รูปแบบปกติของบอยซ์-ค็อด ( BCNFหรือ3.5NF ) เป็นรูปแบบปกติที่ใช้ในการทำให้ฐานข้อมูลเป็นมาตรฐานเป็นรูปแบบที่เข้มงวดกว่ารูปแบบปกติที่สาม (3NF) เล็กน้อย การใช้ BCNF จะช่วยขจัด ความซ้ำซ้อนทั้งหมดที่เกิดจากการพึ่งพาเชิงฟังก์ชัน ในฐาน ข้อมูล

เอ็ดการ์ เอฟ. คอดด์ เผยแพร่บทความต้นฉบับเรื่อง "แบบจำลองเชิงสัมพันธ์ของข้อมูลสำหรับฐานข้อมูลขนาดใหญ่ที่ใช้ร่วมกัน" ในเดือนมิถุนายน ปี 1970 นี่เป็นครั้งแรกที่มีการเผยแพร่แนวคิดเกี่ยวกับฐานข้อมูลเชิงสัมพันธ์ งานวิจัยทั้งหมดหลังจากนั้น รวมถึงวิธีการรูปแบบปกติของบอยซ์-คอดด์ ล้วนอิงตามแบบจำลองเชิงสัมพันธ์นี้

รูปแบบปกติของ Boyce–Codd ได้รับการอธิบายครั้งแรกโดย Ian Heath ในปี 1971 และChris Dateเรียก มันว่า รูปแบบปกติของ Heathเช่น กัน ^{[ 1 ]}

BCNF ได้รับการพัฒนาอย่างเป็นทางการในปี พ.ศ. 2517 โดยRaymond F. BoyceและEdgar F. Coddเพื่อจัดการกับความผิดปกติบางประเภทที่ 3NF ไม่ได้จัดการตามที่กำหนดไว้แต่เดิม^{[ 2 ]}

ดังที่กล่าวไว้คริส เดทได้ชี้ให้เห็นว่าคำจำกัดความของสิ่งที่เรารู้จักในปัจจุบันว่าเป็น BCNF ปรากฏในบทความของเอียน ฮีธ ในปี พ.ศ. 2514 ^{[ 3 ]}เดทเขียนว่า: ^{[ 1 ]}

เนื่องจากคำจำกัดความนั้นมีมาก่อนคำจำกัดความของบอยซ์และค็อดด์ประมาณสามปี ดูเหมือนว่า BCNF ควรจะถูกเรียกว่ารูปแบบปกติของฮีธ (Heath normal form) อย่างถูกต้อง แต่ก็ไม่ได้ถูก เรียกเช่น นั้น

หากสคีมาเชิงสัมพันธ์อยู่ใน BCNF ความซ้ำซ้อนทั้งหมดที่อิงตามการพึ่งพาเชิงฟังก์ชันจะถูกลบออกไป^{[ 4 ]}แม้ว่าความซ้ำซ้อนประเภทอื่นอาจยังคงมีอยู่ สคีมาเชิงสัมพันธ์Rอยู่ในรูปแบบปกติของ Boyce–Codd ก็ต่อเมื่อ สำหรับ การพึ่งพาเชิงฟังก์ชันX → Yแต่ละรายการอย่างน้อยหนึ่งเงื่อนไขต่อไปนี้เป็นจริง: ^{[ 5 ]}

• X → Yเป็น ความสัมพันธ์เชิงฟังก์ชัน ที่ไม่สำคัญ (Y ⊆ X)
• Xเป็นซูเปอร์คีย์สำหรับสคี^มา R [ ^{5 ]}

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

ในบางกรณีที่หายาก ตาราง 3NF จะไม่ตรงตามข้อกำหนดของ BCNF ตาราง 3NF ที่ไม่มีคีย์ผู้สมัคร ที่ทับซ้อนกันหลายรายการ จะรับประกันได้ว่าเป็น BCNF ^{[ 6 ]}ขึ้นอยู่กับการพึ่งพาเชิงฟังก์ชัน ตาราง 3NF ที่มีคีย์ผู้สมัครที่ทับซ้อนกันสองรายการขึ้นไปอาจเป็น BCNF หรือไม่ก็ได้

