エンティティ-属性-値モデル

エンティティ属性値モデル( EAV ) は、スパース (またはアドホック)プロパティまたはデータ値を効率的に格納するために最適化されたデータ モデルであり、実行時の使用パターンが任意であったり、ユーザーの変化の影響を受けたり、固定設計では予測できない状況を想定しています。このユース ケースは、定義されたプロパティ タイプの大規模または豊富なシステムを提供するアプリケーションを対象としています。これらのプロパティ タイプは、幅広いエンティティ セットに適していますが、通常は特定のエンティティに対してこれらのプロパティ タイプのうちのごく一部のみがインスタンス化 (または永続化) されます。したがって、このタイプのデータ モデルは、スパース マトリックスの数学的概念に関連しています。EAV は、オブジェクト属性値モデル、垂直データベース モデル、オープン スキーマとも呼ばれます。

このデータ表現は、空でない値のみが格納されるスパース マトリックスを格納するスペース効率の高い方法に似ています。EAV データ モデルでは、各属性と値のペアはエンティティを記述するファクトであり、EAV テーブルの行には 1 つのファクトが格納されます。EAV テーブルは、多くの場合「長くて細い」と表現されます。「長い」は行の数を指し、「細い」は列の数が少ないことを指します。

データは次の 3 つの列として記録されます。

• エンティティ: 記述される項目。
• 属性またはパラメータ: 通常は、属性定義のテーブルへの外部キーとして実装されます。属性定義テーブルには、属性 ID、属性名、説明、データ型、および最大文字列長や正規表現、許容値のセットなどの入力検証を支援する列が含まれる場合があります。
• 属性の値。

リレーショナル データベースで汎用の臨床記録を表現する方法を考えてみましょう。何千もの列を持つテーブル (またはテーブル セット) を作成することは、明らかに実現可能ではありません。列の大部分がnullになるからです。さらに複雑なことに、患者を長期にわたって追跡する縦断的な医療記録では、同じパラメーターの値が複数存在する場合があります。たとえば、子供の身長と体重は、子供が成長するにつれて変化します。最後に、臨床所見の範囲は拡大し続けます。たとえば、病気が出現し、新しい臨床検査が考案されます。これには、列を絶えず追加し、ユーザー インターフェイスを絶えず改訂する必要があります。「属性の変動性」という用語は、使用可能な属性のリストまたはその定義を時間の経過とともに進化させる必要がある場合に発生する問題や状況を説明するために使用されることがあります。

以下は、1998 年 5 月 1 日の朝に発熱のため医師の診察を受けた際の臨床所見に関する EAV テーブルの行の一部です。山括弧内のエントリは、他のテーブルのエントリへの参照です。ここでは、理解しやすいように、エンコードされた外部キー値ではなくテキストとして表示されています。この例では、値はすべてリテラル値ですが、定義済みの値リストにすることもできます。後者は、可能な値が限られていることがわかっている場合 (つまり、列挙可能) に特に役立ちます。

• エンティティ。臨床所見の場合、エンティティは患者イベントです。つまり、少なくとも患者 ID と、記述されているイベントが発生した日時を記録する 1 つ以上のタイムスタンプ(例: 検査の開始日時と終了日時) を含むテーブルへの外部キーです。
• 属性またはパラメータ: 属性定義のテーブルへの外部キー (この例では、臨床所見の定義)。属性定義テーブルには、少なくとも、属性 ID、属性名、説明、データ型、測定単位、および入力検証を支援する列 (最大文字列長と正規表現、許容される最大値と最小値、許容される値のセットなど) が含まれます。
• 属性の値。これはデータ型によって異なりますが、値の保存方法については後ほど説明します。

以下の例は、肺炎の患者に見られる可能性のある症状所見を示しています。

上記の EAV データは、スーパーマーケットの販売レシートの内容に似ています (これは、データベースの Sales Line Items テーブルに反映されます)。レシートには、実際に購入した商品の詳細のみが記載されており、顧客が購入した可能性があるが購入しなかった店内の商品がすべて記載されているわけではありません。特定の患者の臨床所見と同様に、販売レシートは、本質的にスパースなデータをコンパクトに表現したものです。

• 「エンティティ」は、販売/取引 ID です。これは、販売取引テーブルへの外部キーです。これは、各明細項目を内部的にタグ付けするために使用されますが、領収書では、販売に関する情報が上部 (店舗の場所、販売日時) と下部 (販売の合計金額) に表示されます。
• 「属性」は製品テーブルへの外部キーであり、そこから説明、単価、割引、プロモーションなどを検索します。(製品は臨床所見と同じくらい、あるいはそれ以上に不安定です。新製品は毎月導入されますが、消費者の受け入れが悪ければ市場から撤退する製品もあります。有能なデータベース設計者であれば、Doritos や Diet Coke などの個々の製品をテーブルの列としてハードコードすることはないでしょう。)
• 「値」は、購入数量と合計明細価格です。

行モデリングは、^何か（この場合は販売取引）に関する事実が複数の列ではなく複数の行として記録される^標準的なデータモデリング手法です。行モデリングと EAV（行モデリング^の一般化と見なすことができます）の違いは次のとおりです。

• 行モデル化されたテーブルは、記述する事実が同質です。つまり、Line Items テーブルは販売された製品のみを記述します。対照的に、EAV テーブルにはほぼすべてのタイプの事実が含まれます。
• 行モデル テーブルの値列のデータ型は、記録される事実の性質によって事前に決定されます。対照的に、EAV テーブルでは、特定の行の値の概念的なデータ型はその行の属性によって異なります。したがって、実稼働システムでは、EAV テーブルへの直接データ入力を許可すると、データベース エンジン自体が堅牢な入力検証を実行できないため、大惨事を招くことになります。属性ごとに無限のコーディングを行うことなく、入力検証のタスクのほとんどを実行する汎用フレームワークを構築する方法については、後で説明します。

臨床データ リポジトリでは、行モデリングもさまざまな用途に使用されています。臨床検査の結果は通常数値であるか、数値でエンコードできるため、臨床検査サブスキーマは通常この方法でモデル化されます。

標準的な行モデリングを超えて EAV に移行する必要がある状況を以下に示します。

• 個々の属性のデータ型はさまざまです (臨床所見に見られるように)。
• データのカテゴリは多数あり、増加または変動していますが、各カテゴリ内のインスタンス (レコード/行) の数は非常に少ないです。ここで、従来のモデリングでは、データベースのエンティティ関係図には何百ものテーブルが含まれる可能性があります。数千/数百万の行/インスタンスを含むテーブルは、非常に少ない行を含むテーブルと同じ程度に視覚的に強調されます。後者は、EAV 表現に変換する候補です。この状況は、カテゴリ (「クラス」) をオンザフライで作成する必要があり、一部のクラスがその後のプロトタイプ作成サイクルで削除されることが多いオントロジーモデリング環境で発生します。

