ความแตกต่างระหว่าง 3NF และ BCNF ในแง่ง่าย (ต้องสามารถอธิบายได้ถึง 8 ปี)

ฉันได้อ่านคำพูด: ข้อมูลขึ้นอยู่กับกุญแจ [1NF] คีย์ทั้งหมด [2NF] และไม่มีอะไร แต่ที่สำคัญ [3NF]

อย่างไรก็ตามฉันมีปัญหาในการทำความเข้าใจ 3.5NF หรือ BCNF ตามที่เรียกว่า นี่คือสิ่งที่ฉันเข้าใจ:

• BCNF เข้มงวดกว่า 3NF
• ด้านซ้ายของ FD ใด ๆ ในตารางจะต้องเป็นปุ่ม Superkey (หรืออย่างน้อยหนึ่งปุ่มตัวเลือก)

แล้วเหตุใดตาราง 3NF บางตัวจึงไม่อยู่ใน BCNF ฉันหมายถึงคำพูด 3NF พูดอย่างชัดเจนว่า "ไม่มีอะไรนอกจากกุญแจ" หมายความว่าแอตทริบิวต์ทั้งหมดขึ้นอยู่กับคีย์หลักเท่านั้น คีย์หลักคือคีย์ตัวเลือกจนกว่าจะได้รับเลือกให้เป็นคีย์หลักของเรา

หากมีอะไรผิดปกติเกี่ยวกับความเข้าใจของฉันโปรดแก้ไขฉันและขอบคุณสำหรับความช่วยเหลือที่คุณสามารถให้ได้

พิซซ่าของคุณมีประเภทท็อปปิ้งสามประเภท:

• ชีสชนิดหนึ่ง
• เนื้อสัตว์ชนิดหนึ่ง
• ผักประเภทหนึ่ง

ดังนั้นเราจึงสั่งพิซซ่าสองอันและเลือกรสชาติต่อไปนี้:

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

เดี๋ยวก่อนมอสซาเรลล่าไม่สามารถเป็นทั้งชีสและเนื้อสัตว์ได้! และไส้กรอกไม่ใช่ชีส!

เราจำเป็นต้องป้องกันไม่ให้แปลก ๆ เหล่านี้ของความผิดพลาดที่จะทำให้ mozzarella เสมอเป็นชีส เราควรใช้ตารางแยกต่างหากสำหรับเรื่องนี้ดังนั้นเราจึงเขียนความจริงนั้นไว้ในที่เดียว

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เป็นหลักสูตรที่จริงถ้าเป็นส่วนหนึ่งของY Xดังนั้นในตารางใด ๆ ที่มีคีย์ตัวเลือกเดียวและอยู่ใน 3NF มันมีอยู่แล้วใน BCNF เพราะไม่มีคอลัมน์ (ทั้งคีย์หรือไม่ใช่คีย์) ซึ่งขึ้นอยู่กับหน้าที่ใด ๆ นอกเหนือจากคีย์นั้น

เนื่องจากพิซซ่าแต่ละตัวจะต้องมีประเภทของการเติมหน้าหนึ่งชนิดเท่านั้นเราจึงรู้ว่า (Pizza, Topping Type) เป็นรหัสผู้สมัคร เรารู้ด้วยสัญชาตญาณว่าเครื่องประดับที่กำหนดไม่สามารถอยู่ในประเภทที่แตกต่างกันพร้อมกัน ดังนั้น (Pizza, Topping) จะต้องไม่ซ้ำกันดังนั้นจึงเป็นรหัสผู้สมัคร ดังนั้นเราจึงมีปุ่มผู้สมัครสองคนที่ทับซ้อนกัน

ฉันพบความผิดปกติที่เราระบุว่าโมซาเรลล่าเป็นประเภทเครื่องประดับที่ผิด เรารู้ว่าสิ่งนี้ผิด แต่กฎที่ทำให้มันผิดคือการพึ่งพาTopping -> Topping Typeซึ่งไม่ใช่การอ้างอิงที่ถูกต้องสำหรับ BCNF สำหรับตารางนี้ มันเป็นการพึ่งพาสิ่งอื่นนอกเหนือจากคีย์ตัวเลือกทั้งหมด

