web-dev-qa-db-ja.com

簡単な用語での3NFとBCNFの違い（8歳の子供に説明する必要があります）

私は引用を読みました：データはキー[1NF]、キー全体[2NF]に依存し、キー[3NF]以外は何もありません。

しかし、私は3.5NFまたはBCNFと呼ばれるように理解するのに苦労しています。ここに私が理解していることがあります：

  • BCNFは3NFよりも厳密です
  • テーブル内のFDの左側はスーパーキー（または少なくとも候補キー）でなければなりません

では、なぜいくつかの3NFテーブルがBCNFにないのですか？つまり、3NFの引用では、明示的に「キー以外は何もありません」ということは、すべての属性が主キーのみに依存していることを意味しています。結局、主キーは、主キーとして選択されるまで候補キーです。

これまでの私の理解に関して何かおかしなことがあれば、私を修正してください。あなたが提供できる助けをありがとう。

databaserelational-databasedatabase-normalization3nf
141
Arnab Datta

ピザには、正確に3つのトッピングタイプがあります。

  • チーズの一種
  • 肉の一種
  • 野菜の一種

そこで、2つのピザを注文し、次のトッピングを選択します。

Pizza    Topping     Topping Type
-------- ----------  -------------
1        mozzarella  cheese
1        pepperoni   meat
1        olives      vegetable
2        mozzarella  meat
2        sausage     cheese
2        peppers     vegetable

ちょっと待ってください。モッツァレラチーズはチーズにも肉にもなり得ません！そして、ソーセージはチーズではありません！

モザレラalwaysチーズにするには、この種の間違いを防ぐ必要があります。これには別のテーブルを使用する必要があります。そのため、その事実を1か所だけに書き留めます。

Pizza    Topping
-------- ----------
1        mozzarella
1        pepperoni
1        olives
2        mozzarella 
2        sausage
2        peppers

Topping     Topping Type
----------  -------------
mozzarella  cheese
pepperoni   meat
olives      vegetable
sausage     meat
peppers     vegetable

それが、8歳の人が理解できる説明でした。これは、より技術的なバージョンです。

BCNFは、複数の候補キーが重複している場合にのみ3NFとは異なる動作をします。

理由は、YがXのサブセットである場合、機能的な依存関係X -> Yはもちろんtrueであるためです。したがって、候補キーが1つだけで3NFにあるテーブルでは、そのキー以外に機能的に依存する列（キーまたは非キー）がないため、すでにBCNFにあります。

各ピザには各トッピングタイプが1つずつ必要であるため、（ピザ、トッピングタイプ）が候補キーであることがわかります。また、特定のトッピングが同時に異なるタイプに属することはできないことを直感的に知っています。 （Pizza、Topping）は一意である必要があるため、候補キーでもあります。そのため、2つの候補キーが重複しています。

Mozarellaを間違ったトッピングタイプとしてマークした異常を示しました。これが間違っていることはわかっていますが、間違っているルールは、このテーブルのBCNFの有効な依存関係ではない依存関係Topping -> Topping Typeです。これは、候補キー全体以外の何かに対する依存関係です。

したがって、これを解決するために、PizzasテーブルからTopping Typeを取り出し、Toppingsテーブルの非キー属性にします。

153
Bill Karwin

微妙な違いは、3NFがキー属性と非キー属性（non-prime属性とも呼ばれる）を区別するのに対し、BCNFは区別しないことです。

これは、3NFの Zanioloの定義 を使用して最もよく説明されます。これはCoddの場合と同等です。

関係Rは、Rによって満たされるすべての非自明なFD（X-> A）に対して3NFであり、少なくとも次の条件の1つが当てはまります。

（a）XはRのスーパーキー、または

（b）AはRのキー属性です

BCNFは（a）を必要としますが、（b）をそれ自体の特別なケースとして扱いません。言い換えれば、BCNFでは、依存する属性がキーの一部である場合でも、すべての重要な決定要因がスーパーキーであることを要求します。