特定の (「ハイブリッド」) クラスには、非スパースな (すべてのインスタンスまたはほとんどのインスタンスに存在する) 属性と、非常に可変でスパースな属性があります。後者は EAV モデリングに適しています。たとえば、複合企業によって製造される製品の説明は、製品カテゴリによって異なります。たとえば、電球のブランドを説明するために必要な属性は、医療用画像装置を説明するために必要な属性とはまったく異なりますが、パッケージ単位やアイテムあたりのコストなどの共通の属性は両方にあります。

臨床データでは、エンティティは通常、前述のように臨床イベントです。より汎用的な設定では、エンティティは、データベース内のすべての「オブジェクト」(物) に関する共通情報 (少なくとも、優先名と簡単な説明、およびエンティティが属するカテゴリ/クラス) を記録する「オブジェクト」テーブルへの外部キーです。このテーブル内のすべてのレコード (オブジェクト) には、マシンによって生成されたオブジェクト ID が割り当てられます。

「オブジェクト テーブル」アプローチは、ローレンス リバモア研究所の Tom Slezak 氏と同僚が Chromosome 19 データベース用に開発したもので、現在ではほとんどの大規模バイオインフォマティクス データベースの標準となっています。オブジェクト テーブルの使用は、EAV 設計の同時使用を必須とするものではありません。従来のテーブルを使用して、各オブジェクトのカテゴリ固有の詳細を保存できます。

中央オブジェクト テーブルの主な利点は、オブジェクトの同義語とキーワードのサポート テーブルを用意することで、システム全体にわたって Google のような標準の検索メカニズムを提供できることです。ユーザーは、最初にそのオブジェクトが属するカテゴリを指定しなくても、興味のあるオブジェクトに関する情報を見つけることができます。(これは、"アセチルコリン" などのキーワードが神経伝達物質である分子自体、またはそれが結合する生物学的受容体のいずれかを指す可能性があるバイオサイエンス システムでは重要です。)

EAV テーブル自体では、これは属性 ID にすぎず、前述のように、属性定義テーブルへの外部キーです。ただし、属性関連の情報を含むメタデータ テーブルは通常複数存在し、これについては後ほど簡単に説明します。

上記の EAV データの例のように、すべての値を文字列に強制変換すると、単純ですがスケーラブルではない構造になります。値を使用して何かを行う場合は、定数データ型の相互変換が必要であり、EAV テーブルの値列のインデックスは基本的に役に立ちません。また、画像などの大きなバイナリ データを、小さな整数や文字列と同じテーブルにBase64でエンコードされた形式で保存するのは便利ではありません。そのため、大規模なシステムでは、各データ型 (バイナリ ラージ オブジェクト(BLOB) を含む) ごとに個別の EAV テーブルを使用し、特定の属性のメタデータによって、そのデータが格納される EAV テーブルを識別します。このアプローチは、ユーザーが操作することを選択した特定のクラスまたはフォームの属性メタデータの適度な量をメモリに簡単にキャッシュできるため、実際には非常に効率的です。ただし、属性のデータ型が変更された場合は、データを 1 つのテーブルから別のテーブルに移動する必要があります。

EAV は、知識表現の汎用手段として、「連想リスト」（属性と値のペア）の概念から生まれました。今日では一般的に使用されていますが、これはLISP言語で初めて導入されました。^{[1]属性と値のペアは、設定ファイル（} attribute = value のような単純な構文を使用）など、さまざまなアプリケーションで広く使用されています。EAV の非データベースでの使用例としては、 UIMA（非構造化情報管理アーキテクチャ）があります。これは現在Apache Foundationによって管理され、自然言語処理などの分野で採用されている標準です。テキストを分析するソフトウェアは、通常、セグメントをマークアップ（「注釈」）します。UIMA チュートリアルで提供されている例は、ドキュメントで名前付きエンティティ認識（NER）を実行し、テキスト セグメント「President Bush」に注釈、属性、値のトリプル（Person、Full_Name、「George W. Bush」）を注釈として付けるプログラムです。^[2]このような注釈は、データベース テーブルに格納できます。

EAV は AV ペアと直接関係はありませんが、任意の複雑なデータを永続的に保存するために EAV を使用することを最初に思いついたのは Stead と Hammond のようです。^[3] EAV を採用した最初の医療記録システムは、Regenstrief 電子医療記録 (Clement MacDonald が主導した取り組み)、^[4] William Stead と Ed Hammond の TMR (The Medical Record) システム、およびユタ州ソルトレイクシティの LDS 病院の Homer Warner のグループが作成した HELP Clinical Data Repository (CDR) でした。^{[5] [6]}（Regenstrief システムは、実際には患者属性タイムスタンプ値設計を採用していました。タイムスタンプの使用により、特定の患者/属性の値を時系列で検索することができました。）1970 年代に開発されたこれらのシステムはすべて、EF Coddのリレーショナル データベースモデルに基づく商用システムが利用可能になる前にリリースされましたが、HELP はずっと後になってからリレーショナル アーキテクチャに移植され、3M 社によって商用化されました。（Codd の画期的な論文は 1970 年に発表されましたが、その数学的な論調がコンピューター サイエンス以外の人々にとってアクセスしにくく、結果として IT およびソフトウェア ベンダー界隈でのモデルの受け入れが遅れるという残念な結果をもたらしました。IBM でのCodd の同僚であるChristopher J. Date が、これらのアイデアをわかりやすい言葉に翻訳し、その威力を示す簡単な例を添えたその後の貢献の価値は、いくら強調してもし過ぎることはありません。）

コロンビア・プレスビテリアン医療センターのグループは、EAVシステムの基盤としてリレーショナルデータベースエンジンを初めて使用しました。 ^[7]

NadkarniらによるオープンソースのTrialDB臨床試験 データ管理システムは、DBMSデータ型ごとに1つずつ複数のEAVテーブルを使用した最初のシステムでした。^[8]

EAV/CRフレームワークは、主にLuis MarencoとPrakash Nadkarniによって設計され、EAVにオブジェクト指向の原則を重ね合わせたものです。 ^[9]これは、Tom Slezakのオブジェクトテーブルアプローチ（「エンティティ」セクションで前述した）に基づいて構築されています。公的にアクセス可能な神経科学データベースであるSenseLabは、EAV/CRフレームワークを使用して構築されています。

「EAV データベース」という用語は、データの大部分が EAV としてモデル化されているデータベース設計を指します。ただし、「EAV ベース」と説明されているデータベースでも、システム内の一部のテーブルは従来のリレーショナル テーブルです。

