1

次の db-schema があります。

FILE、GROUP、およびBLOCKは、XML ファイルのオブジェクト構造を表します。 FILEはルートです。 GROUPにはFILEへの FK があります。 BLOCKにはGROUPへの 1 つの FK とUNITへの別の 1 つの FK があります。

UNITは、 FILEのコンテキストで異なるGROUPからの「類似の」BLOCKをグループ化します。

データベースは現在 3NF にあります。それでも、どの UNIT がFILE .id =1に属しているか知りたいです。これを行うには、4 つのテーブルすべてを結合するクエリを作成する必要があります。このスキーマを最適化するために、新しいリレーションUNIT n--FK-->1 FILEを作成できます。それでも、私のクエリは、最適化された db-schema で 2 つのテーブルのみを結合します。そしてここに質問があります: この DB (この新しい FK を含む) はまだ 3 NF にありますか? 理論は何と言っていますか？ 

BLOCK  n--FK-->1  GROUP  n--FK-->1  FILE
 n 
 |
 FK    
 |    
 1  
Unit

また

            +--------+
      +-----|  File  |.....+
      |     +--------+     .
      |                    .
     /|\                  /.\
 +--------+           +--------+
 | Group  |--+     +--|  Unit  |
 +--------+  |     |  +--------+
             |     |
            /|\   /|\
           +---------+
           |  Block  |
           +---------+
4

3 に答える 3

1

提供された情報から、これは真の並列階層であることがわかります。これに基づいて、提案された修正されたスキーマは依然として 3NF に正規化されると思います。

于 2010-09-24T11:07:21.427 に答える
0

あなたの「カラスの足」図は、質問で概説されている他の依存関係をサポートしているとは思いません。FILE と UNIT の 1 対多の関係はどのようにして思いついたのですか?

これらは、あなたが説明する機能的な依存関係です...

  • グループ->ファイル
  • ブロック->グループ
  • ブロック->ユニット

また、上記の属性のそれぞれが、他の機能依存関係の左側に表示されないいくつかの追加属性を機能的に決定すると仮定します。これらは次のとおりです。

  • FILE -> その他のファイル属性
  • GROUP -> 他のグループ属性
  • ブロック-> 他のブロック属性
  • ユニット-> 他のユニット属性

上記の関数依存関係から一連の 3NF 関係を構築すると、次のようになります。

  • FileRelation: ( FILE、その他のファイル属性)
  • GroupRelation: ( GROUP、FILE、その他のグループ属性)
  • UnitRelation: ( UNIT , other-unit-attributes)
  • BlockRelation: ( BLOCK , GROUP , UNIT , other-block-attributes)

これは、あなたが説明したこととほぼ一致しています。

特定のFILEに関連するUNITインスタンスを決定 するには、 FileRelation をFILEの GroupRelation に結合し、次に GroupRelation をGROUPの BlockRelation に結合し、次に BlockRelation をUNITの UnitRelation に結合する必要があります。

UNITからFILEへの直接マッピングを提供する新しい関係をモデルのどこかに挿入することで、この複数テーブルの結合を回避したいと考えています。このような関係は、関数依存を意味します。

  • ユニット->ファイル

これは、「クロウズ フット」図に追加したビットのように見えます。これを追加すると、論理的な矛盾が生じます。元のスキーマは、複数のFILEインスタンスに関連する特定のUNITを持つことをサポートしています。次のように:

  • ファイル関係(F1, ...)
  • ファイル関係(F2, ...)
  • グループ関係(G1、F1、...)
  • グループ関係 (G2、F2、...)
  • ブロック関係(B1、G1、U1、...)
  • ブロック関係(B2、G2、U1、...)
  • UnitRelation(U1, ...)

UNIT インスタンス U1 は、FILE インスタンス F1 および F2 に関連しています。この状況を考えると、UNIT -> FILE機能依存関係をサポートできないか、機能依存関係の元のセットが不完全であり、スキーマが 3NF にありません。

この時点で、実世界がFILE -> UNIT 依存関係をサポートしているかどうかを解決する必要があります。存在する場合、元のモデルは 3NF ではなく、スキーマをもう少し手直しする必要があります。依存関係がサポートされていない場合は、次のように言えます。

  • FILE、UNIT ->なし

および対応する関係:

  • ファイルユニット: (ファイル、ユニット)

そのコンテンツは既存のテーブルの機能依存関係から派生する可能性があるため、非正規化です。

================================================== ===============================

編集

この回答および他の回答に対する多くのコメントに基づいて、次のように見えます。

  • ユニット->ファイル

は真の機能依存性、機能依存性です:

  • ブロック->ユニット

間違っていませんが、冗長でなければなりません。このモデルの正しい 3NF 関係セットは次のようになると思います。

  • FileRelation: ( FILE、その他のファイル属性)
  • GroupRelation: ( GROUP、FILE、その他のグループ属性)
  • UnitRelation: ( UNIT、FILE、その他のユニット属性)
  • BlockRelation: ( BLOCK , GROUP , other-block-attributes)

UNIT外部キーが BlockRelation から削除されていることに注意してください。これは、UNIT -> FILE FD が冗長になったためです。( BLOCK , UNIT ) 関係は、UnitRelation をFILE の FileRelation に結合し、次に FileRelation をFILEの GroupRelation に結合し、次に GroupRelation をGROUPの BlockRelation に結合することによって形成されます。

元のスキーマは、 UNIT -> FILEという機能依存関係が明示されていないため、3NF にはありませんでした。上記の提案された関係のセットは 3NF にあります。

注: スキーマを正規化するときは、すべての機能依存関係を前もって述べる必要があります。1つ欠けると全体像が変わる可能性があります！

于 2010-09-23T15:04:13.223 に答える
0

変更を加える前に、UNIT テーブルがスキーマにどのように適合するかは明確ではありません。

明らかに、変更を行った後、どのユニットがファイルに属しているかを知るために必要なことは、FILE テーブルと UNIT テーブルを結合することだけです。

すべての機能依存関係がキー、キー全体、およびキーだけによって決定される場合 (Codd を助けてください)、テーブルは 3NF にあるため、スキーマをその観点から見る必要があります。

入手可能な情報を考えると、ほとんどの場合、テーブルはすべて 3NF (および BCNF、4NF と 5NF の AFAICT) にあります。

于 2010-09-23T13:10:32.503 に答える