リレーションRは、次の条件が満たされる場合にRによって満たされるすべての非自明なFD（X-> A）に対してBCNFにあります。

（a）XはRのスーパーキーです

したがって、BCNFはより厳密です。

違いは非常に微妙であるため、3NFとして多くの人が非公式に説明しているのは、実際にはBCNFです。たとえば、3NFは「データはkey [s] ...に依存し、key [s]のみに依存する」という意味ですが、これは3NFではなくBCNFの非公式な記述です。 3NFは、「非キーデータはキーに依存し、...キーにのみ依存する」とより正確に説明できます。

あなたはまた述べた：

3NFの引用では、明示的に「キー以外は何もありません」ということは、すべての属性が主キーのみに依存していることを意味しています。

それは単純化しすぎです。 3NFおよびBCNFおよびすべての標準形は、1つの「プライマリ」キーだけでなく、all候補キーおよび/またはスーパーキーに関係します。

84
nvogel

BCNFと3NFの違い

BCNF定義を使用する

すべての依存関係X→Yの場合にのみ、以下の条件の少なくとも1つが成り立ちます：

  • X→Yは些細な機能依存性（Y⊆X）、または
  • XはスキーマRのスーパーキーです

および3NF定義

機能的な依存関係X→Aのそれぞれについて、次の条件の少なくとも1つが成り立つ場合にのみ：

  • XにAが含まれている（つまり、X→Aは単純な機能依存関係）、または
  • Xはスーパーキー、または
  • A-Xのすべての要素（AとXのセットの差）はプライム属性です（つまり、A-Xの各属性はいくつかの候補キーに含まれています）

簡単に言うと、次の違いがあります。

  • BCNF内：すべての部分キー（プライム属性）は、スーパーキーにのみonly依存できますが、

一方、

  • In 3NF：部分キー（プライム属性）は、alsoである属性に依存できますnotスーパーキー（つまり、別の部分キー/プライム属性、または非プライム属性）。

どこで

  1. prime attributeは、候補キーで見つかった属性です。
  2. 候補キーはそのリレーションの最小のスーパーキーであり、
  3. A superkey is a set of attributes of a relation variable for which it holds that in all relations assigned to that variable, there are no two distinct tuples (rows) that have the same values for the attributes in this set.Equivalently a superkey can also be defined as a set of attributes of a relation schema upon which all attributes of the schema are functionally dependent. (A superkey always contains a candidate key/a candidate key is always a subset of a superkey. You can add any attribute in a relation to obtain one of the superkeys.)

つまり、候補キーの部分的なサブセット（完全なセットを除く非自明なサブセット）は、スーパーキー以外の機能に依存することはできません。

BCNFにないテーブル/リレーションは、ピザの例で別のユーザーが言及した更新の異常などの異常の影響を受けます。残念ながら、

  • BNCF できません常に取得できます
  • 3NF 常に可能取得可能。

3NFとBCNFの例

現在、違いの例は、ウィキペディアの「 BCNF（Boyce–Codd normal form））を満たしていない3NFテーブル 」で見つけることができます。部分キー/プライム属性）は、「レートタイプ」（notではないスーパーキーである部分キー/プライム属性）に依存します。これは、データベースのクライアントに問い合わせることで決定できる依存関係です。 、テニスクラブ：

今日のテニスコートの予約（NF、notBCNF）

Court   Start Time  End Time    Rate Type
------- ----------  --------    ---------
1       09:30       10:30       SAVER
1       11:00       12:00       SAVER
1       14:00       15:30       STANDARD
2       10:00       11:30       PREMIUM-B
2       11:30       13:30       PREMIUM-B
2       15:00       16:30       PREMIUM-A

テーブルのスーパーキーは次のとおりです。