上で述べたように、EAV モデリングは、臨床所見など、属性が多数かつまばらなデータ カテゴリに適しています。これらの条件が満たされない場合は、標準のリレーショナル モデリング (つまり、属性ごとに 1 つの列) が適しています。EAV を使用することは、常識や適切なリレーショナル設計の原則を放棄することを意味するものではありません。臨床記録システムでは、患者の人口統計と請求を扱うサブスキーマは通常、従来の方法でモデリングされます。(ほとんどのベンダー データベース スキーマは独自のものですが、米国退役軍人省 (VA) の医療システム全体で使用されるシステムであるVistA (退役軍人保健局(VHA) ^[10]として知られている) はオープン ソースであり、そのスキーマは簡単に検査できますが、リレーショナル データベースではなく MUMPSデータベース エンジンを使用しています。)

後ほど説明するように、EAVデータベースは、サポートメタデータを含む多数のサポートテーブルがなければ本質的に保守できません。メタデータテーブルは、通常、EAVテーブルの少なくとも3倍以上あり、通常は標準的なリレーショナルテーブルです。^{[8] [9]}メタデータテーブルの例としては、前述の属性定義テーブルがあります。

単純な EAV 設計では、データベース エンジンに関する限り、属性の値は単純またはプリミティブなデータ型です。ただし、非常に多様なデータの表現に使用される EAV システムでは、特定のオブジェクト (クラス インスタンス) にサブ構造がある可能性があります。つまり、その属性の一部は他の種類のオブジェクトを表し、そのオブジェクトも任意のレベルの複雑さでサブ構造を持つ可能性があります。たとえば、車にはエンジン、トランスミッションなどがあり、エンジンにはシリンダーなどのコンポーネントがあります。(特定のクラスの許容されるサブ構造は、後で説明するように、システムの属性メタデータ内で定義されます。したがって、たとえば、属性「ランダム アクセス メモリ」はクラス「コンピュータ」には適用できますが、クラス「エンジン」には適用できません。)

サブ構造を表現するには、値列にシステム内の他のエンティティへの参照 (つまり、オブジェクト テーブルへの外部キー値) が含まれる特別な EAV テーブルを組み込みます。特定のオブジェクトに関するすべての情報を取得するには、メタデータの再帰的トラバーサルと、取得されたすべての属性が単純 (アトミック) になった時点で停止するデータの再帰的トラバーサルが必要です。再帰的トラバーサルは、個々のクラスの詳細が従来の形式または EAV 形式で表されるかどうかに関係なく必要です。このようなトラバーサルは、たとえば、標準のオブジェクト リレーショナル システムで実行されます。実際には、ほとんどのクラスで再帰レベルの数は比較的少ない傾向があるため、再帰によるパフォーマンスの低下は、特にオブジェクト ID のインデックス作成ではそれほど大きくありません。

EAV/CR (クラスとリレーションシップを備えた EAV) ^{[11] [12] [13] は、}複雑なサブ構造をサポートするフレームワークを指します。その名前はやや誤解を招くものです。EAV システムの研究から派生したものですが、実際には、そのようなシステムのクラスの多く、あるいはほとんどは、属性が疎か密かに基づいて、標準的なリレーショナル形式で表現できます。EAV/CR は、非常に詳細なメタデータを特徴としており、クラスごとにユーザー インターフェイス コードを記述しなくても、個々のクラスへのブラウジング インターフェイスの自動生成をサポートできるほど豊富です。このようなブラウザー インターフェイスの基礎は、オブジェクトのクラスに依存しない一連の動的 SQL クエリを生成できることです。そのためには、まずそのメタデータを参照し、メタデータ情報を使用してデータ テーブルに対する一連のクエリを生成します。これらのクエリの一部は、任意に再帰的になる場合があります。このアプローチは、オブジェクト名をクリックするとそのオブジェクトの詳細がすべて別のページに表示される Web ベースのブラウジング インターフェイスなどの、オブジェクトを一度に 1 つずつ検索するクエリに適しています。オブジェクトのクラスに関連付けられたメタデータには、個々の属性のキャプション、属性の表示順序、およびグループ化方法が含まれているため、オブジェクトの詳細の表示も容易になります。

EAV/CR への 1 つのアプローチは、列にJSON構造を保持できるようにして、必要なクラス構造を提供することです。たとえば、PostgreSQL はバージョン 9.4 以降、JSON バイナリ列 (JSONB) をサポートしており、JSON 属性のクエリ、インデックス作成、結合が可能です。

ダニエル・マシス教授（元ヴァンダービルト大学医療情報学部長）によれば、EAV を扱う際の課題は、EAV データベースでは「物理スキーマ」（データの格納方法）が「論理スキーマ」（ユーザーや統計パッケージなどの多くのソフトウェア アプリケーションがデータを個々のクラスの従来の行と列として扱う方法）と根本的に異なるという事実から生じています。（EAV テーブルは概念的にリンゴ、オレンジ、グレープフルーツ、チャプスイを混ぜ合わせたものなので、標準的な市販ソフトウェアを使用してデータの分析を行う場合、ほとんどの場合、データのサブセットを列形式に変換する必要があります。^[14]このプロセスはピボットと呼ばれ、別途説明するほど重要です。）

メタデータは、ユーザーが物理的なスキーマではなく論理的なスキーマの観点からシステムと対話できるようにする巧妙な操作に役立ちます。ソフトウェアは、データの表示、対話型の検証、一括データ抽出、アドホッククエリなどのさまざまな操作について、継続的にメタデータを参照します。メタデータは、実際にシステムの動作をカスタマイズするために使用できます。

EAV システムでは、データの物理的および論理的構造の単純さとメタデータの複雑さがトレードオフされています。メタデータは、とりわけ、標準データベース設計におけるデータベース制約と参照整合性の役割を果たします。このようなトレードオフは、一般に価値があります。なぜなら、本番システムの一般的な混合スキーマでは、従来のリレーショナル テーブルのデータも自動インターフェイス生成などの機能の恩恵を受けることができるからです。メタデータの構造は、データベース内に独自のサブスキーマを構成するほど複雑です。データ テーブル内のさまざまな外部キーは、このサブスキーマ内のテーブルを参照します。このサブスキーマは標準リレーショナルであり、制約や参照整合性などの機能が最大限に活用されています。

メタデータの内容が、意図されたシステム動作の観点から正確であることは極めて重要であり、正確性を保証するというタスクは、EAV システムを作成する際に、問題領域 (臨床医学など) を理解しているが必ずしもプログラマーではないチーム メンバーが使用できるメタデータ編集用のユーザー インターフェイスの構築に、かなりの設計努力を費やす必要があることを意味します。(歴史的に、リレーショナル以前の TMR システムが本拠地以外のサイトで採用されなかった主な理由の 1 つは、すべてのメタデータが直感的でない構造を持つ 1 つのファイルに保存されていたことです。このファイルの内容を変更してシステムを壊さずにシステム動作をカスタマイズすることは、非常に繊細なタスクであったため、システムの作成者は自分自身でしかそれを実行できませんでした。)

EAVシステムがRDFを介して実装されている場合、RDFスキーマ言語はそのようなメタデータを表現するために便利に使用できます。このスキーマ情報は、EAVデータベースエンジンによって使用され、内部テーブル構造を動的に再編成して、最高の効率を実現します。^[15]

