1

リレーションを 5 NF に正規化する必要があるかどうかを判断するのに苦労しています。

以下で構成されるすべての重要な関係があるとしましょう。

あいうえお

  • A と B は、A と B を主キーとする別のテーブルからの外部キーです。
  • CはX1、X2、X3の可能性があります
  • D は Y1、Y2、Y3 の可能性があります

この関係で、CとDはお互いの組み合わせです。

サンプルデータ:

  • 1、2、X1、Y2
  • 3、4、X2、Y2
  • 5、6、X1、Y3
  • 7、8、X2、Y1

この関係を次のように正規化することは理にかなっていますか?

  • A、B、C
  • A、B、D
  • CD

C、D を保持する関係がすべての可能な組み合わせを含む場合

4

1 に答える 1

0

(A,B) が関係のキーである場合 (これが星印で示されていると仮定)、C と D の両方がそれぞれ機能的に (A,B) に依存しているため、それは既に 4NF にあります。5NF への分解は、次のようになります。

(A,B,C)
(A,B,D)

それ以上の関係 (C,D) は必要ありません。SQL で簡単にチェックすると、サンプル データについて次のことが確認されます。

create table t1(A,B,C);
create table t2(A,B,D);

insert into t1 values (1,2,'X1'), (3,4,'X2'), (5,6,'X1'), (7,8,'X2');
insert into t2 values (1,2,'Y2'), (3,4,'Y2'), (5,6,'Y3'), (7,8,'Y1');

select * from t1 natural join t2; 

A           B           C           D
----------  ----------  ----------  ----------
1           2           X1          Y2
3           4           X2          Y2
5           6           X1          Y3
7           8           X2          Y1

リレーションに分解することが理にかなっているのかどうかについて: 一般的に、私は常に最大のデータ整合性を保証するリレーショナル デザインを採用します。あなたの場合、4NF から 5NF に移行しても、それ以上の挿入/更新/削除の異常から保護されません。データを水平に分割するだけです。これは、関心の分離という点からは理にかなっているかもしれませんが、データの一貫性の点からは必要ありません。

編集：キーが（A、B、C、D）の場合の議論を追加

(A,B,C,D) がリレーションのキーであり、データのプロジェクト結合依存関係が質問に入力したものである場合 ( R = (A,B,C) * (A,B ,D) * (C,D)、例のデータだけでなく、データの整合性ルールとして)、5NF スキーマはデータの一貫性を強制しますが、元のスキーマはそうではありません (挿入/更新/削除の異常が発生する可能性があります) ）。したがって、論理的な観点からは、5NF スキーマを使用する必要があります。それ以外の場合は、アプリケーション レベルでデータの整合性を強化する必要があります。

いつものように (そして 3NF の場合も)、特定のパフォーマンス要件によってスキーマの非正規化が必要になる場合があります (たとえば、データのクエリ時に結合を保存するため)。ただし、強制されない限り、私は常に最善を尽くします。概念スキーマが可能です。多くの DBMS では、適切な論理リレーショナル設計をあきらめることなく、たとえば適切なインデックスやインクリメンタル マテリアライズド ビューを使用することで、物理レベルでの 5NF 設計のクエリ パフォーマンスを改善することさえできます。しかし、もちろん、ある時点でパフォーマンスやスペース効率のために一貫性を犠牲にする必要があるかもしれません.

于 2013-11-06T22:52:21.757 に答える