S1 = {Court, Start Time}
S2 = {Court, End Time}
S3 = {Rate Type, Start Time}
S4 = {Rate Type, End Time}
S5 = {Court, Start Time, End Time}
S6 = {Rate Type, Start Time, End Time}
S7 = {Court, Rate Type, Start Time}
S8 = {Court, Rate Type, End Time}
ST = {Court, Rate Type, Start Time, End Time}, the trivial superkey

NF問題：部分キー/プライム属性「Court」は、スーパーキー以外のものに依存しています。代わりに、部分的なキー/プライム属性「レートタイプ」に依存します。つまり、裁判所をアップグレードする場合、ユーザーは手動で料金タイプを変更する必要があります。料金変更を適用する場合は、手動で裁判所を変更する必要があります。

  • しかし、ユーザーが裁判所をアップグレードしたが、レートを上げることを覚えていない場合はどうなりますか？または、間違った料金タイプが裁判所に適用された場合はどうなりますか？

（技術的には、「レートタイプ」->「コート」機能依存関係が違反されないことを保証できません。）

BCNFソリューション：上記のテーブルをBCNFに配置する場合、指定されたリレーション/テーブルを次の2つのリレーション/テーブルに分解できます（レートタイプが裁判所のみに依存していることがわかっていると仮定します）データベースのクライアント、テニスクラブのオーナーに尋ねることで発見できるメンバーシップステータス）：

Rate Types（BCNFおよびBCNFによって暗示されるより弱い3NF）

Rate Type   Court   Member Flag
---------   -----   -----------
SAVER       1       Yes
STANDARD    1       No
PREMIUM-A   2       Yes
PREMIUM-B   2       No

Today's Tennis Court Bookings（BCNFおよびBCNFによって暗示されるより弱い3NF）

Member Flag     Court     Start Time   End Time
-----------     -----     ----------   --------
Yes             1         09:30        10:30
Yes             1         11:00        12:00
No              1         14:00        15:30
No              2         10:00        11:30
No              2         11:30        13:30
Yes             2         15:00        16:30

問題解決：裁判所をアップグレードした場合、料金タイプにこの変更が反映されることを保証でき、裁判所に間違った価格を請求することはできません。

（技術的には、機能の依存関係「レートタイプ」->「コート」に違反しないことを保証できます。）

23
AGéoCoder

すべての良い答え。単純な言語で表現するには[BCNF]部分キーはキーに依存できません。

つまり、候補キーの部分的なサブセット（つまり、完全なセットを除く任意の非自明なサブセット）は、機能的にいくつかの候補キーに依存することはできません。

4
smartnut007

「smartnut007」、「Bill Karwin」、および「sqlvogel」による回答が優れています。しかし、興味深い見方をしてみましょう。

さて、プライムキーと非プライムキーがあります。

非素数が素数に依存する方法に注目すると、次の2つのケースが見られます。

非素数は依存する場合もしない場合もあります。

  • 依存する場合：完全な候補キーに依存する必要があることがわかります。これは2NFです。

  • 依存していない場合：非依存または推移的な依存関係がある可能性があります

    • 推移的な依存関係でもない：どの正規化理論がこれに対処しているかわからない。
    • 推移的に依存する場合：望ましくないとみなされます。これはNFです。

素数間の依存関係はどうですか？

ご覧のとおり、2番目または3番目のNFによるprimes間の依存関係は扱っていません。さらに、そのような依存関係がある場合、それは望ましくないため、それに対処するための単一のルールがあります。これはBCNFです。

ここにあるBill Karwinの投稿の例を参照すると、「Topping」と「」の両方に気付くでしょう。 Topping Type 'は主キーであり、依存関係があります。それらが依存関係を持つ非素数であれば、3NFが作動していました。

注：

BCNFの定義は非常に一般的であり、素数と素数の間で属性を区別しません。それでも、上記の考え方は、2番目と3番目のNFの後でも異常が浸透する様子を理解するのに役立ちます。

高度なトピック：ジェネリックBCNFを2NFおよび3NFにマッピング