ดังนั้นเพื่อแก้ปัญหานี้เรานำ Topping Type ออกจากตาราง Pizzas และทำให้เป็นคุณลักษณะที่ไม่สำคัญในตาราง Toppings

ความแตกต่างที่ลึกซึ้งคือ 3NF สร้างความแตกต่างระหว่างแอตทริบิวต์ที่สำคัญและไม่ใช่กุญแจ (เรียกอีกอย่างว่าคุณลักษณะที่ไม่สำคัญ ) ในขณะที่ BCNF ไม่ได้

นี่คือคำอธิบายที่ดีที่สุดโดยใช้คำจำกัดความของ Zanioloของ 3NF ซึ่งเทียบเท่ากับ Codd's:

ความสัมพันธ์, R, อยู่ใน 3NF iff สำหรับทุก ๆ FD ที่ไม่พึงประสงค์ (X-> A) ที่พึงพอใจโดย R อย่างน้อยหนึ่งในเงื่อนไขต่อไปนี้เป็นจริง:

(a) X คือ superkey สำหรับ R หรือ

(b) A เป็นคุณสมบัติที่สำคัญสำหรับ R

BCNF ต้องการ (ก) แต่ไม่ถือว่า (ข) เป็นกรณีพิเศษของตนเอง กล่าวอีกนัยหนึ่ง BCNF ต้องการให้ทุกปัจจัยที่ไม่สำคัญเป็น superkey แม้คุณสมบัติที่ขึ้นอยู่กับมันจะเกิดขึ้นเป็นส่วนหนึ่งของคีย์

ความสัมพันธ์, R, อยู่ใน BCNF iff สำหรับทุก ๆ FD ที่ไม่พึงประสงค์ (X-> A) ที่พอใจโดย R เงื่อนไขต่อไปนี้เป็นจริง:

(a) X เป็นซุปเปอร์คีย์สำหรับ R

BCNF จึงเข้มงวดมากขึ้น

ความแตกต่างนั้นลึกซึ้งมากจนหลายคนอธิบายอย่างไม่เป็นทางการว่า 3NF จริงๆแล้วเป็น BCNF ตัวอย่างเช่นคุณระบุที่นี่ว่า 3NF หมายถึง "ข้อมูลขึ้นอยู่กับคีย์ [s] ... และไม่มีอะไรนอกจากคีย์ [s]" แต่นั่นเป็นคำอธิบายที่ไม่เป็นทางการของ BCNF และไม่ใช่ 3NF 3NF สามารถอธิบายได้อย่างแม่นยำมากขึ้นว่า "ข้อมูลที่ไม่ใช่กุญแจขึ้นอยู่กับปุ่ม ... และไม่มีอะไรนอกจากกุญแจ"

คุณระบุด้วย:

เครื่องหมายคำพูด 3NF ระบุอย่างชัดเจนว่า "ไม่มีอะไรนอกจากคีย์" หมายความว่าแอตทริบิวต์ทั้งหมดขึ้นอยู่กับคีย์หลักเท่านั้น

นั่นเป็นเรื่องธรรมดามาก 3NF และ BCNF และฟอร์มปกติทั้งหมดเกี่ยวข้องกับคีย์ผู้สมัครทั้งหมดและ / หรือซุปเปอร์คีย์ไม่ใช่คีย์ "หลัก" เพียงปุ่มเดียว

ความแตกต่างระหว่าง BCNF และ 3NF

การใช้นิยาม BCNF

ถ้าหากว่าสำหรับการขึ้นต่อกันทุกครั้งของ X → Y จะต้องมีเงื่อนไขอย่างน้อยหนึ่งข้อต่อไปนี้ :

• X → Y คือการพึ่งพาการทำงานเล็กน้อย (Y ⊆ X) หรือ
• X คือกุญแจสำคัญสำหรับ schema R

และคำจำกัดความ 3NF

ถ้าหากว่าสำหรับการขึ้นต่อกันของฟังก์ชั่น X และ A นั้นมีเงื่อนไขอย่างน้อยหนึ่งข้อต่อไปนี้:

• X มี A (นั่นคือ X → A เป็นการพึ่งพาการทำงานเล็กน้อย) หรือ
• X คือซุปเปอร์คีย์หรือ
• องค์ประกอบของ AX ทุกชุดความแตกต่างระหว่าง A และ X เป็นคุณลักษณะเฉพาะ (เช่นแต่ละแอตทริบิวต์ใน AX มีอยู่ในคีย์ตัวเลือกบางตัว)

เราเห็นความแตกต่างดังต่อไปนี้ในแง่ง่าย ๆ :

• ใน BCNF : ทุกที่สำคัญบางส่วน (แอตทริบิวต์ที่สำคัญ) สามารถเท่านั้นขึ้นอยู่กับ superkey ที่

แต่ทว่า

• ใน 3NF : คีย์บางส่วน (คุณสมบัติหลัก) ยังสามารถขึ้นอยู่กับแอตทริบิวต์ที่ไม่ใช่ superkey (เช่นคีย์ / ไพรม์คีย์บางส่วนหรือแอตทริบิวต์ที่ไม่ใช่ไพรม์)

ที่ไหน

1. แอตทริบิวต์ที่สำคัญเป็นคุณลักษณะที่สำคัญที่พบในผู้สมัครและ
2. ที่สำคัญผู้สมัครเป็น superkey น้อยที่สุดสำหรับความสัมพันธ์นั้นและ
3. superkeyคือชุดของคุณลักษณะของตัวแปรความสัมพันธ์สำหรับการที่จะถือได้ว่าในความสัมพันธ์ทั้งหมดที่กำหนดให้ตัวแปรที่ไม่มีสองสิ่งอันดับที่แตกต่างกัน (แถว) ที่มีค่าเหมือนกันสำหรับแอตทริบิวต์ที่อยู่ในนี้ set.Equivalently superkey ยังสามารถ ถูกกำหนดให้เป็นชุดของคุณลักษณะของสคีมาความสัมพันธ์ซึ่งคุณลักษณะทั้งหมดของสคีมานั้นขึ้นอยู่กับการใช้งาน (Superkey มีคีย์ผู้สมัคร / คีย์ผู้สมัครอยู่เสมอเป็นชุดย่อยของ superkey คุณสามารถเพิ่มคุณลักษณะใด ๆ ในความสัมพันธ์เพื่อให้ได้หนึ่งในคีย์ซุปเปอร์)

นั่นคือไม่มีส่วนย่อยบางส่วน (ส่วนย่อยที่ไม่สำคัญยกเว้นชุดเต็ม) ของคีย์ตัวเลือกสามารถขึ้นอยู่กับหน้าที่อื่นใดนอกจาก superkey

ตาราง / ความสัมพันธ์ที่ไม่ได้อยู่ใน BCNF ขึ้นอยู่กับความผิดปกติเช่นความผิดปกติในการอัพเดทที่กล่าวถึงในตัวอย่างพิซซ่าโดยผู้ใช้รายอื่น น่าเสียดาย,

• ไม่สามารถรับ BNCF ได้ในขณะที่
• 3NF สามารถรับได้เสมอ

3NF กับ BCNF ตัวอย่าง

ตัวอย่างของความแตกต่างสามารถพบได้ที่ " 3NF ตารางไม่พบ BCNF (รูปแบบปกติ Boyce – Codd) " บน Wikipedia ซึ่งตารางต่อไปนี้ตรงกับ 3NF แต่ไม่ใช่ BCNF เพราะ "สนามเทนนิส" (แอตทริบิวต์บางส่วนของคีย์ / นายกรัฐมนตรี) บน "ประเภทอัตรา" (แอตทริบิวต์คีย์ / ไพรม์บางส่วนที่ไม่ใช่ซุปเปอร์คีย์) ซึ่งเป็นการอ้างอิงที่เราสามารถตรวจสอบได้โดยถามลูกค้าของฐานข้อมูลสโมสรเทนนิส:

การจองสนามเทนนิสในวันนี้ ( 3NF ไม่ใช่ BCNF )

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

Superkeys ของตารางคือ:

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" ขึ้นอยู่กับสิ่งอื่นที่ไม่ใช่ superkey แต่ขึ้นอยู่กับแอตทริบิวต์คีย์ / นายกบางส่วน "ประเภทอัตรา" แทน ซึ่งหมายความว่าผู้ใช้จะต้องเปลี่ยนประเภทอัตราด้วยตนเองหากเราอัพเกรดศาลหรือเปลี่ยนศาลด้วยตนเองหากต้องการใช้การเปลี่ยนแปลงอัตรา