メタデータに関する最後の注意事項:

• ビジネス ロジックはデータベース スキーマに明示されているのではなく、メタデータ内にあるため (つまり、従来の設計のシステムと比較して 1 レベル離れている)、システムに精通していない人にはわかりにくくなります。したがって、メタデータ参照ツールとメタデータ レポート ツールは、EAV システムの保守性を確保する上で重要です。メタデータがリレーショナル サブスキーマとして実装される一般的なシナリオでは、これらのツールは、メタデータ テーブルで動作する既製のレポート ツールまたはクエリ ツールを使用して構築されたアプリケーションにすぎません。
• 十分な知識のないユーザーは、メタデータを破損 (つまり、不整合やエラーを導入) しがちです。そのため、メタデータへのアクセスを制限し、複数のユーザーがメタデータにアクセスできる状況に対処するために、アクセスと変更の監査証跡を用意する必要があります。メタデータに RDBMS を使用すると、トランザクションのサポートなどの RDBMS 機能を活用して、メタデータの作成と編集中に一貫性を維持するプロセスが簡素化されます。また、メタデータがデータ自体と同じデータベースの一部である場合は、データ自体と同じ頻度でバックアップされ、特定の時点に回復できるようになります。
• メタデータ内の注釈とドキュメント（つまり、メタデータ サブスキーマの説明列にある説明文）の品質は、開発チームのさまざまなメンバーの理解を容易にするために、はるかに高くなければなりません。メタデータの品質を確保すること（およびシステムの進化に合わせてメタデータを最新の状態に保つこと）は、EAV コンポーネントを使用する設計の長期的な管理と保守において非常に高い優先度を持ちます。ドキュメント化が不十分なメタデータや古いメタデータは、システムの長期的な存続を危うくする可能性があります。^{[16] [17]}

• 検証メタデータには、データ型、許容値の範囲または値セットのメンバーシップ、正規表現の一致、デフォルト値、および値が null になることが許可されるかどうかが含まれます。サブ構造を持つクラスを表す EAV システムでは、検証メタデータには、特定の属性が属するクラス (存在する場合) も記録されます。
• プレゼンテーション メタデータ: 属性をユーザーにどのように表示するか (たとえば、指定された寸法のテキスト ボックスまたは画像、プルダウン リスト、ラジオ ボタンのセットなど)。EAV/CR 設計のように、複合オブジェクトが複数の属性で構成されている場合は、属性を表示する順序、およびこれらの属性をオプションでグループ化する方法 (説明的な見出しの下) に関する追加のメタデータがあります。
• 検査パラメータとなる属性については、年齢、性別、生理状態、検査方法によって異なる可能性がある正常値の範囲が記録されます。
• グループ化メタデータ: 属性は通常、専門分野固有のフォームなどの上位グループの一部として表示されます。グループ化メタデータには、属性が表示される順序などの情報が含まれます。フォント/色や行ごとに表示される属性の数などの特定のプレゼンテーション メタデータは、グループ全体に適用されます。

• 依存関係メタデータ: 多くのユーザー インターフェイスでは、特定のフィールド/属性に特定の値を入力することで、他の特定のフィールドを無効/非表示にしたり、他のフィールドを有効に/表示したりする必要があります。(たとえば、ユーザーが「患者は糖尿病を患っていますか?」というブール値の質問に対して「いいえ」と回答した場合、糖尿病の期間、糖尿病の薬などに関する後続の質問を無効にする必要があります。) 汎用フレームワークでこれを実現するには、制御属性と制御対象属性間の依存関係を保存する必要があります。
• 計算と複雑な検証: スプレッドシートと同様に、特定の属性の値は、順番に前に表示されているフィールドに入力された値に基づいて計算され、表示されます。(たとえば、体表面積は高さと幅の関数です)。同様に、データが有効であるためには「制約」が満たされていなければならない場合があります。たとえば、白血球の分画では、個々の白血球の種類のカウントの合計は常に 100 に等しくなければなりません。これは、個々のカウントがパーセンテージを表しているためです。計算された数式と複雑な検証は、通常、ユーザーが入力して評価できる値でマクロ置換される式をメタデータに格納することによって行われます。Web ブラウザーでは、JavaScriptとVBScript の両方に、この目的に利用できる Eval() 関数があります。

検証、プレゼンテーション、およびグループ化メタデータにより、データ ブラウジングと対話型編集の両方の自動ユーザー インターフェイス生成をサポートするコード フレームワークの作成が可能になります。Web 経由で配信される実稼働システムでは、EAV データの検証タスクは、基本的にバックエンド/データベース層 (このタスクに関しては無力) から中間層/Web サーバー層に移行されます。バックエンド検証は常に理想的ですが、テーブルに直接データを入力すると無効にすることが不可能であるため、汎用フレームワークによる中間層検証は非常に有効です。ただし、最初にフレームワークを構築するためにかなりのソフトウェア設計作業を行う必要があります。個々のニーズに合わせて調査および変更できるオープン ソースフレームワークを利用できることは、車輪の再発明を回避するのに大いに役立ちます。^{[引用が必要]}

（このセクションの最初の部分は、 Central ^[18]のDinu/Nadkarniの参考記事の要約であり、詳細については読者に紹介されています。）

EAV モデリングは、「汎用データ モデリング」または「オープン スキーマ」とも呼ばれ、長年、上級データ モデラーの標準ツールとして使用されてきました。他の高度な技術と同様に、EAV モデリングは諸刃の剣であり、慎重に使用する必要があります。

また、EAV を採用しても、同じデータベース スキーマ内で従来のリレーショナル データベース モデリング アプローチを採用できないわけではありません。臨床データ サブスキーマに EAV アプローチを使用するCernerなどの RDBMS に依存する EMR では、スキーマ内のテーブルの大部分は実際には従来の方法でモデル化されており、属性は行ではなく個別の列として表されます。

実際、EAV システムのメタデータ サブスキーマのモデリングは、メタデータのさまざまなコンポーネント間の相互関係のため、従来のモデリングに非常に適しています。たとえば、TrialDB システムでは、スキーマ内のメタデータ テーブルの数は、データ テーブルの約 10 倍です。メタデータの正確性と一貫性は、EAV システムの正しい動作に不可欠であるため、システム設計者は、RDBMS エンジン ホイールを再発明するのではなく、参照整合性やプログラム可能な制約など、RDBMS が提供するすべての機能を最大限に活用したいと考えています。その結果、EAV 設計をサポートする多数のメタデータ テーブルは、通常、第 3 正規リレーショナル形式になります。

