0

次の表...：

CREATE TABLE v (
    height int,
    width int,
    depth int,
    volume int,
    PRIMARY KEY (height, width, depth);
)

...は、volumeという名前の3つの変数の関数の入力と出力を格納するために使用できますvolume(height, width, depth) = height * width * depth。

ここではどのようなデータモデルを使用していますか？それはEntity-Attribute-Valueですか？

4

3 に答える 3

2

あなたは数学志向のようです。Codd(Date) がリレーショナル モデルを導入したとき、彼(彼ら) は既存の数学言語を新しい分野に再構築しました。

あなたの場合: value は3つのパラメータの関数である可能性があります: val = f(h,w,d). しかし、「リレーション」(データベース テーブル) の場合は少し異なります。関数は、{h,w,d} が実際にテーブルに存在する場合にのみ定義されます。数学では、関数は R3 ドメイン全体で定義されます。リレーショナル代数では、テーブルのキー ({h,w,d}) は、より制限されたドメイン (または一連のドメインの積) で定義されます。DBMS/SQL の世界のほとんどは、これらの制限に関係しています。(制約、ドメイン制約など) UNIQUE 制約は、おそらく最も基本的な制約です。特定の {h,w,d} を持つタプルが最大で 1 つ存在することを保証します。結果として、関数値は 1 つだけです。. DBMS の人々は、リレーションの非キー フィールドを FK ({h,w,d}} に「機能的に依存する」と呼びます: キーのセットが与えられると、それに対応する行は最大で 1 つ (および最大で 1 つ) "機能値")

EAVは、関連するテーブルの定義を変更することなく、オブジェクトが可変数の属性を持つことを「シミュレート」するためのデータモデルのクラスです。ただし、テーブル レベルでは、属性と値を含む追加のテーブル (実際には 2 つ) を追加するだけです。データ モデリングは、変装したトポロジにすぎません。

于 2012-06-21T22:57:20.127 に答える
0

あなたが示すVテーブルは単なるテーブルです。3 つの部分からなるキーと、キーに完全に依存する 1 つのデータ列があります。ボリュームは、キーにある 3 つのメジャー (およびその他のメジャー) を使用した数式によって導き出されます。ボリュームの機能依存性は、3 つの部分からなる鍵です。属性値のペアではありません。また、通常のフォームにも違反しません。これは、3 つの部分からなるキーと 1 つのデータ列を持つ単なる派生テーブルです。この質問は考えすぎる可能性があります。

于 2012-08-27T03:43:14.827 に答える
0

いいえ、EAVモデルではありません。直方体の寸法をモデリングし、ボリュームも保存することを選択しているだけです。現実の世界では、おそらく測定単位といくつかのチェック制約を含めるでしょう。

CREATE TABLE v (
    height_cm int not null check (height_cm > 0),
    width_cm int not null check (width_cm > 0),
    depth_cm int not null check (depth_cm > 0),
    volume_cm3 int not null check (volume_cm3 = height_cm * width_cm * depth_cm),
    PRIMARY KEY (height_cm, width_cm, depth_cm)
);

(私はかつて、不適切な構成の委員会によって設計されたリレーショナル db/XML/XSLT 怪物の問題を処理しなければならなかった男の隣で働いていました。ユーザーは、各パッケージの 1 つのディメンションに負の数を指定するだけで、送料を節約できることにすぐに気付きました。)

"volume_cm3" の列を削除すると、表は明らかに 5NF です。（非キー属性はまったくありません。）しかし、列「volume_cm3」とその制約を含めると、これはどのような通常の形式になりますか？まだ5NFですか？

于 2012-06-21T22:54:41.073 に答える