• แต่ถ้าผู้ใช้อัปเกรดศาล แต่จำไม่ได้ว่าต้องเพิ่มอัตรา หรือถ้าประเภทอัตราที่ผิดถูกนำไปใช้กับศาล

(ในด้านเทคนิคเราไม่สามารถรับประกันได้ว่า "ประเภทอัตรา" -> "ศาล" ขึ้นอยู่กับการใช้งานจะไม่ถูกละเมิด)

วิธีการแก้ปัญหา BCNF : ถ้าเราต้องการวางตารางด้านบนใน BCNF เราสามารถแยกความสัมพันธ์ที่กำหนด / ตารางออกเป็นสองความสัมพันธ์ / ตารางต่อไปนี้ (สมมติว่าเรารู้ว่าประเภทอัตราขึ้นอยู่กับศาลและสถานะสมาชิกเท่านั้นซึ่งเราสามารถ ค้นพบโดยถามลูกค้าของฐานข้อมูลของเราเจ้าของสโมสรเทนนิส):

ประเภทอัตรา ( BCNFและ 3NF ที่อ่อนกว่าซึ่งแสดงนัยโดย BCNF)

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

การจองสนามเทนนิสในวันนี้ ( BCNFและ 3NF ที่อ่อนกว่าซึ่งบ่งบอกโดย BCNF)

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 ' นั้นยอดเยี่ยม แต่ให้ฉันใส่มุมมองที่น่าสนใจกับมัน

เรามีกุญแจที่ดีและไม่สำคัญ

เมื่อเรามุ่งเน้นวิธีการที่ไม่ใช่เฉพาะช่วงเวลาขึ้นอยู่กับช่วงเวลาเราจะเห็นสองกรณี:

ไม่ใช่ช่วงเวลาที่สามารถจะขึ้นหรือไม่

• เมื่อต้องพึ่งพา:เราเห็นว่าพวกเขาต้องขึ้นอยู่กับคีย์ตัวเลือกแบบเต็ม นี่คือ2NF

• เมื่อไม่ได้ขึ้นอยู่กับ:สามารถมีการพึ่งพาไม่ได้หรือการพึ่งพาสกรรมกริยา

  • ไม่ได้พึ่งพาสกรรมกริยา:ไม่แน่ใจว่าทฤษฎีการทำให้เป็นมาตรฐานที่อยู่นี้
  • เมื่อขึ้นอยู่กับการขนส่ง:ถือว่าไม่พึงประสงค์ นี้เป็น3NF

สิ่งที่เกี่ยวกับการพึ่งพาในหมู่เฉพาะช่วงเวลา?

ตอนนี้คุณเห็นแล้วว่าเราไม่ได้พูดถึงความสัมพันธ์ในการพึ่งพากันระหว่างช่วงเวลาโดย NF ที่ 2 หรือ 3 นอกจากนี้การพึ่งพาดังกล่าวหากมีก็ไม่เป็นที่ต้องการดังนั้นเราจึงมีกฎข้อเดียวในการแก้ไขปัญหานั้น นี่คือBCNF

อ้างถึงตัวอย่างจากโพสต์ของBill Karwinที่นี่คุณจะสังเกตเห็นว่าทั้ง ' Topping ' และ ' Topping Type ' เป็นกุญแจสำคัญและมีการพึ่งพา หากพวกเขาไม่ใช่คนพาลที่พึ่งพาแล้ว 3NF จะเตะเข้า

บันทึก:

คำจำกัดความของ BCNF นั้นกว้างมากและไม่มีแอตทริบิวต์ที่แตกต่างกันระหว่างไพรม์และไพรม์ แต่วิธีคิดข้างต้นช่วยให้เข้าใจว่าความผิดปกติบางอย่างเกิดขึ้นได้แม้หลังจาก NF ที่ 2 และ 3

หัวข้อขั้นสูง: การจับคู่ BCNF ทั่วไปกับ 2NF & 3NF

