まだ正規化されたDBスキーマですか？データベース

StackOverflow https://stackoverflow.com/questions/3772306

質問

私は次のdbschemaを持っています。

ファイル, グループ と ブロック XMLファイルのオブジェクト構造を表します。ファイル ルートです。グループ fkを持っています ファイル. ブロック 1つのfkを持っています グループ そして、もう1つはfkです 単位.

単位 グループ「同様」 ブロック 異なるものから グループ の文脈で ファイル.

データベースは現在3NFにあります。それでも私はどちらを知りたいです ユニット に属します ファイル.id = 1。これを行うには、4つのテーブルすべてに参加するクエリを作成する必要があります。このスキーマを最適化するために、新しい関係を作成できます 単位 n - fk-> 1 ファイル. 。しかし、私のクエリは、最適化されたDBシーマの2つのテーブルのみに参加します。質問は次のとおりです。このdb（この新しいFK）はまだ3 nfにありますか？理論は何と言っていますか？ 

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

また

            +--------+
      +-----|  File  |.....+
      |     +--------+     .
      |                    .
     /|\                  /.\
 +--------+           +--------+
 | Group  |--+     +--|  Unit  |
 +--------+  |     |  +--------+
             |     |
            /|\   /|\
           +---------+
           |  Block  |
           +---------+
役に立ちましたか？

解決

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

他のヒント

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

明らかに、変更を加えた後、ファイルに属するユニットがファイルとユニットテーブルに参加しているかを知るために必要なことはすべてします。

テーブルは3NFであるため、すべての機能依存関係がキー、キー全体、およびキーだけ（CODDに役立つ）によって決定される場合、その光の中でスキーマを見る必要があります。

利用可能な情報を考えると、おそらくテーブルはすべて3NF（およびBCNF、4NFおよび5NFのAFAICT）にあります。

あなたの「カラスの足」の図は、あなたの質問で概説されている他の依存関係をサポートしているとは思いません。 1：ファイルとユニットの多くの関係をどのように思いついたのですか？

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

  • グループ -> ファイル
  • ブロック -> グループ
  • ブロック -> 単位

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

  • ファイル - >他のファイルアトリビュート
  • グループ - >その他のグループアトリビュート
  • ブロック - >その他のブロックアトリビュート
  • 単位 - > other-unit-attributes

上記の機能的依存関係から3NF関係のセットを構築すると、次のことが得られます。

  • FileRelation：（ファイル, 、他のファイルアトリビュート）
  • grouprelation：（グループ, ファイル, 、他のグループ - アトリビュート）
  • ユニットリレーション：（単位, 、他のユニットアトリビュート）
  • ブロックリレーション：（ブロック, グループ, 単位, 、その他のブロックアトリビュート）

これは、あなたが説明したことにほとんど対応しています。

どちらを決定します 単位 インスタンスは与えられたものに関連しています ファイルGrouprelationのためにFileRelationの結合が必要です ファイル そして、ブロックリレーションに移動します グループ 次に、単位関連にブロックリレーションします 単位.

あなたは、モデルのどこかに新しい関係を挿入することで、このマルチテーブル結合を避けたいと思います。 単位 に ファイル. 。このような関係は、機能的依存関係を意味します。

  • 単位 -> ファイル

これは、「カラスの足」図に追加されたビットのように見えます。これを追加すると、論理的な矛盾が導入されます。元のスキーマは、与えられたものをサポートしています 単位 複数に関連しています ファイル インスタンス。のように：

  • FileRelation（F1、...）
  • FileRelation（F2、...）
  • grouprelation（g1、f1、...）
  • grouprelation（g2、f2、...）
  • ブロックリレーション（B1、G1、U1、...）
  • ブロックリレーション（B2、G2、U1、...）
  • ユニットリレーション（U1、...）

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

この時点で、現実世界がサポートするかどうかを解決する必要があります ファイル -> 単位依存関係かどうか。もしそうなら、元のモデルは3NFではなく、スキーマのもう少し再加工が適切です。依存関係がサポートされていない場合、あなたが言うことができる最善は次のとおりです。

  • ファイル, 単位 -> なし

と対応する関係：

  • fileUnit：（ファイル, 単位)

その内容は、既存のテーブル機能依存関係を介して導出される可能性があるため、非正規化です。

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

編集

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

  • 単位 -> ファイル

真の機能的依存性、機能的依存関係です。

  • ブロック -> 単位

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

  • FileRelation：（ファイル, 、他のファイルアトリビュート）
  • grouprelation：（グループ, ファイル, 、他のグループ - アトリビュート）
  • ユニットリレーション：（単位, ファイル, 、他のユニットアトリビュート）
  • ブロックリレーション：（ブロック, グループ, 、その他のブロックアトリビュート）

に注意してください 単位 外部キーはブロックリレーションから低下しました。これは、 単位 -> ファイル FDはそれを冗長にしました。 （ブロック, 単位）関係は、ユニットリレーションをファイラーレーションに結合することによって形成されます ファイルその後、grouplerationにfilrelation ファイル 次に、ブロックリレーションに移動します グループ.

元のスキーマは、未定の機能依存関係のために3NFにはありませんでした： 単位 -> ファイル. 。上記の提案された関係セットは3NFにあります。

注：スキーマを正規化する場合、すべての機能的依存関係を前もって述べる必要があります。欠けている人は全体像を変えることができます！

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top