商用の電子健康記録システム (EHR) では、診断、手術、臨床検査結果などのデータのクラスに行モデリングが使用され、これらは別々のテーブルに分離されています。各テーブルでは、「エンティティ」は患者 ID と診断が行われた日時 (または手術または臨床検査が行われた日時) を組み合わせたもので、属性は、制御された語彙 (診断の場合はICD-10、外科処置の場合はCurrent Procedural Terminologyなど)と一連の値属性を含む特別に指定されたルックアップ テーブルへの外部キーです。 (たとえば、実験室でのテスト結果の場合、測定された値、それが正常範囲、低値範囲、高値範囲のいずれであるか、テストの実行責任者の ID、テストの実行日時などを記録することができます。) 前述のように、これは本格的な EAV アプローチではありません。スーパーマーケットの Sales テーブル内の製品 ID のドメインが Products テーブル内の Products のドメインに制限されるのと同じように、特定のテーブルの属性のドメインが制限されるためです。

ただし、標準の語彙で必ずしも定義されていないパラメータのデータを取得するために、EHR は「純粋な」EAV メカニズムも提供します。このメカニズムでは、特別に指定されたパワー ユーザーが新しい属性、そのデータ タイプ、最大および最小許容値 (または許容される値/コードのセット) を定義し、他のユーザーがこれらの属性に基づいてデータを取得できるようにします。Epic (TM) EHR では、このメカニズムは「フローシート」と呼ばれ、入院患者の看護観察データを取得するためによく使用されます。

EAV モデルを使用する典型的なケースは、前述のように、電子医療記録 (EMR) の臨床パラメータなど、非常にまばらで異種の属性の場合です。ただし、ここでも、EAV モデリングの原則は、データベースのすべてのコンテンツではなく、データベースのサブスキーマに適用されていると述べるのが正確です。(たとえば、患者の人口統計は、属性ごとに 1 列の従来のリレーショナル構造で最も自然にモデル化されます。)

その結果、EAV と「リレーショナル」設計に関する議論は、問題に対する理解が不十分であることを反映します。EAV 設計は、スパース属性をモデル化する必要があるデータベースのサブスキーマにのみ使用する必要があります。この場合も、第 3 正規形のメタデータ テーブルでサポートする必要があります。スパース属性が発生するデータベース設計の問題は比較的少ないため、EAV 設計を適用できる状況は比較的まれです。発生した場合でも、EAV テーブルのセットがスパース データに対処する唯一の方法ではありません。エンティティあたりの属性の最大数が比較的少なく、スパース データの総量も同様に少ない場合は、XML ベースのソリューション (後述) を適用できます。この状況の例として、さまざまな製品タイプの可変属性を取得する問題が挙げられます。

スパース属性は、組織が膨大かつ非常に多様な商品を購入または販売し、商品の個々のカテゴリの詳細が非常に変動しやすい電子商取引の状況でも発生する可能性があります。

EAV のもう 1 つの用途は、クラスと属性をモデル化することです。クラスと属性は、まばらではありませんが動的であり、クラスあたりのデータ行数は比較的少なく (多くても数百行ですが、通常は数十行)、システム開発者は Web ベースのエンド ユーザー インターフェイスを非常に短いターンアラウンド タイムで提供する必要があります。「動的」とは、進化するデータ モデルを表すために、新しいクラスと属性を継続的に定義および変更する必要があることを意味します。このシナリオは、急速に進化する科学分野やオントロジー開発、特にプロトタイプ作成と反復的な改良の段階で発生する可能性があります。

新しいカテゴリのデータを表す新しいテーブルと列の作成は特に手間がかかるわけではありませんが、型と範囲に基づく検証による参照や基本的な編集をサポートする Web ベースのインターフェイスのプログラミングは手間がかかります。このような場合、より保守しやすい長期的なソリューションは、クラスと属性の定義がメタデータに保存され、ソフトウェアがこのメタデータから基本的なユーザー インターフェイスを動的に生成するフレームワークを作成することです。

前述の EAV/CR フレームワークは、まさにこの状況に対処するために作成されました。EAV データ モデルはここでは必須ではありませんが、システム設計者は、たとえば合計 2,000 行以下のテーブルを 60 個以上作成する代わりに、EAV データ モデルを許容できると考えるかもしれません。ここでは、クラスあたりの行数が非常に少ないため、効率性を考慮することはそれほど重要ではありません。クラス ID/属性 ID による標準のインデックス作成により、DBMS オプティマイザーは、そのクラスまたは属性を含むクエリを実行するときに、小さなクラスのデータを簡単にメモリにキャッシュできます。

動的属性のシナリオでは、リソース記述フレームワーク(RDF) がセマンティック Web 関連のオントロジー作業の基盤として採用されていることに注目する価値があります。RDF は、情報を表す一般的な方法となることを意図しており、EAV の一種です。RDF トリプルは、オブジェクト、プロパティ、および値で構成されます。

Jon Bentley の著書「効率的なプログラムの作成」の最後で、著者は、コードを効率化すると、一般的に理解や保守が難しくなるため、パフォーマンスに問題があると判断され、コード プロファイリングなどの手段でボトルネックの正確な場所が特定されない限り、急いでコードを調整すべきではないと警告しています。いったんそうしたら、より高速に実行する必要がある特定のコードのみを変更します。同様の考慮事項が EAV モデリングにも当てはまります。つまり、従来のリレーショナル モデリングが扱いにくいことが事前にわかっているサブシステム(臨床データ ドメインなど) や、システムの進化中に保守上の大きな課題が判明したサブシステムにのみ EAV を適用します。たとえば、データベースの第一人者 (現在は Oracle Corporation のコア テクノロジー担当副社長) Tom Kyte 氏^[19]は、従来のビジネス シナリオで EAV を採用することの欠点を正しく指摘し、単なる「柔軟性」だけでは EAV を採用する十分な基準ではないことを指摘しています。 （しかし、オラクルのヘルスサイエンス部門自体が、商用システムであるClinTrial ^[20]とOracle Clinical ^[21]で臨床データ属性をモデル化するためにEAVを採用しているにもかかわらず、彼はEAVはいかなる状況でも避けるべきであると大胆に主張している。 ）

EAV の最大の弱点は、大量の EAV データを扱うのが難しいことです。同じデータの列形式と行形式または EAV 形式の表現を一時的または永続的に相互変換する必要がある場合がよくあります。これは、手動で行うとエラーが発生しやすく、CPU を集中的に使用することになります。属性と属性グループ化メタデータを利用する汎用フレームワークは、前者の制限には対処しますが、後者の制限には対処しません。従来のリレーショナル データと EAV データが混在する混合スキーマの場合、エラー率が非常に大きくなる可能性があるため、それらの使用は多かれ少なかれ必須です。

変換操作はピボットと呼ばれます。ピボットは、EAV データだけでなく、行モデル化されたあらゆる形式のデータにも必要です。(たとえば、スーパーマーケットの売上データを処理して、特定の製品の購入者が購入する可能性のある他の製品を識別するために広く使用されているアソシエーション分析のApriori アルゴリズムの実装では、最初のステップとして行モデル化されたデータをピボットします。) 多くのデータベース エンジンには、ピボットを容易にするための独自の SQL 拡張機能があり、Microsoft Excel などのパッケージもこれをサポートしています。ピボットが必要な状況については、以下で説明します。