BCNFがプライム/非プライム属性を参照せずに一般的な定義を提供することがわかったので、BCNFと2/3 NFがどのように関連するかを見てみましょう

最初に、BCNFでは、機能的な依存関係X -> Y（FD）ごとに、Xがスーパーキーであることを（些細な場合を除いて）要求します。 FDのみを考慮する場合、3つのケースがあります-（1）XとYの両方が非素数、（2）両方の素数と（3）Xの素数とYの非素数、（無意味な）ケースX nonの破棄-primeおよびY prime。

ケース（1）の場合、3NFが処理します。

ケース（3）の場合、2NFが処理します。

（2）の場合、BCNFの使用が見つかります

3
KGhatak

これは価値のある答えを含む古い質問ですが、3NFの問題を示す実際の例を見つけるまでは、まだ少し混乱していました。 8歳の子供には向かないかもしれませんが、助けになるといいのですが。

明日は、四半期に一度の親と教師のミーティングで長女の先生に会います。日記は次のようになります（名前と部屋が変更されました）。

Teacher   | Date             | Room
----------|------------------|-----
Mr Smith  | 2018-12-18 18:15 | A12 
Mr Jones  | 2018-12-18 18:30 | B10 
Ms Doe    | 2018-12-18 18:45 | C21 
Ms Rogers | 2018-12-18 19:00 | A08

部屋ごとに教師は1人しかいません。 （1）すべての属性Teacher、Date、Roomについては、行ごとに1つの値しかありません。 （2）スーパーキーは：(Teacher, Date, Room)、(Teacher, Date)、および(Date, Room)であり、候補キーは明らかに(Teacher, Date)および(Date, Room)です。

(Teacher, Room)はスーパーキーではありません。次の四半期にテーブルを完成させ、このような行があるかもしれません（スミス氏は移動しませんでした！）：

Teacher  | Date             | Room
---------|------------------| ----
Mr Smith | 2019-03-19 18:15 | A12

結論は何ですか？ （1）1NFの非公式だが正しい定式化。 （2）から、「非素数属性」がないことがわかります。2NFと3NFは無料で提供されます。

私の日記は3NFです。良い！いいえ。DBスキーマでこれを受け入れるデータモデラーがないため、実際にはそうではありません。 Room属性はTeacher属性に依存しています（繰り返しますが、教師は移動しません！）が、スキーマはこの事実を反映していません。正気なデータモデラーは何をしますか？テーブルを2つに分割します。

Teacher   | Date
----------|-----------------
Mr Smith  | 2018-12-18 18:15
Mr Jones  | 2018-12-18 18:30
Ms Doe    | 2018-12-18 18:45
Ms Rogers | 2018-12-18 19:00

そして

Teacher   | Room
----------|-----
Mr Smith  | A12
Mr Jones  | B10
Ms Doe    | C21
Ms Rogers | A08

ただし、3NFは主な属性の依存関係を処理しません。 これは問題です：3NF準拠では、を確保するのに十分ではありません状況によってはサウンドテーブルスキーマの設計です。

BCNFでは、属性が2NFおよび3NFルールの主要な属性であるかどうかは関係ありません。自明でない依存関係（サブセットは明らかにスーパーセットによって決定されます）ごとに、行列式は完全なスーパーキーです。 つまり、完全なスーパーキー（些細なFDを除く）以外の何かによって決定されるものはありません。 （正式な定義については他の回答をご覧ください）。

RoomがTeacherに依存するとすぐに、RoomはTeacherのサブセットでなければなりません（そうではありません）。またはTeacherはスーパーキーでなければなりません（それは私の日記ではそうではありませんが、テーブルを分割するときはそうです）。

要約すると、BNCFはより厳密ですが、私の意見では、3NFよりも把握しやすいと考えています。

  • ほとんどの場合、BCNFは3NFと同一です。
  • 他の場合では、BCNFは3NFがあなたが考える/望んでいるものです。
2
jferard