3NFとBCNFの違いを簡単な言葉で（8歳まで説明できる必要がある）

見積もりを読みました。 データはキー[1NF]、キー全体[2NF]に依存し、キー[3NF]にのみ依存しています。

しかし、3.5NFまたはBCNFと呼ばれているとおりに理解できません。これが私が理解していることです：

• BCNFは3NFよりも厳しい
• テーブル内のFDの左側はスーパーキー（または少なくとも候補キー）である必要があります

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

これまでの私の理解に関して何か問題があれば、私を訂正してください。あなたが提供できるあらゆる助けに感謝します。

あなたのピザはちょうど3つのトッピングタイプを持つことができます：

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

したがって、2つのピザを注文し、次のトッピングを選択します。

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

ちょっと待って、モッツァレラチーズと肉の両方になることはできません！ソーセージはチーズではありません！

モッツァレラチーズを常にチーズにするためには、このような間違いを防ぐ必要があります。これには別のテーブルを使用する必要があるので、その事実を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とは異なる動作をします。

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

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

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

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

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

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

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

（a）XがRのスーパーキーである、または

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

BCNFは（a）を必要としますが、（b）をそれ自体の特殊なケースとして扱いません。言い換えると、BCNFは、依存関係のある属性がキーの一部である場合でも、すべての非自明な行列式がスーパーキーであることを要求します。

関係Rは、次の条件が真であるときにRによって満たされるすべての自明でないFD（X-> A）のBCNF iffにあります。

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

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

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

あなたはまた述べました：

3NFの引用では、「キーのみ」と明示的に述べられており、すべての属性が主キーにのみ依存していることを意味しています。

それは単純化しすぎです。3NFとBCNF、およびすべての正規形は、1つの「主」キーだけでなく、すべての候補キーやスーパーキーに関係しています。

BCNFと3NFの違い

BCNF定義の使用

すべての依存関係X→Yの場合に限り、次の条件の少なくとも1つが成立します。

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

と3NFの定義

その機能依存関係X→Aのそれぞれについて、以下の条件の少なくとも1つが当てはまる場合に限ります。

• XにAが含まれている（つまり、X→Aは些細な機能依存である）、または
• Xはスーパーキーです、または
• AXのすべての要素、AとXのセットの違いは主要な属性です（つまり、AXの各属性はいくつかの候補キーに含まれています）

簡単に言えば、次の違いがあります。

• BCNFの場合：すべての部分キー（基本属性）は、スーパーキーにのみ依存できます。

一方

• 3NFの場合：部分キー（素数属性）は、スーパーキーではない属性（つまり、別の部分キー/素数属性または非素数属性）にも依存する可能性があります。

どこ

1. プライム属性が候補キーで見つかった属性であり、
2. 候補キーは、その関係のための最小限のスーパーキーで、
3. スーパーキー、それがその変数に割り当てられたすべての関係で、どの2つの別個のタプルこのset.Equivalentlyスーパーキーの属性について同じ値を持つ（行）が存在しないことを保持するための関連変数の属性の集合であることもスキーマのすべての属性が機能的に依存する関係スキーマの属性のセットとして定義されます。（スーパーキーには常に候補キーが含まれます/候補キーは常にスーパーキーのサブセットです。リレーションに任意の属性を追加して、スーパーキーの1つを取得できます。）

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

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

• BNCF は常に取得できるとは限りませんが、
• 常に 3NF が得られます。

3NFとBCNFの例

違いの例は現在、Wikipediaの「3NF table not BCNF（Boyce–Codd normal form）」にあります。ここでは、次の表は3NFを満たしていますが、BCNFを満たしていません。 "Rate Type"（スーパーキーではない部分的なキー/プライム属性）に依存します。これは、データベースのクライアントであるテニスクラブに尋ねることによって決定できる依存関係です。

今日のテニスコートの予約（BCNF ではなく 3NF）

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

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

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

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

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

レートのタイプ（BCNFおよびBCNFによって暗示されるより弱い3NF）

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

今日のテニスコートの予約（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

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

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

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

つまり、候補キーの部分サブセット（つまり、完全セット以外の重要なサブセット）は、いくつかの候補キーに機能的に依存することはできません。

「smartnut007」、「Bill Karwin」、「sqlvogel」の回答は素晴らしいです。それでも興味深い見方をさせてください。

まあ、私たちは素数と非素数のキーを持っています。

非素数が素数にどのように依存するかに注目すると、2つのケースが見られます。

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

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

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

  • 推移的な依存関係すらありません：これに対応する正規化理論はわかりません。
  • 推移的に依存する場合：望ましくないと見なされます。これは3NFです。

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

ご覧のとおり、私たちは相互間の依存関係を扱っていません とおり、2番目または3番目のNFによる素数。さらに、このような依存関係は存在するとしても望ましくないため、これに対処するための単一のルールがあります。これはBCNFです。

ここにあるビルカーウィンの投稿の例を参照すると、 Topping」と「Topping Type」の両方が主キーであり、依存関係があることがわかります。彼らが依存関係のある非素数であったなら、3NFがキックしたでしょう。

注意：

BCNFの定義は非常に一般的であり、素数と非素数の属性を区別しません。しかし、上記の考え方は、2回目と3回目のNFの後でさえ、何らかの異常が浸透していることを理解するのに役立ちます。

高度なトピック：一般的なBCNFを2NFおよび3NFにマッピング

BCNFが素数/非素数属性を参照せずに一般的な定義を提供することがわかったので、BCNFと2/3 NFの関係を見てみましょう。

第1に、BCNFには、機能的な依存関係ごとに（些細な場合を除いて） X -> Y（FD）にXがスーパーキーであることを（ます。FDだけを考慮した場合、（1）XとYの両方が非素数、（2）素数と（3）X素数、Yが素数の3つのケースがあり、（無意味な）ケースX非-primeとYプライム。

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

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

ケース（2）の場合、BCNFの使用を見つけます

これは貴重な答えを含む古い質問ですが、3NFの問題を示す実際の例を見つけるまで、私はまだ少し混乱していました。8歳の子供には適さないかもしれませんが、役立つことを願っています。

明日は、四半期ごとの親/教師会議の1つで、長女の教師に会います。私の日記は次のようになっています（名前と部屋は変更されています）。

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（私の日記ではそうではないのですが、あなたは、テーブルを分割する場合のthats）スーパーキーでなければなりません。

要約すると、BNCFは3NFよりも厳密ですが、理解しやすいと思います。

• ほとんどの場合、BCNFは3NFと同じです。
• 他の場合では、BCNFは、3NFがあなたが考えている/期待しているものです。