• 個々のエンティティの適度な量のデータを参照し、必要に応じて属性間の依存関係に基づいてデータを編集します。この操作は、適度な量の必要なサポート メタデータをキャッシュすることで容易になります。TrialDB などの一部のプログラムは、メタデータにアクセスして、埋め込まれたプログラミング コードとメタデータを保持するデータ構造を含む半静的 Web ページを生成します。
• 一括抽出は、大量の（ただし予測可能な）データ（例：臨床試験の完全なデータ）をリレーショナル テーブルのセットに変換します。CPU を集中的に使用するこのタスクは、頻度が低く、リアルタイムで実行する必要はありません。つまり、ユーザーはバッチ処理が完了するまで待つことができます。一括抽出の重要性は、特に EAV 構造をまったく認識しない標準的なサードパーティ ツールでデータを処理または分析する場合に、過大評価されることはありません。ここでは、汎用フレームワークを使用して車輪のセット全体を再発明することはお勧めできません。EAV データをリレーショナル テーブルに一括抽出し、標準ツールを使用して操作するのが最善です。
• 行または EAV モデル化されたデータへのアドホック クエリインターフェイスは、個々の属性の観点からクエリを実行する場合 (例: 「肝疾患があり、肝不全の兆候があり、アルコール乱用の履歴がないすべての患者を取得する」)、通常は個々の属性を別々の列としてクエリの結果を表示する必要があります。ほとんどの EAV データベース シナリオでは、アドホック クエリのパフォーマンスは許容範囲内である必要がありますが、クエリは本質的に探索的である傾向があるため、1 秒未満の応答は必要ありません。

しかし、EAVデータモデルの構造はリレーショナルディビジョンの完璧な候補です。リレーショナル代数を参照してください。適切なインデックス戦略を使用すれば、10億行のEAVテーブルで数百ミリ秒未満の応答時間を実現できます。Microsoft SQL Server MVPのPeter Larssonはラップトップでこれを実証し、ソリューションを一般に公開しました。^[22]

• 最適化の 1 つの方法として、本番 (トランザクション) スキーマとは別の「ウェアハウス」またはクエリ可能なスキーマを使用して、その内容をバッチ モードで更新する方法があります。データ ウェアハウスを参照してください。ウェアハウス内のテーブルは、複数のテーブルを 1 つに結合してテーブル結合によるパフォーマンスの低下を最小限に抑える非正規化を使用して、徹底的にインデックス付けおよび最適化されています。
• ウェアハウス内の特定のEAVデータは、「マテリアライズドビュー」（データウェアハウスを参照）を使用して標準テーブルに変換できますが、この種のビューの数はシステム内の属性の数に応じて非線形に増加する傾向があるため、これは通常最後の手段であり、慎重に使用する必要があります。^[14]
• インメモリ データ構造: ハッシュ テーブルと 2 次元配列をメモリ内で属性グループ化メタデータと組み合わせて使用​​することで、一度に 1 グループずつデータをピボットできます。このデータは、各属性の内部名が最初の行にあるフラットな区切りファイルとしてディスクに書き込まれます。この形式は、リレーショナル テーブルに簡単に一括インポートできます。この「インメモリ」手法は、EAV テーブルに対するクエリを可能な限りシンプルに保ち、I/O 操作の数を最小限に抑えることで、他のアプローチを大幅に上回ります。^[14]各ステートメントは大量のデータを取得し、ハッシュ テーブルはピボット操作の実行に役立ちます。ピボット操作では、特定の属性インスタンスの値を適切な行と列に配置します。ランダム アクセス メモリ (RAM) は、最新のハードウェアでは十分に豊富で手頃な価格であるため、大規模なデータ セットでも、単一の属性グループの完全なデータ セットは通常、メモリに完全に収まります。ただし、そうでない場合は、データのスライスを処理することでアルゴリズムをよりスマートにすることができます。

明らかに、どのようなアプローチをとっても、特定の種類のクエリでは、EAV のクエリは標準の列モデル化されたリレーショナル データのクエリほど高速ではありません。これは、スパース マトリックス内の要素へのアクセスが、非スパース マトリックスが完全にメイン メモリに収まる場合の非スパース マトリックス内の要素へのアクセスほど高速ではないのと同じです。(リンク リストなどの構造を使用して表されるスパース マトリックスでは、特定の XY 位置にある要素にアクセスするためにリストのトラバーサルが必要ですが、2 次元配列として表されるマトリックス内の要素へのアクセスは、高速な CPU レジスタ操作を使用して実行できます。) ただし、解決しようとしていた問題に対して EAV アプローチを正しく選択した場合、これは支払うべき代償です。この点で、EAV モデリングは、スペース (およびスキーマのメンテナンス) と CPU 時間のトレードオフの例です。

もともと Maier、Ullman、Vardi によって提唱された^[23]「ユニバーサル データ モデル」(UDM) は、すべてが 1 つの巨大な「ユニバーサル テーブル」に格納されているという錯覚を作り出すことで、初心者ユーザーによる複雑なリレーショナル スキーマのクエリを簡素化することを目指しています。これはテーブル間の関係を利用して実現されるため、ユーザーはどのテーブルにどの属性が含まれているかを気にする必要がありません。しかし、CJ Date ^[24]は、テーブルが別のテーブルと多重に関連付けられている状況 (個人の父親と母親も個人である系図データベースや、すべての住所が一元的に格納され、組織がオフィス アドレスと配送先住所を別々に持つことができる一部のビジネス データベースなど) では、データベース スキーマ内には明確な結合を指定するためのメタデータが不十分であると指摘しました。 SAP BusinessObjectsのように UDM が商品化されると、この制限は「ユニバース」の作成によって回避されます。「ユニバース」は、テーブル セット間の結合が事前に定義されたリレーショナル ビューです。「ユニバース」開発者は、異なるエイリアスを使用して、複数回関連するテーブルをビューに含めることで、あいまいな結合を明確にします。

データが明示的にモデル化される方法 (UDM は、ユーザーとデータベース スキーマの間を仲介するためにリレーショナル ビューを使用するだけ) とは別に、EAV は、UDM のようなクエリ指向 (読み取り専用) システムだけでなく、トランザクション システムにも適用されるという点でユニバーサル データ モデルとは異なります。また、臨床データ クエリ システムの基盤として使用される場合、EAV 実装は、ユーザーが関心のあるオブジェクトのクラスを指定する必要がないようにするわけではありません。たとえば、EAV ベースの i2b2 臨床データ マート^{[25]では、ユーザーが用語を検索するときに、関心のあるデータのカテゴリを指定するオプションがあります。たとえば、「}リチウム」という語句は、薬剤 (双極性障害の治療に使用される) または患者の血液中のリチウム濃度の検査結果のいずれかを指します。(リチウムの血中濃度は注意深く監視する必要があります。薬剤が多すぎると深刻な副作用が生じ、少なすぎると効果がありません。)

