リレーショナル モデリング ツールを使用して、論理モデルまたは第 3 正規形の論理モデルを EAV を使用するデータベースにマッピングする方法は?
2 に答える
EAV は非リレーショナル設計です。EAV ではリレーションシップに失敗するため、通常のフォームを 実現できません。
EAV はInner-Platform Effectアンチパターンの一例です。
多くの属性が必要な場合は、XMLの blobにシリアル化し、その XML をCLOB
列に格納することを検討できます。
リレーショナルでは、EAV (属性値ペアまたは名前と値のペアとも呼ばれます) を持つことができます。かなり抽象的なデータ モデルを使用します。それについて説明する前に、いくつかの注意事項があります。クエリが難しく、うまく機能しません。EAV は、監査テーブルのリレーショナルでよく使用されます。EAV には、1 つの列のビフォア イメージ (変更前) が格納されます。変更された 1 つの列を 1 つずつ格納します。5 つの属性が変更された場合、5 つの行が EAV に格納されます。さらに、EAV の自然な主キーが大きくなる可能性があるため、EAV の代わりにミラー テーブルが使用されることがよくあります。
EAV は、論理データ モデリングとリレーショナルで作成できます。これは、3 つの関連するエンティティまたはテーブルで実行できます。
- 基本エンティティ (顧客など)。列ファミリーに似ています。
- 純資産額などの属性とその特性を説明する「タイプ」エンティティ
- 基本エンティティのインスタンスに属性を割り当て、それに値を与える「値」エンティティ。
基本エンティティは、さまざまな特性を持つエンティティです。
「タイプ」エンティティは、タイプ コードによって識別され、説明やその他のドメイン特性を含む単なるコード テーブルです。ドメインは、データ型、長さ、意味、および測定単位などを指します。これは、属性をコンテキスト外 (つまり、割り当てられていない) で表します。例として、Net Worth Amount があります。これは小数点以下 2 桁の 8 桁の数値であり、右揃えであり、その説明は「流動的および非流動的な金額を含む顧客の財務的価値の合計を表す値」です。
「値」エンティティは、顧客 ID と属性タイプ コード [両方の外部キー] によって識別される関連エンティティまたはテーブルであり、純資産額タイプを顧客に割り当て、次のような値を与える値属性を持ちます。 「200万ドル」多くの場合、値列にはフィールドなどの一般的な名前が付けられます。
ただし、SQL では、名前と値のペアを照会するのはやや難しく、一般的にうまく機能しません。「値」エンティティに「フィールド」という属性があるとします。これは文字列です。SQL は通常、結果セットのヘッダーに列名を使用します。フィールドに純資産があるとします。ただし、表示される場合、ヘッダーは Net Worth ではなく「Field」と呼ばれます。フィールドは列の実際の名前です。目的のヘッダーを取得するには、高度な SQL が必要です。この問題は、「タイプ」エンティティと「値」エンティティを 1 つに非正規化することで対処できます。3 つのテーブルの代わりに、ベース テーブルと値テーブルの 2 つ (1 対多) を使用します。実際、これが基本的に Cassandra のやり方です。列ファミリーの列は、完全に平坦化された属性と値のペアです。リレーショナルで非正規化しても、「フィールド」は
3 つのエンティティをリレーショナルの 1 つのテーブルにフラット化 (非正規化) することもできますが、冗長性の問題があります: 顧客 ID[FK]、属性タイプ コード[FK]、顧客ベース属性、属性タイプ属性、フィールド (値)。私はそれを勧めているわけではありません。言ってるだけ。
データ モデリングの黎明期、データ モデラーは EAV を好んで使用していました。EAV はエレガントで柔軟なソリューションのように見えたからです。DBA が EAV を手に入れるまでは。その結果、EAV は論理モデルに使用されることがありますが、物理モデルでは完全に非正規化する必要があります。完全に非正規化すると、Cassandra に非常に似ています。上記の問題で、論理と物理の両方でEAVを使用したことがあります。これらのコメントにグラフィックを追加する方法がわかりません。または、イラストを含めます。