ตัวอย่างของตาราง 3NF ที่ไม่ตรงตามมาตรฐาน BCNF คือ:

• แต่ละแถวในตารางแสดงถึงการจองสนามเทนนิสที่สโมสรเทนนิสแห่งหนึ่ง สโมสรนั้นมีสนามฮาร์ดคอร์ต 1 สนาม (สนามที่ 1) และสนามหญ้า 1 สนาม (สนามที่ 2)
• การจองจะถูกกำหนดโดยสนามและระยะเวลาที่สนามนั้นถูกจองไว้
• นอกจากนี้ การจองแต่ละครั้งจะมีประเภทอัตราค่าบริการที่เกี่ยวข้องอยู่ด้วย โดยมีประเภทอัตราค่าบริการที่แตกต่างกันสี่ประเภท:
  • โปรแกรม SAVER สำหรับการจองคอร์ท 1 โดยสมาชิก
  • มาตรฐาน สำหรับการจองคอร์ท 1 โดยผู้ที่ไม่ใช่สมาชิก
  • แพ็กเกจ PREMIUM-A สำหรับการจองคอร์ต 2 โดยสมาชิก
  • แพ็กเกจ PREMIUM-B สำหรับการจองคอร์ท 2 โดยผู้ที่ไม่ใช่สมาชิก

คีย์หลักของตารางมีดังนี้:

• S ₁ = {สนาม, เวลาเริ่มต้น}
• S ₂ = {ศาล, เวลาสิ้นสุด}
• S ₃ = {ประเภทอัตรา, เวลาเริ่มต้น}
• S ₄ = {ประเภทอัตรา, เวลาสิ้นสุด}
• S ₅ = {สนาม, เวลาเริ่มต้น, เวลาสิ้นสุด}
• S ₆ = {ประเภทอัตรา, เวลาเริ่มต้น, เวลาสิ้นสุด}
• S ₇ = {สนาม, ประเภทอัตรา, เวลาเริ่มต้น}
• S ₈ = {ศาล, ประเภทอัตรา, เวลาสิ้นสุด}
• S _T = {ศาล, ประเภทอัตรา, เวลาเริ่มต้น, เวลาสิ้นสุด} ซึ่งเป็นซูเปอร์คีย์ที่ไม่สำคัญ

โปรดทราบว่าถึงแม้ในตารางด้านบน ค่า เวลาเริ่มต้นและเวลาสิ้นสุดจะไม่ซ้ำกัน แต่เราก็ต้องยอมรับว่าในบางวัน การจองสองครั้งที่แตกต่างกันในคอร์ต 1 และคอร์ต 2 อาจเริ่มต้นหรือสิ้นสุดในเวลาเดียวกันนี่คือเหตุผลที่ {เวลาเริ่มต้น} และ {เวลาสิ้นสุด} ไม่สามารถถือเป็นซูเปอร์คีย์ของตารางได้

คีย์หลักของตารางมีดังนี้:

• S ₁ = {สนาม, เวลาเริ่มต้น}
• S ₂ = {ศาล, เวลาสิ้นสุด}
• S ₃ = {ประเภทอัตรา, เวลาเริ่มต้น}
• S ₄ = {ประเภทอัตรา, เวลาสิ้นสุด}

เฉพาะ S ₁ , S ₂ , S ₃และ S ₄ เท่านั้น ที่เป็นคีย์ผู้สมัคร (กล่าวคือ ซูเปอร์คีย์ขั้นต่ำสำหรับความสัมพันธ์นั้น) เพราะเช่น S ₁ ⊂ S ₅ดังนั้น S ₅ จึง ไม่สามารถเป็นคีย์ผู้สมัครได้

เนื่องจาก2NFห้ามการพึ่งพาเชิงฟังก์ชันบางส่วนของแอตทริบิวต์ที่ไม่ใช่ค่าหลัก (เช่น แอตทริบิวต์ที่ไม่ปรากฏในคีย์ผู้สมัครใดๆ ) และ3NFห้ามการพึ่งพาเชิงฟังก์ชันแบบถ่ายทอดของแอตทริบิวต์ที่ไม่ใช่ค่าหลักกับคีย์ผู้สมัคร

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