Open Schema実装では、テーブル内のXML列を使用して、可変/スパース情報を取得できます。^{[26]同様のアイデアは、} JSON値の列 をサポートするデータベースにも適用できます。スパースで階層的なデータはJSONとして表現できます。PostgreSQLや（部分的に）SQL Server 2016以降など、データベースがJSONをサポートしている場合は、属性をクエリ、インデックス付け、結合できます。これにより、単純なEAV実装に比べて1000倍以上のパフォーマンス向上が実現できます。^[27]ただし、データベースアプリケーション全体が必ずしも堅牢になるわけではありません。

XML または JSON データを保存する方法は 2 つあります。1 つは、データベース サーバーに不透明なプレーン文字列として保存する方法です。もう 1 つは、構造を「確認」できるデータベース サーバーを使用する方法です。不透明な文字列を保存すると、明らかにいくつかの重大な欠点があります。つまり、直接クエリを実行できず、内容に基づいてインデックスを作成できず、内容に基づいて結合を実行できないのです。

EAV モデルを使用すると、メタデータ テーブルとアプリケーション フレームワーク コードに関して開発する必要があるインフラストラクチャの範囲が広いため、データを管理するアプリケーションの構築が非常に複雑になります。XML を使用すると、サーバーベースのデータ検証の問題は解決されます (EAV ベースのフレームワークでは、中間層とブラウザーベースのコードによって実行する必要があります)。ただし、次のような欠点があります。

• プログラマーの負担が大きい。XML スキーマは手動で記述するのが難しいことで有名です。推奨される方法は、リレーショナル テーブルを定義し、XML スキーマ コードを生成し、これらのテーブルを削除して作成することです。これは、動的スキーマを伴う多くの実稼働オペレーションで問題になります。動的スキーマでは、特定のアプリケーション ドメイン (在庫管理やバイオメディカルなど) を理解しているものの、必ずしもプログラマーではないパワー ユーザーが新しい属性を定義する必要があります。対照的に、EAV を使用する実稼働システムでは、そのようなユーザーは GUI アプリケーションを使用して新しい属性 (およびそれぞれに関連付けられたデータ型と検証チェック) を定義します。検証に関連付けられたメタデータは、正規化された設計で複数のリレーショナル テーブルに格納する必要があるため、これらのテーブルを結び付けて適切なメタデータの一貫性チェックを実施する GUI アプリケーションが、高度な開発者であっても、属性情報を入力できる唯一の実用的な方法です。最終結果が個別のリレーショナル テーブルではなく XML または JSON を使用する場合でもです。
• 不正なデータを挿入しようとした場合に XML/JSON ソリューションで生成されるサーバーベースの診断 (範囲チェックや正規表現パターン違反など) は、エンド ユーザーにはわかりにくいものです。エラーを正確に伝えるには、少なくとも各属性に詳細かつユーザー フレンドリなエラー診断を関連付ける必要があります。
• このソリューションでは、ユーザー インターフェイス生成の問題は解決されません。

上記の欠点はすべて、メタデータとアプリケーション コードの層を作成することで解決できますが、これを作成すると、フレームワークを作成する必要がないという当初の「利点」が消えてしまいます。実際、どのストレージ アプローチを使用する場合でも、スパース データ属性を堅牢にモデル化することは、データベース アプリケーション設計の難しい問題です。ただし、Sarka の研究^[26]では、データ ストレージ層にタイプ固有のリレーショナル EAV テーブルではなく XML フィールドを使用することが実現可能であることが証明されています。また、エンティティあたりの属性数がそれほど多くない場合 (たとえば、異なる製品タイプに対する可変の製品属性)、XML ベースのソリューションは EAV テーブル ベースのソリューションよりもコンパクトです (XML 自体は、リレーショナル テーブルではなく構造化テキストに基づいていますが、属性値データ表現の手段と見なすことができます)。

リレーショナルデータベースでは、ツリー構造のデータを表現する方法として、XML、JSON 、ネストされたセットモデルなどの他の形式など、いくつかのアプローチが存在します。一方、データベースベンダーは、IBM Db2のように、SQL文の一部としてXPathクエリを使用してXMLデータをテーブルとは別のXMLとして保存したり、 PostgreSQLのようにインデックス作成やクエリが可能なJSONデータ型^[28]を使用したりすることで、JSONとXMLのサポートを自社のデータ構造やクエリ機能に組み込み始めています。これらの開発により、EAVモデルアプローチが実現、改善、または代替されています。

JSON と XML の使用は、重複することはありますが、必ずしも EAV モデルの使用と同じではありません。単一のエンティティに対して比較的小規模な任意の階層データの場合は、EAV よりも XML の方が適しています。データ操作のパフォーマンスに関しては、数ギガバイト レベルまでスケールアップすることを意図していません。^[要出典] XML は、スパース属性の問題に本質的には関係がなく、表現する情報の基礎となるデータ モデルをリレーショナル構造に簡単に分解できる場合、XML はプライマリ ストレージ メカニズムよりもデータ交換の手段として適しています。EAV は、前述のように、スパース属性のシナリオにのみ適用できます。このようなシナリオが当てはまる場合、エンティティ、属性、値でインデックスを付けることができ、単純な SQL ステートメントで操作できるデータ型固有の属性値テーブルを使用する方が、XML ツリー構造を使用するよりもはるかにスケーラブルです。^{[引用が必要]}前述の Google App Engine ^{[引用が必要]}では、正当な理由により、厳密に型指定された値のテーブルが使用されています。^{[引用が必要]}

EAV構造化データで発生するさまざまな問題に対処するための代替アプローチは、グラフデータベースを使用することです。グラフデータベースは、エンティティをグラフまたはハイパーグラフのノードとして表し、属性をそのグラフのリンクまたはエッジとして表します。テーブル結合の問題は、 Apache TinkerPop ^[29]やOpenCogアトムスペースパターンマッチャー^[30]などのグラフ固有のクエリ言語を提供することで解決されます。

別の方法としては、 SPARQLストアを使用する方法があります。

PostgreSQLバージョン9.4には、クエリ、インデックス、結合が可能なJSONバイナリ列（JSONB）のサポートが含まれています。これにより、従来のEAVテーブル設計に比べて1000倍以上のパフォーマンス向上が実現します。^[27]

JSONBに基づくDBスキーマは常にテーブルが少なくなります。エンティティテーブルのJSONB型フィールドに属性と値のペアをネストすることができます。これにより、DBスキーマが理解しやすくなり、SQLクエリが簡潔になります。^[31] 抽象化レイヤー上のデータベースオブジェクトを操作するプログラミングコードははるかに短くなります。^[32]