ตอนนี้เราทราบแล้วว่า BCNF ให้คำจำกัดความทั่วไปโดยไม่มีการอ้างอิงถึงสิ่งที่สำคัญที่สุด / ไม่ใช่นายกลองมาดูกันว่า BCNF และ 2/3 NF เกี่ยวข้องกันอย่างไร

ก่อนอื่น BCNF ต้องการ (นอกเหนือจากกรณีเล็กน้อย) ที่สำหรับการพึ่งพาการทำงานX -> Y(FD) แต่ละครั้งX ควรเป็นซุปเปอร์คีย์ หากคุณพิจารณา FD ใด ๆ เรามีสามกรณี - (1) ทั้ง X และ Y ที่ไม่ใช่แบบไพรม์, (2) Prime และ (3) X prime และ Y non-prime, การละทิ้งกรณี (ไร้สาระ) X ไม่ใช่ - ไพรม์และ Y ไพรม์

สำหรับกรณี (1) 3NF ดูแล

สำหรับกรณี (3) 2NF ดูแล

สำหรับกรณี (2) เราพบการใช้ BCNF

นี่เป็นคำถามเก่าที่มีคำตอบที่มีค่า แต่ฉันก็ยังสับสนเล็กน้อยจนกระทั่งฉันพบตัวอย่างชีวิตจริงที่แสดงปัญหาของ 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) สำหรับทุกแอตทริบิวต์Teacher, Date, Roomเรามีเพียงหนึ่งค่าต่อแถว (2) ซุปเปอร์คีย์: (Teacher, Date, Room), (Teacher, Date)และ(Date, Room)และกุญแจผู้สมัครที่เห็นได้ชัดและ(Teacher, Date)(Date, Room)

_{(Teacher, Room) ไม่ใช่ซุปเปอร์คีย์เพราะฉันจะทำตารางให้เสร็จในไตรมาสถัดไปและฉันอาจมีแถวเช่นนี้ (Mr Smith ไม่ย้าย!):}

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

เราสรุปอะไรได้บ้าง? (1) เป็นสูตรที่ไม่เป็นทางการ แต่ถูกต้องของ 1NF จาก (2) เราเห็นว่าไม่มี "non prime attribute": 2NF และ 3NF ให้ฟรี

ไดอารี่ของฉันคือ 3NF ดี! ไม่ไม่ได้เพราะไม่มีตัวสร้างข้อมูลที่จะยอมรับสิ่งนี้ใน DB schema Roomแอตทริบิวต์จะขึ้นอยู่กับTeacherแอตทริบิวต์ (อีกครั้งครูจะไม่ย้าย!) แต่คีมาไม่สะท้อนความเป็นจริงนี้ ตัวสร้างข้อมูลที่มีสติจะทำอะไร? แยกตารางเป็นสองส่วน:

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 สำหรับการพึ่งพาที่ไม่สำคัญทุกครั้ง (เซตย่อยจะถูกกำหนดโดย supersets ของพวกเขาอย่างชัดเจน) ดีเทอร์มิแนนต์เป็นซุปเปอร์คีย์ที่สมบูรณ์ กล่าวอีกนัยหนึ่งไม่มีอะไรถูกกำหนดโดยสิ่งอื่นใดนอกจากซุปเปอร์คีย์หลักอย่างสมบูรณ์ (ยกเว้น FD เล็กน้อย) (ดูคำตอบอื่น ๆ สำหรับคำจำกัดความที่เป็นทางการ)

ทันทีที่Roomขึ้นอยู่กับTeacher, Roomจะต้องเป็นส่วนหนึ่งของTeacher(กรณีที่ไม่) หรือTeacherต้องเป็นกุญแจสำคัญสุด (กรณีที่ไม่อยู่ในไดอารี่ของฉัน แต่ thats กรณีที่เมื่อคุณสามารถแยกตาราง)

เพื่อสรุป: BNCF เข้มงวดมากขึ้น แต่ในความคิดของฉันเข้าใจง่ายกว่า 3NF:

• ในกรณีส่วนใหญ่ BCNF เหมือนกับ 3NF;
• ในกรณีอื่น BCNF คือสิ่งที่คุณคิด / หวัง 3NF คือ