Loading article…
エンティティ属性値モデル（EAV）は、実行時の使用パターンが任意であったり、ユーザーによって変動したり、固定設計では予測不可能な状況を想定し、疎な（またはアドホックな）プロパティ値またはデータ値を効率的に格納するために最適化されたデータモデルです。このユースケースは、定義済みのプロパティタイプの大規模または豊富なシステムを提供するアプリケーションを対象としており、これらのプロパティタイプは幅広いエンティティセットに適していますが、通常、特定のエンティティに対してインスタンス化（または永続化）されるのは、これらのうちのごく一部のみです。したがって、このタイプのデータモデルは、疎行列という数学的概念に関連しています。EAVは、オブジェクト属性値モデル、垂直データベースモデル、オープンスキーマとも呼ばれます。
このデータ表現は、空でない値のみを格納する疎行列を格納する、スペース効率の良い方法に似ています。EAVデータモデルでは、各属性と値のペアはエンティティを記述する事実であり、EAVテーブルの行には単一の事実が格納されます。EAVテーブルはしばしば「長くて細い」と表現されます。「長い」とは行の数を指し、「細い」とは列の数が少ないことを指します。
データは3つの列として記録されます。
汎用的な臨床記録をリレーショナルデータベースでどのように表現するかを考えてみましょう。明らかに、数千もの列を持つテーブル（またはテーブルのセット）を作成することは現実的ではありません。なぜなら、列の大部分がNULLになるからです。さらに複雑なことに、患者の経過を追跡する縦断的な医療記録では、同じパラメータに複数の値が存在する可能性があります。たとえば、子供の身長と体重は、子供の成長に伴って変化します。最後に、臨床所見の範囲は拡大し続けます。たとえば、新しい病気が出現したり、新しい検査法が考案されたりします。これには、列の継続的な追加とユーザーインターフェースの継続的な改訂が必要になります。「属性の変動性」という用語は、利用可能な属性のリストやその定義が時間の経過とともに変化する必要がある場合に発生する問題や状況を説明するために使用されることがあります。
以下は、1998年5月1日朝に発熱のため医師の診察を受けた際の臨床所見を示すEAVテーブルの行の一部です。山括弧で囲まれたエントリは、他のテーブルのエントリへの参照です。ここでは、理解を容易にするため、エンコードされた外部キー値ではなくテキストとして表示しています。この例では、値はすべてリテラル値ですが、定義済みの値リストにすることもできます。後者は、可能な値が限られていることがわかっている場合（つまり、列挙可能な場合）に特に役立ちます。
以下の例は、肺炎患者に見られる可能性のある症状や所見を示しています。
上述のEAVデータは、スーパーマーケットのレシートの内容（データベースの売上明細テーブルに反映されるもの）に相当します。レシートには、顧客が購入した可能性のあるすべての商品ではなく、実際に購入した商品の詳細のみが記載されています。特定の患者の臨床所見と同様に、レシートは本質的に疎なデータを簡潔に表現したものです。
行モデリングとは、ある事象（この場合は販売取引）に関する事実を、複数の列ではなく複数の行として記録する、標準的なデータモデリング手法です。行モデリングとEAV（行モデリングの一般化とみなせる）の違いは以下のとおりです。
臨床データリポジトリにおいても、行モデリングは数多くの用途で活用されています。検査結果は通常数値データであるか、数値的に符号化できるため、検査サブスキーマは一般的にこの方法でモデル化されます。
標準的な行モデリングを超えてEAV（拡張可能値）を使用する必要がある状況は以下のとおりです。
特定の（「ハイブリッド」）クラスには、非スパース（すべてのインスタンスまたはほとんどのインスタンスに存在する）属性と、非常に変動が大きくスパースな属性があります。後者はEAVモデリングに適しています。たとえば、複合企業が製造する製品の説明は製品カテゴリによって異なります。たとえば、電球のブランドを説明するために必要な属性は、医療画像診断装置を説明するために必要な属性とはかなり異なりますが、どちらにも包装単位や単価などの共通属性があります。
臨床データにおいては、エンティティは通常、前述のように臨床イベントです。より汎用的な設定では、エンティティは「オブジェクト」テーブルへの外部キーであり、データベース内のすべての「オブジェクト」（物）に関する共通情報（ 最低限、推奨される名前と簡単な説明、およびそれが属するエンティティのカテゴリ／クラス）を記録します。このテーブル内のすべてのレコード（オブジェクト）には、機械生成されたオブジェクトIDが割り当てられます。
「オブジェクトテーブル」方式は、ローレンス・リバモア研究所のトム・スレザック氏らが染色体19データベースのために開発したもので、現在ではほとんどの大規模バイオインフォマティクスデータベースで標準となっています。オブジェクトテーブルを使用するからといって、EAV設計を併用する必要はありません。従来型のテーブルを使用して、各オブジェクトのカテゴリ固有の詳細情報を保存することも可能です。
中央オブジェクトテーブルの主な利点は、オブジェクトの同義語とキーワードをまとめた補助テーブルを用意することで、システム全体にわたってGoogleのような標準的な検索メカニズムを提供できる点です。これにより、ユーザーはまずそのオブジェクトが属するカテゴリを指定することなく、関心のあるあらゆるオブジェクトに関する情報を見つけることができます。（これは、バイオサイエンスシステムにおいて特に重要です。「アセチルコリン」のようなキーワードは、神経伝達物質である分子そのもの、あるいはそれが結合する生物学的受容体のどちらかを指す可能性があるからです。）
EAVテーブル自体では、これは単なる属性IDであり、前述のとおり属性定義テーブルへの外部キーです。ただし、属性関連情報を含むメタデータテーブルは通常複数存在し、これらについては後ほど説明します。
上記の EAV データ例のように、すべての値を文字列に強制変換すると、構造は単純になりますが、拡張性に欠けます。値を使って何らかの処理を行うには、常にデータ型の相互変換が必要となり、EAV テーブルの値列にインデックスを作成しても実質的に役に立ちません。また、画像などの大きなバイナリデータをBase64エンコード形式で、小さな整数や文字列と同じテーブルに格納するのは不便です。そのため、大規模なシステムでは、データ型ごとに個別の EAV テーブルを使用し (バイナリラージオブジェクト(BLOB) を含む)、特定の属性のメタデータによって、そのデータが格納される EAV テーブルが識別されます。このアプローチは、ユーザーが操作する特定のクラスまたはフォームの属性メタデータが少量であるため、メモリに容易にキャッシュできるため、実際には非常に効率的です。ただし、属性のデータ型が変更された場合は、データをあるテーブルから別のテーブルに移動する必要があります。
EAV は、知識表現の汎用的な手段として、「関連リスト」（属性と値のペア）の概念から始まりました。今日では一般的に使用されているこれらは、最初にLISP言語で導入されました。[ 1 ]属性と値のペアは、構成ファイル（属性 = 値 のような単純な構文を使用）など、さまざまなアプリケーションで広く使用されています。データベース以外の EAV の使用例としては、現在Apache Foundationが管理し、自然言語処理などの分野で使用されている標準であるUIMA (Unstructured Information Management Architecture) があります。テキストを分析するソフトウェアは通常、セグメントにマークアップ (「注釈」) します。UIMA チュートリアルで提供されている例は、ドキュメントに対して固有表現認識(NER) を実行するプログラムで、テキストセグメント「President Bush」に注釈-属性-値のトリプル(Person, Full_Name, "George W. Bush")を注釈として付けます。[ 2 ]このような注釈は、データベース テーブルに格納できます。
EAVはAVペアと直接的な関連はないものの、ステッドとハモンドは任意に複雑なデータの永続的な保存にEAVを使用することを最初に考案した人物であると思われる。[ 3 ] EAVを採用した最初の医療記録システムは、レゲンストリーフ電子医療記録（クレメント・マクドナルドが主導した取り組み）[ 4 ] 、ウィリアム・ステッドとエド・ハモンドのTMR（医療記録）システム、そしてユタ州ソルトレイクシティのLDS病院のホーマー・ワーナーのグループによって作成されたHELP臨床データリポジトリ（CDR）であった。[ 5 ] [ 6 ] (レゲンストリーフ・システムは実際には患者-属性-タイムスタンプ-値の設計を採用しており、タイムスタンプを使用することで、特定の患者/属性の値を時系列順に取得することが可能でした。) 1970年代に開発されたこれらのシステムはすべて、EFコッドのリレーショナル・データベース・モデルに基づく商用システムが利用可能になる前にリリースされましたが、HELPはその後ずっと後にリレーショナル・アーキテクチャに移植され、3M社によって商用化されました。(コッドの画期的な論文は1970年に発表されましたが、その数学的な表現が多用されていたため、コンピュータ科学の専門家以外の人々にとって理解しにくく、結果としてIT業界やソフトウェアベンダーの間でのモデルの普及が遅れるという残念な結果となりました。IBMでコッドの同僚であったクリストファー・J・デイトが、これらのアイデアを分かりやすい言葉に翻訳し、その威力を示す簡単な例を添えたことは、非常に大きな貢献でした。)
コロンビア・プレズビテリアン医療センターのグループが、リレーショナルデータベースエンジンをEAVシステムの基盤として使用した最初のグループでした。[ 7 ]
Nadkarniらによるオープンソースの臨床試験データ管理システムTrialDBは、DBMSデータタイプごとに1つずつ、複数のEAVテーブルを使用した最初のシステムでした。[ 8 ]
主にLuis MarencoとPrakash Nadkarniによって設計されたEAV/CRフレームワークは、オブジェクト指向の原則をEAVに重ね合わせたものであり、[ 9 ] Tom Slezakのオブジェクトテーブルアプローチ（前述の「エンティティ」セクションで説明）に基づいて構築されています。一般公開されている神経科学データベースであるSenseLabは、EAV/CRフレームワークを使用して構築されています。
「EAVデータベース」という用語は、データの大部分がEAV（拡張現実）としてモデル化されているデータベース設計を指します。しかし、「EAVベース」と称されるデータベースであっても、システム内には従来型のリレーショナルテーブルが存在する場合があります。
前述のとおり、EAVモデリングは、属性が多数かつ疎である臨床所見などのデータカテゴリに適しています。これらの条件が満たされない場合は、標準的なリレーショナルモデリング（つまり、属性ごとに1つの列）が望ましいです。EAVを使用することは、常識や優れたリレーショナル設計の原則を放棄することを意味するものではありません。臨床記録システムでは、患者の人口統計情報や請求に関するサブスキーマは通常、従来の方法でモデル化されます。（ほとんどのベンダーのデータベーススキーマは独自仕様ですが、米国退役軍人省（VA）の医療システム全体（退役軍人保健局（VHA）として知られる）で使用されているシステムであるVistA [ 10 ]はオープンソースであり、そのスキーマは容易に検査できますが、リレーショナルデータベースではなくMUMPSデータベースエンジンを使用しています。）
後述するように、EAV データベースは、サポートメタデータを含む多数のサポートテーブルがなければ基本的に保守できません。メタデータテーブルは通常、EAV テーブルの少なくとも 3 倍以上の数があり、通常は標準的なリレーショナルテーブルです。[ 8 ] [ 9 ]メタデータテーブルの例としては、前述の属性定義テーブルがあります。
単純なEAV設計では、データベースエンジンから見ると、属性の値は単純なデータ型またはプリミティブデータ型です。しかし、非常に多様なデータを表現するために使用されるEAVシステムでは、特定のオブジェクト（クラスインスタンス）がサブ構造を持つ可能性があります。つまり、その属性の一部が他の種類のオブジェクトを表し、それらのオブジェクトもまた、任意の複雑さのレベルでサブ構造を持つ可能性があります。たとえば、自動車にはエンジン、トランスミッションなどがあり、エンジンにはシリンダーなどのコンポーネントがあります。（特定のクラスに許容されるサブ構造は、後述するように、システムの属性メタデータ内で定義されます。したがって、たとえば、「ランダムアクセスメモリ」属性は「コンピュータ」クラスには適用できますが、「エンジン」クラスには適用できません。）
サブストラクチャを表現するために、特別な EAV テーブルを組み込みます。このテーブルの値列には、システム内の他のエンティティへの参照 (つまり、オブジェクト テーブルへの外部キー値) が含まれます。特定のオブジェクトに関するすべての情報を取得するには、メタデータの再帰的な走査と、取得されたすべての属性が単純 (アトミック) になった時点で停止するデータの再帰的な走査が必要です。再帰的な走査は、個々のクラスの詳細が従来型で表現されているか EAV 形式で表現されているかに関わらず必要です。このような走査は、たとえば標準的なオブジェクト リレーショナル システムで実行されます。実際には、ほとんどのクラスで再帰レベルの数は比較的少ない傾向があるため、再帰によるパフォーマンスの低下は、特にオブジェクト ID のインデックス付けの場合、わずかです。
EAV/CR (EAV with Classes and Relationships) [ 11 ] [ 12 ] [ 13 ]は、複雑なサブストラクチャをサポートするフレームワークを指します。その名称はやや誤解を招く可能性があります。EAV システムの研究から派生したものではありますが、実際には、属性が疎か密かに関わらず、そのようなシステムのクラスの多く、あるいはほとんどは、標準的な関係形式で表現される可能性があります。EAV/CR の真の特長は、非常に詳細なメタデータです。このメタデータは、クラスごとにユーザーインターフェイスコードを記述することなく、個々のクラスへのブラウジングインターフェイスの自動生成をサポートするのに十分なほど豊富です。このようなブラウザーインターフェイスの基盤は、まずメタデータを参照し、メタデータ情報を使用してデータテーブルに対する一連のクエリを生成することで、オブジェクトのクラスに依存しない動的な SQL クエリのバッチを生成できることです。これらのクエリの一部は、任意に再帰的になる可能性があります。このアプローチは、オブジェクトを一度に1つずつ処理するクエリに適しています。例えば、Webベースのブラウジングインターフェースでは、オブジェクトの名前をクリックすると、そのオブジェクトの詳細が別のページに表示されます。オブジェクトのクラスに関連付けられたメタデータには、個々の属性のキャプション、表示順序、グループ化方法などが含まれているため、オブジェクトの詳細の表示も容易になります。
EAV/CRへのアプローチの一つとして、列にJSON構造を持たせることで、必要なクラス構造を実現する方法があります。例えば、PostgreSQLはバージョン9.4以降、JSONバイナリ列（JSONB）をサポートしており、JSON属性のクエリ、インデックス作成、結合が可能になっています。
ヴァンダービルト大学医療情報学科の元学科長であるダニエル・マシス教授の言葉を借りれば、EAVを扱う際の課題は、EAVデータベースでは「物理スキーマ」（データの格納方法）が「論理スキーマ」 （ユーザーや統計パッケージなどの多くのソフトウェアアプリケーションが認識する方法、つまり個々のクラスに対応する従来の行と列）とは根本的に異なるという事実から生じます。（EAVテーブルは概念的にリンゴ、オレンジ、グレープフルーツ、チャプスイを混ぜ合わせたようなものなので、市販の標準ソフトウェアを使用してデータを分析する場合、ほとんどの場合、そのサブセットを列形式に変換する必要があります。[ 14 ]この変換プロセスはピボットと呼ばれ、別途議論するほど重要です。）
メタデータは、ユーザーが物理的なスキーマではなく論理的なスキーマに基づいてシステムとやり取りできるようにする、いわば手品のような役割を果たします。ソフトウェアは、データ表示、対話型検証、一括データ抽出、アドホッククエリなど、さまざまな操作においてメタデータを継続的に参照します。メタデータは、システムの動作をカスタマイズするためにも使用できます。
EAVシステムは、データの物理的および論理的な構造の単純さを犠牲にして、メタデータの複雑さを高めています。メタデータは、標準的なデータベース設計におけるデータベース制約や参照整合性の役割を担っています。このようなトレードオフは一般的に有益です。なぜなら、本番システムの典型的な混合スキーマでは、従来のリレーショナルテーブルのデータも、自動インターフェース生成などの機能の恩恵を受けることができるからです。メタデータの構造は十分に複雑であるため、データベース内に独自のサブスキーマを構成します。データテーブルのさまざまな外部キーは、このサブスキーマ内のテーブルを参照します。このサブスキーマは標準的なリレーショナルであり、制約や参照整合性などの機能が最大限に活用されています。
メタデータの内容が、意図したシステム動作に合致していることは極めて重要であり、その正確性を確保するためには、EAVシステムを構築する際、問題領域（例えば臨床医学）に精通しているものの、必ずしもプログラマーではないチームメンバーが使用できるメタデータ編集用のユーザーインターフェースの構築に、相当な設計努力を費やす必要がある。（歴史的に見ると、リレーショナルデータベース以前のTMRシステムが、本拠地以外の施設で採用されなかった主な理由の一つは、すべてのメタデータが直感的でない構造の単一ファイルに保存されていたことにある。このファイルの内容を変更してシステム動作をカスタマイズし、システムを破損させないようにすることは非常に繊細な作業であったため、システム開発者自身しかその作業を任せられなかった。）
EAVシステムがRDFを介して実装されている場合、RDFスキーマ言語を使用してこのようなメタデータを表現するのに便利です。このスキーマ情報は、EAVデータベースエンジンによって使用され、最高の効率を実現するために内部テーブル構造を動的に再編成することができます。[ 15 ]
メタデータに関する最後の注意点：
検証、表示、およびグループ化のメタデータにより、データ閲覧と対話型編集の両方に対応する自動ユーザーインターフェイス生成をサポートするコードフレームワークの作成が可能になります。Web を介して提供される本番システムでは、EAV データの検証タスクは、基本的にバックエンド/データベース層 (このタスクに関して無力) からミドル/Web サーバー層に移行されます。バックエンドでの検証は、テーブルへの直接データ入力を試みることで不正操作を行うことが不可能なため常に理想的ですが、汎用フレームワークによるミドル層での検証も十分に実用的です。ただし、フレームワークを最初に構築するには、かなりのソフトウェア設計作業が必要になります。個々のニーズに合わせて研究および変更できるオープンソースのフレームワークが利用可能であれば、車輪の再発明を避けるのに大いに役立ちます。
（このセクションの最初の部分は、Central誌に掲載されたDinu/Nadkarniの参考論文[ 18 ]の要約であり、より詳細な情報についてはそちらを参照してください。）
EAVモデリングは、「汎用データモデリング」または「オープンスキーマ」という別の用語で呼ばれることもあり、高度なデータモデラーにとって長年標準的なツールとなっています。しかし、他の高度な技術と同様に、諸刃の剣となる可能性があり、慎重に使用する必要があります。
また、EAVを採用しても、同じデータベーススキーマ内で従来のリレーショナルデータベースモデリング手法を採用することは可能です。CernerなどのRDBMSに依存するEMRでは、臨床データサブスキーマにEAV手法を採用していますが、スキーマ内のテーブルの大部分は実際には従来の手法でモデリングされており、属性は行ではなく個々の列として表現されています。
実際、EAVシステムのメタデータサブスキーマのモデリングは、メタデータのさまざまなコンポーネント間の相互関係があるため、従来のモデリングに非常に適しています。たとえば、TrialDBシステムでは、スキーマ内のメタデータテーブルの数はデータテーブルの約10倍です。メタデータの正確性と一貫性はEAVシステムの正しい動作に不可欠であるため、システム設計者は、RDBMSエンジンをゼロから開発するのではなく、参照整合性やプログラマブル制約など、RDBMSが提供するすべての機能を最大限に活用したいと考えています。その結果、EAV設計をサポートする多数のメタデータテーブルは、通常、第3正規関係形式になっています。
商用電子カルテシステム（EHR）では、診断、実施された外科手術、臨床検査結果などのデータクラスに対して行モデリングを使用し、これらは別々のテーブルに分離されます。各テーブルでは、「エンティティ」は患者IDと診断が行われた日時（または手術や臨床検査が実施された日時）の複合体です。属性は、統制語彙（診断の場合はICD-10 、外科手術の場合はCurrent Procedural Terminologyなど）と値属性のセットを含む、特別に指定されたルックアップテーブルへの外部キーです。（たとえば、臨床検査結果の場合、測定された値、それが正常範囲、低値範囲、高値範囲のいずれであるか、検査を実施した担当者のID、検査が実施された日時などを記録することができます。）前述のように、これは完全なEAVアプローチではありません。特定のテーブルの属性のドメインが制限されているためです。これは、スーパーマーケットの売上テーブルの製品IDのドメインが製品テーブルの製品のドメインに制限されるのと同様です。
しかし、標準的な用語集で必ずしも定義されていないパラメータに関するデータを取得するために、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トリプルは、オブジェクト、プロパティ、および値で構成されます。
ジョン・ベントレーの著書「効率的なプログラムの書き方」の最後に、著者は、一般的にコードをより効率的にすると、理解や保守が難しくなるため、パフォーマンスの問題があることを最初に確認し、コード プロファイリングなどの手段でボトルネックの正確な場所を特定しない限り、急いでコードを修正してはいけないと警告しています。そうしたら、より速く実行する必要がある特定のコードのみを変更します。同様の考慮事項は EAV モデリングにも当てはまります。従来の関係モデリングが事前に扱いにくいことがわかっているサブシステム(臨床データ領域など)、またはシステムの進化中に重大な保守上の課題をもたらすことが判明したサブシステムにのみ EAV を適用します。たとえば、データベースの第一人者 (現在は Oracle Corporation のコア テクノロジー担当副社長) の Tom Kyte [ 19 ]は、従来のビジネス シナリオで EAV を採用することの欠点を正しく指摘し、単なる「柔軟性」は EAV を採用するための十分な基準ではないと指摘しています。 （しかし、彼はEAVはあらゆる状況で避けるべきだという包括的な主張をしているが、Oracleのヘルスサイエンス部門自体は、商用システムであるClinTrial [ 20 ]とOracle Clinical [ 21 ]で臨床データ属性をモデル化するためにEAVを使用している。 ）
EAVの最大の弱点は、大量のEAVデータを扱うのが難しい点です。多くの場合、同じデータの列形式表現と行形式またはEAV形式の表現との間で、一時的または恒久的に相互変換を行う必要があります。これは手動で行うとエラーが発生しやすく、CPU負荷も高くなります。属性メタデータと属性グループ化メタデータを利用する汎用フレームワークは、前者の制限には対処しますが、後者の制限には対処しません。これらのフレームワークの使用は、従来のリレーショナルデータとEAVデータが混在する混合スキーマの場合にほぼ必須となります。このような場合、エラー率が非常に高くなる可能性があるためです。
変換操作はピボットと呼ばれます。ピボットはEAVデータだけでなく、あらゆる形式の行モデルデータにも必要です。（例えば、スーパーマーケットの販売データを処理して、特定の商品を購入した顧客が他に購入する可能性が高い商品を特定するために広く使用されているアソシエーション分析のためのAprioriアルゴリズムの実装では、最初のステップとして行モデルデータをピボットします。）多くのデータベースエンジンには、ピボットを容易にするための独自のSQL拡張機能があり、Microsoft Excelなどのパッケージもピボットをサポートしています。ピボットが必要となる状況については、以下で説明します。
しかし、EAVデータモデルの構造は、関係除算に最適な候補です（関係代数を参照）。適切なインデックス戦略を使用すれば、10億行のEAVテーブルでも数百ミリ秒未満の応答時間を実現できます。Microsoft SQL Server MVPのPeter Larsson氏は、ラップトップでこれを実証し、ソリューションを一般に公開しました。[ 22 ]
当然のことながら、どのようなアプローチを採用しても、特定の種類のクエリにおいては、EAV のクエリは標準的な列指向リレーショナル データのクエリほど高速ではありません。これは、疎行列の要素へのアクセスが、メイン メモリに完全に収まる非疎行列の要素へのアクセスほど高速ではないのとよく似ています。（リンク リストなどの構造を使用して表現される疎行列では、特定の XY 位置にある要素にアクセスするためにリストを走査する必要がありますが、2 次元配列として表現される行列の要素へのアクセスは、高速な CPU レジスタ操作を使用して実行できます。）しかし、解決しようとしている問題に対して EAV アプローチを正しく選択したのであれば、これは支払うべき代償です。この点において、EAV モデリングは、スペース（およびスキーマの保守）と CPU 時間のトレードオフの一例と言えます。
元々は Maier、Ullman、Vardi によって提唱された[ 23 ] 、 「ユニバーサル データ モデル」（UDM）は、すべてが単一の巨大な「ユニバーサル テーブル」に格納されているという錯覚を作り出すことで、経験の浅いユーザーによる複雑な関係スキーマのクエリを簡素化することを目指しています。これは、テーブル間の関係を利用することで実現され、ユーザーはどのテーブルにどの属性が含まれているかを気にする必要がありません。しかし、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ベースのフレームワークではミドルティアとブラウザベースのコードで実行する必要がある）の問題を解決できますが、次のような欠点があります。
上記の欠点はすべてメタデータとアプリケーションコードのレイヤーを作成することで解消できますが、そうするとフレームワークを作成する必要がないという本来の「利点」が失われてしまいます。実際、どのストレージ方式を使用しても、疎なデータ属性を堅牢にモデル化することは、データベースとアプリケーションの設計において困難な問題です。しかし、Sarkaの研究[ 26 ]は、データストレージ層に型固有のリレーショナルEAVテーブルの代わりにXMLフィールドを使用することの実現可能性を証明しており、エンティティあたりの属性数が控えめな場合（例えば、異なる製品タイプの可変製品属性など）には、XMLベースのソリューションはEAVテーブルベースのソリューションよりもコンパクトになります。（XML自体は、リレーショナルテーブルではなく構造化テキストに基づいているものの、属性値データの表現手段とみなすことができます。）
ツリー構造データの表現には、XML、JSON 、ネストセットモデルなどの他の形式など、リレーショナルデータベースにおいて他にもいくつかの方法が存在する。一方、データベースベンダーは、 IBM Db2のようにXMLデータをテーブルとは別にXMLとして格納し、 SQLステートメントの一部としてXPathクエリを使用するなど、データ構造やクエリ機能にJSONとXMLのサポートを組み込み始めている。また、PostgreSQLでは、インデックス付けやクエリが可能なJSONデータ型[ 28 ]が用意されている。これらの開発は、EAVモデルのアプローチを実現、改善、または代替するものである。
JSONとXMLの用途は、EAVモデルの用途と必ずしも同じではありませんが、重複する部分もあります。XMLは、単一エンティティのデータ量が比較的少ない、任意の階層構造を持つデータに対してEAVよりも適しています。XMLは、データ操作のパフォーマンスに関して、マルチギガバイトレベルまで拡張することを想定していません。XMLは、スパース属性の問題そのものには直接関係していません。また、表現する情報の基盤となるデータモデルがリレーショナル構造に簡単に分解できる場合、XMLは主要なストレージメカニズムとしてよりも、データ交換手段として適しています。前述のとおり、EAVはスパース属性のシナリオに特化して（かつ唯一）適用されます。このようなシナリオの場合、エンティティ、属性、値ごとにインデックスを付け、単純なSQL文で操作できるデータ型固有の属性値テーブルを使用する方が、XMLツリー構造を使用するよりもはるかに拡張性に優れています。前述のGoogle App Engineが厳密に型指定された値テーブルを使用しているのには、それなりの理由があります。
EAV構造データで発生するさまざまな問題に対処するための別のアプローチとして、グラフデータベースを使用する方法があります。これらは、エンティティをグラフまたはハイパーグラフのノードとして、属性をそのグラフのリンクまたはエッジとして表現します。テーブル結合の問題は、 Apache TinkerPop [ 29 ]やOpenCog atomspace パターンマッチング[ 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 値は現在スペースを全く占有しません)、テーブル内のレコードの大部分がその列に NULL 値を持つ場合に便利です。スパース列のインデックスも最適化されます。値を持つ行のみがインデックス化されます。さらに、テーブルの特定の行にあるすべてのスパース列の内容をまとめて単一の XML 列 (列セット) に集約できます。その内容は次の形式になります。[<column-name>column contents </column-name>]*....実際、CREATE TABLE ステートメントの一部としてテーブルに列セットが定義されている場合、その後に定義されたすべてのスパース列は通常、その列に追加されます。この結果、SQL文はSELECT * from <tablename>個々の疎列を返さず、それらすべてを連結して、列セットと同じ名前の単一のXML列を作成します（そのため、仮想的な計算列として機能します）。疎列は、製品情報などのビジネスアプリケーションに便利です。製品情報では、適用可能な属性は製品タイプによって大きく異なる可能性がありますが、製品タイプごとの可変属性の総数は比較的少ないためです。
しかし、この疎属性モデリング手法にはいくつかの制限があり、競合するDBMSは特に自社エンジンに採用しないことを選択している。制限事項は以下のとおりである。
多くのクラウドコンピューティングベンダーは、EAVモデルに基づいたデータストアを提供しており、特定のエンティティに任意の数の属性を関連付けることができます。Roger Jenningsはこれらの詳細な比較を行っています[ 34 ]。AmazonのSimpleDBでは、データ型は文字列に限定されており、ソートなどの操作を実行するには、本来文字列ではないデータを文字列に変換する必要があります（たとえば、数値は先頭にゼロを付加する必要があります）。MicrosoftのWindows Azure Table Storageでは、byte[]、bool、DateTime、double、Guid、int、long、stringといった限られたデータ型が提供されています。Google App EngineGoogleは、最も多様なデータ型を提供しています。数値データをint、long、floatに分類するだけでなく、電話番号、Eメールアドレス、ジオコード、ハイパーリンクなどのカスタムデータ型も定義できます。Googleは、メタデータモデルを作成することで、無効な属性が特定のエンティティクラスに関連付けられるのを防ぐメタデータを定義できますが、AmazonやMicrosoftはそうではありません。
GoogleではSQLのサブセットを使用してデータを操作できます。MicrosoftはLINQプロバイダーを介して抽象化されたURLベースのクエリ構文を提供しています。Amazonはより限定的な構文を提供しています。懸念されるのは、3つのエンジンすべてにおいて、結合による異なるエンティティの結合が組み込まれていないことです（2010年4月現在）。このような操作はアプリケーションコードで実行する必要があります。アプリケーションサーバーとデータサーバーがベンダーのデータセンターに併設されている場合は問題にならないかもしれませんが、両者が地理的に離れている場合は大量のネットワークトラフィックが発生します。
EAV アプローチは、モデル化される属性が多数かつ疎である場合にのみ正当化されます。取得されるデータがこの要件を満たさない場合、クラウド ベンダーのデフォルトの EAV アプローチは、真のバックエンド データベース (単なる永続的なデータ ストレージ手段ではなく) を必要とするアプリケーションには不適合となることがよくあります。従来のデータ モデリング アプローチを使用する既存のデータベース アプリケーションの大部分を EAV タイプのクラウド アーキテクチャに改造するには、大規模な手術が必要になります。たとえば、Microsoft は、データベース アプリケーション開発者のベースがそのような労力を投資することに非常に消極的であることを発見しました。そのため、2010 年に、Microsoft は、クラウドからアクセス可能な本格的なリレーショナル エンジンである、プレミアム オファリングである SQL Server Azure をリリースしました。これにより、既存のデータベース アプリケーションをわずかな変更で移植できます。2020 年代初頭の時点で、このサービスでは、標準ティアの物理データベース サイズが最大 8TB まで対応しており、[ 35 ]「ハイパースケール」および「ビジネス クリティカル」オファリングも利用可能です。