Microsoft SQL Server 2008 は、EAV の (独自の) 代替手段を提供しています。^[33]アトミック データ型の列 (数値、varchar、datetime 列など) は、 CREATE TABLE ステートメントの列定義に SPARSE という語を含めるだけで、スパースとして指定できます。スパース列は NULL 値 (スペースをまったく占有しない) の格納を最適化し、テーブル内の大多数のレコードがその列に対して NULL 値を持つ場合に便利です。スパース列のインデックスも最適化されており、値を持つ行だけがインデックス付けされます。さらに、テーブルの特定の行にあるすべてのスパース列の内容を 1 つの XML 列 (列セット) にまとめて集約することができ、その内容は次の形式になります。[<column-name>column contents </column-name>]*....実際、CREATE TABLE ステートメントの一部としてテーブルの列セットが定義されている場合、その後に定義されるすべてのスパース列は通常、その列に追加されます。これには興味深い結果があり、SQL ステートメントはSELECT * from <tablename>個々のスパース列を返すのではなく、それらすべてを、列セットの名前と同じ名前を持つ単一の XML 列に連結します (したがって、仮想の計算列として機能します)。スパース列は、製品情報などのビジネス アプリケーションに便利です。このようなアプリケーションでは、適用可能な属性は製品の種類によって大きく異なりますが、製品の種類ごとの可変属性の合計数は比較的少ないです。

ただし、スパース属性をモデル化するこのアプローチにはいくつかの制限があります。特に、競合 DBMS は、このアイデアを独自のエンジンに取り入れないことを選択しました。制限には次のものがあります。

• テーブル内のスパース列の最大数は 10,000 ですが、臨床データを保存する場合など、属性の可能な数が 1 桁多い実装では、この数では不足する可能性があります。したがって、これは患者のすべての臨床属性をモデル化するためのソリューションではありません。
• EAV モデルが求められる主な理由の 1 つである新しい属性の追加には、依然として DBA が必要です。さらに、スパース属性データへのユーザー インターフェイスの構築の問題は解決されておらず、ストレージ メカニズムのみが合理化されています。
• アプリケーションは、実行時にテーブルからスパース列を動的に追加および削除するように作成できます。対照的に、他のユーザー/プロセスがまだテーブルを使用しているマルチユーザー シナリオでこのようなアクションを実行しようとすると、スパース列のないテーブルでは阻止されます。ただし、この機能は強力で柔軟性がありますが、乱用を招く可能性があるため、慎重に頻繁に使用しないでください。
  • このテーブルを使用するコンパイル済みのクエリ プランが自動的に無効になるため、パフォーマンスが大幅に低下する可能性があります。
  • 動的な列の追加または削除は、列の削除によってデータが失われる可能性があるため、監査する必要がある操作です。アクションの正当性を含む何らかの証跡を保持せずにアプリケーションがテーブルを変更できるようにすることは、適切なソフトウェア プラクティスではありません。
• SQL 制約 (範囲チェック、正規表現チェックなど) はスパース列には適用できません。適用されるチェックは、正しいデータ型のみです。制約は、実稼働 EAV システムで行われるように、メタデータ テーブルと中間層コードに実装する必要があります。(この考慮事項は、ビジネス アプリケーションにも適用されます。)
• SQL Server では、列のストレージ形式を変更する場合、行のサイズに制限があります。データが自動的にコピーされるスパース列がテーブルに含まれている場合、データを含む行のすべてのアトミック データ型列 (スパース列と非スパース列) の合計内容は 8016 バイトを超えることはできません。
• データがたまたま含まれているスパース列には、データ型自体のストレージ (たとえば、datetime 列の場合は 4 バイト) に加えて、列ごとに 4 バイトのストレージ オーバーヘッドがあります。これは、特定の行に関連付けることができるスパース列データの量に影響します。このサイズ制限は varchar データ型では緩和されています。つまり、実稼働システムで行サイズの制限に達した場合、スパース列の本来のデータ型が異なっていても、スパース列を varchar として指定することで回避する必要があります。残念ながら、このアプローチでは、サーバー側のデータ型チェックが無効になります。

多くのクラウド コンピューティングベンダーは、EAV モデルに基づくデータ ストアを提供しています。このモデルでは、任意の数の属性を特定のエンティティに関連付けることができます。Roger Jennings は、これらの詳細な比較^[34]を提供しています。Amazon の SimpleDB では、データ型は文字列に限定されており、本質的に文字列ではないデータは、並べ替えなどの操作を実行する場合は、文字列に強制変換する必要があります (たとえば、数値は先頭にゼロを埋め込む必要があります)。Microsoft の Windows Azure Table Storage では、byte[]、bool、DateTime、double、Guid、int、long、string [1] という限られたデータ型のセットが提供されています。Google App Engine [2] は、最も多様なデータ型を提供しています。数値データを int、long、float に分割するだけでなく、電話番号、電子メール アドレス、ジオコード、ハイパーリンクなどのカスタム データ型も定義しています。Google では、メタデータ モデルを作成することで、無効な属性が特定のエンティティ クラスに関連付けられないようにするメタデータを定義できますが、Amazon や Microsoft ではできません。

Google では、SQL のサブセットを使用してデータを操作できます。Microsoft では、LINQプロバイダーによって抽象化された URL ベースのクエリ構文を提供しています。Amazon では、より制限された構文を提供しています。懸念されるのは、結合によって異なるエンティティを組み合わせる組み込みサポートが、現在 (2010 年 4 月) 3 つのエンジンすべてに存在しないことです。このような操作は、アプリケーション コードによって実行する必要があります。アプリケーション サーバーがベンダーのデータ センターのデータ サーバーと同じ場所にある場合は、これは問題にならないかもしれませんが、2 つが地理的に離れている場合は、大量のネットワーク トラフィックが生成されます。

EAV アプローチは、モデル化される属性が多数かつまばらである場合にのみ正当化されます。キャプチャされるデータがこの要件を満たしていない場合、クラウド ベンダーのデフォルトの EAV アプローチは、真のバックエンド データベース (永続的なデータ ストレージの手段にすぎない) を必要とするアプリケーションには不適合であることがよくあります。従来のデータ モデリング アプローチを使用する既存のデータベース アプリケーションの大部分を EAV タイプのクラウド アーキテクチャに後付けするには、大がかりな作業が必要になります。たとえば、Microsoft は、データベース アプリケーション開発者ベースがそのような労力を費やすことにほとんど消極的であることに気付きました。そのため、2010 年に Microsoft は、クラウド アクセス可能な本格的なリレーショナル エンジンであるプレミアム サービスである SQL Server Azure を開始しました。これにより、わずかな変更のみで既存のデータベース アプリケーションを移植できます。2020 年代初頭の時点で、このサービスでは標準層の物理データベース サイズが最大 8 TB までサポートされ、^[35]「ハイパースケール」および「ビジネス クリティカル」サービスも利用できます。

• 属性値システム
• リンクされたデータ
• リソース記述フレームワーク(RDF)
• セマンティックウェブ
• トリプルストア
• ゆっくりと変化する次元
• ダトミック