web-dev-qa-db-ja.com

BCNF分解問題についてサポートが必要

私はできる限り迅速かつ簡潔にしていきます。私は現在、データベースの正規化と最適化を学びたいと思っている初心者の開発者なので、フルスタック開発のスキルを向上させることができます。さまざまな種類の機能依存関係を特定できるようにして、最適な/適切なリレーショナルモデル/スキーマを作成できるようにしました。現在、3NFおよびBCNF分解（おそらくNF4？）の割り当てを行っています。苦労しています。

アサインメントには2つのパートがあり、最初のパート1を適切に完了したことは確かですが、パート2については完全に混乱しています。

以下は、LOTSと呼ばれる正規化された関係です。 Prompt for Relation called LOTSDiagram of LOTS relation

パート1は、可能であればリレーションシップをBCNFの形式に分解することでした。これが私の仕事です。 My Decomposed Relations of original LOTS in BCNF

現在のR1関係は、パート2のLOTS関係です。

パート2のプロンプトは次のとおりです。 PART 2

AREA属性にはCOUNTY_NAMEを決定できる一意の値のセットがあるため、新しい機能的な依存関係が導入されるのはAREA-> COUNTY_NAMEであり、LOTS関係は3NFのままになります。新参者の学習を手伝ってくれる人に感謝します。乾杯！

database-designoptimizationnormalizationrelations
1
MacDadddy

課題を解決したので、これ以上追加する必要はありません。しかし、あなたはあなたが

「データベースの正規化と最適化を学びたいので、フルスタック開発のスキルを磨くことができます。」

そして、私は最近、ほとんど屋内で動けなくなっているので、目標を達成するために少し異なる方法を示します。この方法は個人およびビジネスプロジェクトに役立ちますが、db関連の試験や教科書の割り当てにはそれほど役立ちません。

したがって、ここがタスクです。属性を持つrelvar（テーブル）があり、（おそらく）データベースデザイナーと呼ばれる神話上の生き物が機能的な依存関係を提供してくれました。

lots { PROPERTY_ID
     , COUNTY_NAME
     , LOT_NO
     , AREA
     , PRICE
     , TAX_RATE
     }

COUNTY_NAME, LOT_NO -> PROPERTY_ID
PROPERTY_ID -> COUNTY_NAME, LOT_NO
PROPERTY_ID -> COUNTY_NAME, LOT_NO, AREA, PRICE, TAX_RATE
COUNTY_NAME -> TAX_RATE
AREA -> PRICE

アイデアは、これを言語化し、（単純な）述語と関連する制約を書き留めて、ロジックを使用して自然言語で問題を推論できるようにすることです。

単純な述語は、情報を失うことなく分解できません。その一致relvarは6NFにありますです。

[p 1]郡COUNTY_NAMEが存在します。

（c 1.1）郡はCOUNTY_NAMEで識別されます。

county {COUNTY_NAME}  -- p 1
   KEY {COUNTY_NAME}  -- c 1.1

[p 2]郡COUNTY_NAMEにロット番号LOT_NOが存在します。

（c 2.1）ロットはCOUNTY_NAMEとLOT_NOのペアで識別されます。

county_lot {COUNTY_NAME, LOT_NO}  -- p 2
       KEY {COUNTY_NAME, LOT_NO}  -- c 2.1

[p 3]郡COUNTY_NAMEのロット番号LOT_NOには、プロパティ番号PROPERTY_IDが割り当てられています。

（c 3.1）ロットと郡のペアごとに、そのロットと郡のペアに1つのプロパティ番号が割り当てられます。

（c 3.2）プロパティ番号ごとに、そのプロパティ番号が1つのロットと郡のペアに割り当てられます。

property {COUNTY_NAME, LOT_NO, PROPERTY_ID} -- p 3
     KEY {COUNTY_NAME, LOT_NO}              -- c 3.1
     KEY {PROPERTY_ID}                      -- c 3.2 

-- this one can be decomposed to
-- {PROPERTY_ID, COUNTY_NAME} {PROPERTY_ID, LOT_NO}
-- but leaving it as is to simplify.

[p 4]郡COUNTY_NAMEの税率はTAX_RATEです。

（c 4.1）各郡について、その郡は正確に1つの税率を持っています。各税率について、複数の郡がその税率を持っている可能性があります。

county_tax {COUNTY_NAME, TAX_RATE} -- p 4
       KEY {COUNTY_NAME}           -- c 4.1

[p 5] AREAの多くのエリアはPRICEで価格設定されています。

（c 5.1）各ロット領域について、そのロット領域は正確に1つの価格で価格設定されます。各価格について、複数のロット領域がその価格で価格設定される場合があります。

area_price {AREA, PRICE} -- p 5
       KEY {AREA}        -- c 5.1

[p 6]プロパティPROPERTY_IDにAREAのエリアがあります。

（c 6.1）各プロパティは正確に1つの領域で構成されます。各領域では、複数のプロパティがその領域を持つ可能性があります。

property_area {PROPERTY_ID, AREA} -- p 6
          KEY {PROPERTY_ID}       -- c 6.1

この時点で、これらすべてのrelvarは単純な述語を表し、6NFにあります（5NFの場合はp3）。これで、それらをそのまま（論理的には問題ありません）のままにするか、キーに基づいてそれらのいくつかを組み合わせることができますが、5NFのままにすることができます。

county_tax {COUNTY_NAME, TAX_RATE}  -- p 1,   p 4
       KEY {COUNTY_NAME}            -- c 1.1, c 4.1

area_price {AREA, PRICE}  -- p 5
       KEY {AREA}         -- c 5.1

property_ { COUNTY_NAME   -- p 2, p 3, p 6
          , LOT_NO
          , PROPERTY_ID
          , AREA
          }
      KEY {COUNTY_NAME, LOT_NO}  -- c 2.1, c 3.1
      KEY {PROPERTY_ID}          -- c 3.2, c 6.1

最初の2つは6NFにあり、3つ目は5NFにあります。

この方法を理解するには、1NF、6NF、5NF; or 1NFのみ。冗長性とロスレス分解結合が適切に理解されている限り。つまり、述語と制約を明確に定義できる限り、意味がわからなくてもDBを5NFにするができます。

では、relvarが何を意味するのかわからない場合、どうすればrelvarが5NFであることを知ることができますか？簡単です、これはあれこれのNFにあるのではなく、冗長性を削除することです。

冗長性の削除に関する限り、5NFは最終的なNFです。
relvar（テーブル）が5NFにある場合、分解しても冗長性は削除されません。

または（同じ意味）これらの少なくとも1つが成り立つ場合：

  • 冗長性はありません。
  • 冗長性はありますが、分解して削除することはできません。
  • 情報を失わずにテーブルを分解することはできません。
  • テーブルを分解することはできません。

ただ確認する冗長性を推論するときは、述語と制約について推論するnotサンプルデータの数行について。

要約すると、このメソッドは、アルゴリズムまたは関数の依存関係に従って分解するのではなく、初期relvarの述語を単純な述語のセット（6NF relvars）に「分解」してから、それらを合成し、5NFに留まるようにします。
論理および自然言語を使用します。これは、アナリストやビジネスマンと通信する必要がある場合に非常に有利です。

1
Damir Sudarevic