ตารางนี้ไม่เป็นไปตามรูปแบบ BCNF เนื่องจากมีความสัมพันธ์แบบพึ่งพา Rate type → Court โดยที่แอตทริบิวต์ที่กำหนดคือ Rate type ซึ่ง Court ขึ้นอยู่กับแอตทริบิวต์นี้ โปรดทราบว่า (1) {Rate type} ไม่ใช่superkeyและ (2) {Court} ไม่ใช่subsetของ {Rate type}

ประเภทอัตราเบี้ยเลี้ยงบุตรบุญธรรม → ศาลจะได้รับการพิจารณา เนื่องจากประเภทอัตราเบี้ยเลี้ยงบุตรบุญธรรมควรใช้กับศาลเพียงแห่งเดียวเท่านั้น

สามารถปรับเปลี่ยนการออกแบบเพื่อให้เป็นไปตามมาตรฐาน BCNF ได้:

คีย์ผู้สมัครสำหรับตารางประเภทอัตราค่าบริการคือ {ประเภทอัตราค่าบริการ} และ {สนาม, สถานะสมาชิก}; คีย์ผู้สมัครสำหรับตารางการจองวันนี้คือ {สนาม, เวลาเริ่มต้น} และ {สนาม, เวลาสิ้นสุด} ทั้งสองตารางอยู่ในรูปแบบ BCNF เมื่อใช้ {ประเภทอัตราค่าบริการ} เป็นคีย์ในตารางประเภทอัตราค่าบริการ การที่ประเภทอัตราค่าบริการหนึ่งประเภทเชื่อมโยงกับสนามสองแห่งที่แตกต่างกันนั้นเป็นไปไม่ได้ ดังนั้นการใช้ {ประเภทอัตราค่าบริการ} เป็นคีย์ในตารางประเภทอัตราค่าบริการจึงช่วยขจัดความผิดปกติที่ส่งผลกระทบต่อตารางเดิมได้

ในบางกรณี ตารางที่ไม่ใช่ BCNF ไม่สามารถแยกย่อยเป็นตารางที่ตรงตามมาตรฐาน BCNF และรักษาความสัมพันธ์ที่มีอยู่ในตารางเดิมได้ Beeri และ Bernstein แสดงให้เห็นในปี 1979 ว่า ตัวอย่างเช่น ชุดความสัมพันธ์เชิงฟังก์ชัน {AB → C, C → B} ไม่สามารถแสดงด้วยสคีมา BCNF ได้^{[ 7 ]}

พิจารณาตารางที่ไม่เป็นไปตามรูปแบบ BCNF ต่อไปนี้ ซึ่งมีการพึ่งพาเชิงฟังก์ชันตามรูปแบบ {AB → C, C → B}:

สำหรับแต่ละการจับคู่ประเภทบุคคล/ร้านค้า ตารางจะบอกเราว่าร้านค้าประเภทใดอยู่ใกล้บ้านของบุคคลนั้นมากที่สุดในเชิงภูมิศาสตร์ เพื่อความง่าย เราจะสมมติว่าร้านค้าหนึ่งร้านไม่สามารถมีได้มากกว่าหนึ่งประเภท

คีย์หลักของตารางมีดังนี้:

• {บุคคล, ประเภทร้านค้า}
• {บุคคล, ร้านค้าที่ใกล้ที่สุด}

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

การละเมิดรูปแบบ BCNF หมายความว่าตารางอาจเกิดความผิดปกติได้ ตัวอย่างเช่น Eagle Eye อาจมีการเปลี่ยนประเภทร้านค้าเป็น "นักทัศนมาตร" ในบันทึก "Fuller" ในขณะที่ยังคงประเภทร้านค้าเป็น "ช่างแว่นตา" ในบันทึก "Davidson" ซึ่งจะทำให้ได้คำตอบที่ขัดแย้งกันสำหรับคำถามที่ว่า "ประเภทร้านค้าของ Eagle Eye คืออะไร?" การเก็บประเภทร้านค้าของแต่ละร้านไว้เพียงครั้งเดียวดูเหมือนจะเป็นวิธีที่เหมาะสมกว่า เพราะจะช่วยป้องกันความผิดปกติดังกล่าวได้

