私は引用を読みました： データはキー[1NF]、キー全体[2NF]、そしてキー[3NF]だけに依存します。
しかし、3.5NFまたはBCNFと呼ばれるものを理解するのに苦労しています。これが私が理解していることです：
では、なぜ一部の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場合、機能従属性はもちろん真であるためです。したがって、候補キーが1つだけで、3NFにあるテーブルでは、そのキー以外に機能的に依存する列（キーまたは非キー）がないため、すでにBCNFにあります。YX
各ピザには各トッピングタイプが1つだけ含まれている必要があるため、（ピザ、トッピングタイプ）が候補キーであることがわかります。また、特定のトッピングが同時に異なるタイプに属することはできないことも直感的にわかります。したがって、（Pizza、Topping）は一意である必要があるため、候補キーでもあります。したがって、2つの重複する候補キーがあります。
モッツァレラチーズを間違ったトッピングタイプとしてマークした異常を示しました。これが間違っていることはわかっていますが、間違っているルールは、Topping -> Topping TypeこのテーブルのBCNFの有効な依存関係ではない依存関係です。これは、候補キー全体以外のものへの依存です。
したがって、これを解決するために、PizzasテーブルからTopping Typeを取り出し、Toppingsテーブルの非キー属性にします。
微妙な違いは、3NFはキー属性と非キー属性（非プライム属性とも呼ばれます）を区別しますが、BCNFは区別しないことです。
これは、ザニオロの3NFの定義を使用して最もよく説明されます。これは、コッドの定義と同等です。
関係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は「データはキーに依存し、キー以外は何も依存しない」という意味であると述べましたが、これは実際には3NFではなくBCNFの非公式な説明です。3NFは、「非キーデータはキーに依存します...そしてキー以外の何物でもない」とより正確に説明できます。
あなたはまた述べました：
3NFの引用では、「キー以外は何もない」と明示的に示されています。これは、すべての属性が主キーのみに依存することを意味します。
それは単純化しすぎです。3NFとBCNF、およびすべての正規形は、1つの「主」キーだけでなく、すべての候補キーやスーパーキーに関係します。
BCNF定義の使用
依存関係X→Yのすべてについて、次の条件の少なくとも1つが当てはまる場合に限ります。
および3NFの定義
機能従属性X→Aのそれぞれについて、次の条件の少なくとも1つが当てはまる場合に限ります。
一方
どこ
つまり、候補キーの部分的なサブセット（完全なセットを除く重要なサブセット）は、スーパーキー以外のものに機能的に依存することはできません。
BCNFにないテーブル/リレーションは、別のユーザーによるピザの例で言及されている更新の異常などの異常の影響を受けます。不運にも、
違いの例は、現在Wikipediaの「3NFテーブルがBCNF（Boyce–Codd正規形）を満たしていない」にあります。次のテーブルは3NFを満たしていますが、「テニスコート」（部分的なキー/プライム属性）が依存しているため、BCNFは満たしていません。 「レートタイプ」（スーパーキーではない部分的なキー/プライム属性）について。これは、データベースのクライアントであるテニスクラブに尋ねることで判断できる依存関係です。
今日のテニスコートの予約（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の問題：部分的なキー/プライム属性「Court」は、スーパーキー以外のものに依存しています。代わりに、部分的なキー/プライム属性「レートタイプ」に依存します。つまり、コートをアップグレードする場合はユーザーがレートタイプを手動で変更する必要があり、レート変更を適用する場合は手動でコートを変更する必要があります。
（技術的には、「レートタイプ」->「コート」機能依存性に違反しないことを保証することはできません。）
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]部分的なキーはキーに依存できません。
つまり、候補キーの部分的なサブセット（つまり、完全なセットを除く重要なサブセット）は、機能的にいくつかの候補キーに依存することはできません。
'<strong> smartnut007'、'<strong> Bill Karwin'、および'<strong>sqlvogel'による回答は優れています。それでも、私はそれに興味深い視点を置きましょう。
ええと、プライムキーと非プライムキーがあります。
非素数が素数にどのように依存するかに焦点を当てると、2つのケースがあります。
非素数は依存する場合としない場合があります。
依存していない場合：非依存または推移的な依存が存在する可能性があります
素数間の依存関係はどうですか？
ご覧のとおり、2番目または3番目のNFによる素数間の依存関係には対応していません。さらに、そのような依存関係がある場合は望ましくないため、それに対処するための単一のルールがあります。これはBCNFです。
ここにあるBillKarwinの投稿の例を参照すると、「<em>Topping」と「<em>ToppingType」の両方がプライムキーであり、依存関係があることがわかります。それらが依存関係のある非素数であった場合、3NFが開始されたでしょう。
ノート：
BCNFの定義は非常に一般的であり、プライムと非プライムの間で属性を区別することはありません。しかし、上記の考え方は、2番目と3番目のNFの後でも何らかの異常がどのように浸透しているかを理解するのに役立ちます。
高度なトピック：一般的なBCNFの2NFおよび3NFへのマッピング
BCNFが素数/非素数の属性を参照せずに一般的な定義を提供することがわかったので、BCNFと2/3NFがどのように関連しているかを見てみましょう。
まず、BCNFは、（自明な場合を除いて）各機能従属性X -> Y（FD）に対してXがスーパーキーであることを要求します。FDを検討する場合、3つのケースがあります-（1）XとYの両方が非プライム、（2）プライムと（3）XプライムとYが非プライムの両方、（無意味な）ケースX非-プライムと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スーパーキーである必要があります（私の日記ではそうではありませんが、テーブルを分割する場合はそうです）。
要約すると、BNCFは3NFよりも厳密ですが、私の意見では理解しやすいです。