ในการออกแบบที่ปรับปรุงใหม่นี้ ตาราง "ร้านค้าที่ใกล้ที่สุดตามบุคคล" มีคีย์หลักคือ {บุคคล, ร้านค้า} และตาราง "ร้านค้า" มีคีย์หลักคือ {ร้านค้า} น่าเสียดายที่ถึงแม้การออกแบบนี้จะสอดคล้องกับ BCNF แต่ก็ไม่เป็นที่ยอมรับด้วยเหตุผลอื่น: มันอนุญาตให้เราบันทึกร้านค้าหลายแห่งที่มีประเภทเดียวกันสำหรับบุคคลเดียวกัน กล่าวอีกนัยหนึ่ง คีย์หลักของมันไม่รับประกันว่าความสัมพันธ์เชิงฟังก์ชัน {บุคคล, ประเภทร้านค้า} → {ร้านค้า} จะได้รับการเคารพ

การออกแบบที่ขจัดความผิดปกติทั้งหมดเหล่านี้ (แต่ไม่สอดคล้องกับ BCNF) เป็นไปได้ การออกแบบนี้แนะนำรูปแบบปกติใหม่ที่เรียกว่าElementary Key Normal Form [ ^{8 ] การ}ออกแบบนี้ประกอบด้วยตาราง "ร้านค้าที่ใกล้ที่สุด" เดิมที่เสริมด้วยตาราง "ร้านค้า" ที่อธิบายไว้ข้างต้น โครงสร้างตารางที่สร้างโดยอัลกอริทึมการสร้างสคีมาของ Bernstein ^{[ 9 ]}จริงๆ แล้วคือ EKNF แม้ว่าการปรับปรุง 3NF นั้นจะยังไม่ได้รับการยอมรับในขณะที่ออกแบบอัลกอริทึมก็ตาม

หาก มีการกำหนด ข้อจำกัดความสมบูรณ์ของการอ้างอิงไว้ว่า {ประเภทร้านค้า, ร้านค้าที่ใกล้ที่สุด} จากตารางแรกจะต้องอ้างอิงถึง {ประเภทร้านค้า, ร้านค้า} จากตารางที่สอง ความผิดปกติของข้อมูลที่กล่าวถึงก่อนหน้านี้ก็จะถูกป้องกันได้

ถือ เป็นปัญหา NP-completeหากโครงสร้างฐานข้อมูลอยู่ในรูปแบบปกติที่สามเพื่อที่จะพิจารณาว่าโครงสร้างนั้นละเมิดรูปแบบปกติของ Boyce–Codd หรือไม่^{[ 10 ]}

หากความสัมพันธ์ R ไม่เป็นไปตามรูปแบบ BCNF เนื่องจากการพึ่งพาเชิงฟังก์ชัน X→Y แล้ว สามารถแยกความสัมพันธ์ R ออกเป็น BCNF ได้โดยการแทนที่ความสัมพันธ์นั้นด้วยความสัมพันธ์ย่อยสองความสัมพันธ์:

1. หนึ่งที่มีคุณสมบัติ X ⁺ ,
2. และอีกอันหนึ่งที่มีแอตทริบิวต์ RX ⁺ +X โปรดสังเกตว่า R แทนแอตทริบิวต์ทั้งหมดในความสัมพันธ์เดิม

ตรวจสอบว่าความสัมพันธ์ย่อยทั้งสองอยู่ในรูปแบบ BCNF หรือไม่ และทำซ้ำกระบวนการแบบเรียกซ้ำกับความสัมพันธ์ย่อยใดๆ ที่ไม่ได้อยู่ในรูปแบบ BCNF ^{[ 11 ]}

• กฎของการทำให้ข้อมูลเป็นมาตรฐาน
• การปรับค่ามาตรฐานขั้นสูงโดย ITS มหาวิทยาลัยเท็กซัส