บทที่ 5 รูปแบบที่เป็นบรรทัดฐาน (Normal Form)

Outline Data Dependency Normalization Functional Dependency 1NF 2NF BCNF

Data Dependency เป็นข้อกำหนดเงื่อนไขที่ไม่สามารถระบุได้ เมื่อสร้าง relation scheme ด้วยคำสั่ง create table ดังนั้น DBMS ไม่สามารถตรวจสอบ Data Dependency Constraint ของฐานข้อมูลได้ Data Dependency ถูกนำมาใช้ในการออกแบบฐานข้อมูลเชิงสัมพันธ์ ด้วยการทำบรรทัดฐาน(Normalization)

Data Dependency(ต่อ) การมีฐานข้อมูลที่ดี ถูกต้อง น่าเชื่อถือ มีข้อมูลซ้ำซ้อนน้อยที่สุด เรียกใช้ฐานข้อมูลได้สะดวก เกิดจากการมีองค์ประกอบต่างๆในระบบฐานข้อมูล ไม่ว่าจะเป็น Software Hardware ต้องสนับสนุนกัน และที่สำคัญฐานข้อมูลต้องถูกออกแบบ scheme ต่างๆให้ดีด้วย ดังนั้น Data Dependency Constraint จึงเป็นข้อกำหนดที่สำคัญ แม้ว่า DBMS จะไม่มีวิธีตรวจสอบก็ตาม แต่ต้องนำมาใช้ในการออกแบบฐานข้อมูล

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

Data Dependency Constraint Functional Dependency เป็นข้อกำหนดของความสัมพันธ์ระหว่าง Attribute ภายใน relational scheme เดียวกัน Multivalued Dependency Join Dependency

นิยาม ฟังก์ชั่นการขึ้นต่อกัน (Functional Dependency : FD) ให้ R เป็นรีเลชั่น และให้ X,Y เป็น arbitrary subsets ของเซตแอตทริบิวต์ใน R แล้วกล่าวได้ว่า “Y is functionally dependent on X” หรือ “X functionally determines Y” ก็ต่อเมื่อ ทุกๆค่าของ X จะมีค่า Y ที่สอดคล้องกันเพียง 1 ค่าเสมอ โดยเขียนเป็นสัญลักษณ์ดังนี้ (XY)

Functional Dependency นิยามให้ความหมายว่า ค่าของattribute Y ขึ้นอยู่กับหรือถูกกำหนดโดย X หรือ ค่าattribute X 1 ค่า สามารถกำหนดว่าเกี่ยวข้องกับค่าattribute Y ได้ 1 ค่าเท่านั้น ดังนั้นเมื่อพบค่า X เท่ากันในทุกๆ 2 แถวใดก็ตาม ก็จะพบว่าในทุกๆ 2 แถวนั้นมีค่า Y เป็นค่าเดียวกันเสมอ

Functional Dependency แอตทริบิวต์หรือกลุ่มของแอตทริบิวต์ที่เป็นตัวระบุค่าของแอตทริบิวต์อื่นๆ เรียกว่า Determinant แอตทริบิวต์อื่นๆ ที่ถูกระบุค่า เรียกว่า Dependent สามารถใช้ Functional Dependency ในการหา primary key ของรีเลชั่นและใช้ในการทำ normalization ด้วย

Functional Dependency สัญลักษณ์ที่ใช้แทนคือ {A} {B} แผนภาพ FD (FD-Diagram) F คือ เซตของ Nontrivial Functional Dependency ที่พบบน Relation A B

ตัวอย่างตาราง Newlearn Stud_id Stud_name Cousre_id Semester Year Grade 111 Jack 4121201 1 2005 A 4123201 B+ 4122201 2 B 4123303 2006 C+ 112 John 113 Tom 4122205 114 Mary 2007 C

สิ่งที่พบนี้คือ Functional Dependency เขียนเป็นสัญลักษณ์ คือ จากตัวอย่าง พบว่าทุกๆ 2 แถว ที่มี stud_id เหมือนกันแล้ว ทุกๆ2 แถวนั้นจะมี stud_name เดียวกันเสมอ สิ่งที่พบนี้คือ Functional Dependency เขียนเป็นสัญลักษณ์ คือ {stud_id}  {stud_name} นอกจากนั้นยังพบ FD อีกคือ {stud_id,course_id,semester,year}  {grade} เพราะเมื่อกำหนดให้ stud_id 1 ค่ารวมกับ course_id 1ค่า รวมกับ semester 1 ค่ารวมกับ year 1 ค่า สามารถมี grade ได้ 1 ค่า เท่านั้น เช่น ถ้า stud_id=111 และ course_id=4121201 และ semester=1 และ year = 2005 ก็จะมีเกรดได้ 1 ค่า คือ A ***ถ้าทั้ง 4 นี้ต้องเป็นจริงเสมอ ไม่ว่าจะเป็น นักศึกษาคนไหน หรือ วิชาใด หรือ ภาคใดหรือปีใดๆก็ได้

จากตาราง newlearn พบว่า จะไม่มีทางพบว่า 2 tuples ใดๆ (2 tuples ที่เป็นคนละtuple กัน) มี stud_id เท่ากัน และมี course_id เท่ากัน และ semester เท่ากันและ year เท่ากัน เพราะ primary key ของตาราง newlearn คือ {stud_id,course_id,semester,year} ไม่ว่าจะเป็นปัจจุบันหรืออนาคต คือไม่มีทางพบ 2 tuples ใดดังกล่าวเสมอเลย เมื่อเป็นเช่นนี้จึงสรุปได้ว่าเกิด functional dependency ขึ้น

FD ที่พบใน Relation แบ่งเป็น 2 กลุ่มได้แก่ Trivial Functional Dependency Nontrivial Functional Dependency

Trivial Functional Dependency คือ FD ที่พบอยู่ในรูป {x}{x} หรือ อยู่ในรูป {x}  {y} ถ้า y  x Trivial FD จัดเป็น FD ที่เป็นจริงเสมอ พบได้ในทุก relation สามารถหา Trivial FD ได้เสมอ แม้ไม่ทราบความหมายหรือความสัมพันธ์ของแอตทริบิวต์

ตัวอย่าง Trivial FD ตาราง R(A,B,C) มี Trivial FD ได้แก่ AA BB ABA CC ABAB ACAC BCBC ABCABC ABA ABB ACC ACA ABCAB ABCBC ฯลฯ

Nontrivial Functional Dependency คือ FD ใดๆ ที่ไม่ใช่ Trivial FD การเริ่มต้นหา Nontrivial FD ต้องทราบความหมาย ความสัมพันธ์ ข้อกำหนดเงื่อนไขต่างๆของแอตทริบิวต์ จึงจะสรุปเป็น Nontrivial FD ได้ ดังนั้นการหา Nontrivial FD จะหาได้ถูกต้องหรือไม่ ขึ้นอยู่กับเราเข้าใจความหมาย ความสัมพันธ์ของแอตทริบิวต์ได้ถูกต้องครอบคลุมหรือเปล่า

ตัวอย่าง Nontrivial FD จากตาราง Newlearn พบ Nontrivial FD ได้แก่ stud_id  stud_name stud_id,course_id,semester,year grade stud_id,course_id  stud_name,cours_id stud_id,semester  stud_name,semester เป็นต้น

ตัวอย่างตาราง SCP S# P# QTY City S1 P1 100 London P2 S2 200 Paris S3 300 S4 400 P4 P5

FD ของตาราง SCP 1. {S#,P#}  {QTY} 2. {S#,P#}  {CITY} หรือ 3. {S#,P#}  {CITY,QTY} (พยายามให้มีจำนวนattributeน้อยสุด) 4. {S#,P#}  {S#} 5. {S#,P#}  {P#} 6. {S#}  {CITY} …S# ไม่เป็น CK เกิด redundancy ถ้าเป็น Supplier คนเดียวกัน ส่งของ ก็จะปรากฎชื่อเมืองซ้ำกัน 7. {S#,P#}  {S#,P#,CITY,QTY} (พยายามให้มีจำนวนattributeน้อยสุด) 8. {S#}  {QTY} 9. {QTY}  {S#} เป็นจริงเฉพาะตารางนี้เท่านั้น ไม่ใช่ FD ที่เราต้องการ

FD ของตาราง SCP 10. {S#}  {S#} **trivial FD 11. {P#}  {P#} **trivial FD 12. {S#,P#}{S#} **trivial FD 13. {S#,P#}{P#} **trivial FD

ตัวอย่าง ตารางอาจารย์ที่ปรึกษา รหัสนักศึกษา ชื่ออาจารย์ 440001 นายอดิศักดิ์ เกิดแสง 460005 นางเพ็ญแก้ว รากทอง 451125 465200 นางอำแดง บุญส่ง FD : { รหัสนักศึกษา }  { ชื่ออาจารย์ } หากระบุนักศึกษาคนใด ก็จะสามารถหาอาจารย์ที่ปรึกษาของนักศึกษาคนนั้นได้ *แต่ ถ้าระบุชื่ออาจารย์ที่ปรึกษา 1 คน จะปรากฏนักศึกษามากกว่า 1 คน

ตัวอย่างตาราง orders Order_id orderDate Product_id Amount 1111 2/5/2006 P1 100 P2 30 1112 50 1113 3/5/2006 P5 20 3/5/2005

FD ที่พบของตาราง orders Trivial FD มากมาย เช่น order_id order_id order_dateorder_date Nontrivial FD เช่น Order_idorder_date Order_id,Product_id Amount Order_id,Product_id order_date,Product_id Order_id,Product_id order_date,Amount Order_id,Amount  order_date,Amount

FD-diagram ตาราง orders Orders(Order_id,OrderDate,Product_id,Amount) F = { order_id  orderDate , order_id,product_id Amount} นำ F มาเขียนเป็น FD diagram ได้ดังนี้ OrderDate Order_id Product_id Amount

ตัวอย่าง ตาราง พนักงาน รหัสพนักงาน รหัสแผนก วันที่ทำงาน เวลาเข้างาน เวลาออกงาน 111 D01 1/1/2007 8:00 19:00 2/1/2007 8:05 17:00 112 D02 7:30 18:25 6:45 17:49 113 5:45 16:45

FD ที่พบของตาราง พนักงาน Trivial FD มากมาย เช่น รหัสพนักงาน รหัสพนักงาน รหัสแผนก รหัสแผนก Nontrivial FD เช่น รหัสพนักงานรหัสแผนก รหัสพนังาน,วันที่ทำงาน เวลาเข้างาน,เวลาออกงาน รหัสพนังาน,วันที่ทำงาน  รหัสแผนก,วันที่ทำงาน รหัสพนังาน,วันที่ทำงาน,รหัสแผนก  เวลาเข้างาน,เวลาออกงาน

สรุปการพิจารณา FD ในแต่ละตาราง แต่ละตารางในฐานข้อมูลเชิงสัมพันธ์ ที่ได้มาจากการแปลง ER-model นั้น จะสามารถหา F ที่มีแต่ Nontrivial FD ได้ แต่ละตาราง ต้องมี primary key ดังนั้นเราจะได้ Nontrivial FD ที่มี determinant ของ FD เป็น primary key

ความสัมพันธ์ระหว่างแอตทริบิวแบบฟังค์ชั่น จำแนกเป็น 3 แบบ ความสัมพันธ์ระหว่างแอตทริบิวต์แบบเต็ม (Full Functional Dependency) ความสัมพันธ์ระหว่างแอตทริบิวต์แบบบางส่วน (Partial Dependency) ความสัมพันธ์ระหว่างแอตทริบิวต์แบบทรานซิทีฟ (Transitive Dependency)

ความสัมพันธ์ระหว่างแอตทริบิวต์แบบเต็ม(Full Functional Dependency) แนวคิดของ Full FD คือ attribute ข้างขวาของ FD ขึ้นอยู่กับ attribute ข้างซ้ายมือของ Full FD เช่น ถ้ามี FD ดังนี้ {รหัสอาจารย์,รหัสวิชา}  {จำนวนชั่วโมงสอน} FD นี้จะเป็น Full FD ได้ จะต้องไม่มี FD ต่อไปนี้ {รหัสอาจารย์}  {จำนวนชั่วโมงสอน} หรือ {รหัสวิชา}  {จำนวนชั่วโมงสอน} ถ้ามี FD อันใดอันหนึ่งข้างต้นแสดงว่า FD: {รหัสอาจารย์,รหัสวิชา}  {จำนวนชั่วโมงสอน} ไม่เป็น Full FD

Full Functional Dependency) กรณี determinant มีเพียงหนึ่งแอตทริบิวต์ ตารางนักศึกษา รหัสนักศึกษา ชื่อ นามสกุล วันเดือนปีเกิด 471002 นัฐพร จริงใจ 15 ม.ค 2529 475001 สมปอง รอดปลอด 24 ก.พ. 2530 460005 คณิต แก้วใส 21 ธ.ค. 2528 FD: {รหัสนักศึกษา}  {ชื่อ, นามสกุล, วันเดือนปีเกิด } แอตทริบิวต์ ชื่อ, นามสกุล, วันเดือนปีเกิด จึงมีความสัมพันธ์ระหว่างแอตทริบิวต์แบบเต็ม กับ แอตทริบิวต์ รหัสนักศึกษา

Full Functional Dependency) กรณี determinant มีมากกว่าหนึ่งแอตทริบิวต์ ตารางอาจารย์ผู้สอน รหัสวิชา กลุ่มเรียน ชื่ออาจารย์ผู้สอน 218552 001 จริงใจ 218001 002 พวงแก้ว 003 ทองหยด FD: {รหัสวิชา,กลุ่มเรียน}  {ชื่ออาจารย์ผู้สอน } แอตทริบิวต์ ชื่ออาจารย์ผู้สอน จึงมีความสัมพันธ์ระหว่างแอตทริบิวต์แบบเต็ม กับ แอตทริบิวต์ {รหัสวิชา, กลุ่มเรียน }

ความสัมพันธ์ระหว่างแอทริบิวต์แบบบางส่วน(Partial Dependency) เมื่อรีเลชั่นหนึ่งๆ มี primary key เป็น composite key และแอตทริบิวต์บางส่วนของ primary key สามารถระบุค่าของ แอตทริบิวต์อื่นๆ ในทูเปิลเดียวกัน ที่ไม่ใช่ primary key ของรีเลชั่นได้

ตัวอย่าง ตารางการลงทะเบียน รหัสนักศึกษา รหัสวิชา ชื่อวิชา กลุ่มเรียน 4420001 4122531 ระบบฐานข้อมูล 001 4420005 4420090 4122522 ระบบปฎิบัติการ 003 FD: {รหัสนักศึกษา, รหัสวิชา}  {ชื่อวิชา, กลุ่มเรียน} {รหัสวิชา}  {ชื่อวิชา} partial FD แอตทริบิวต์ รหัสวิชา ซึ่งเป็นส่วนหนึ่งของ primary key สามารถระบุค่าของชื่อวิชา ซึ่งความสัมพันธ์แบบนี้ อาจก่อให้เกิดปัญหาเรื่องความซ้ำซ้อนในการปรับปรุงข้อมูลได้

ความสัมพันธ์ระหว่างแอตทริบิวต์แบบ ทรานซิทีฟ(Transitive Dependency) ในบางรีเลชั่นที่ออกแบบไม่เหมาะสม อาจมีแอตทริบิวต์อื่นๆที่ไม่ใช่ primary key แต่สามารถระบุค่าของแอตทริบิวต์อื่นๆใน ทูเปิลเดียวกัน ของรีเลชั่นได้

ตัวอย่าง ตารางที่ปรึกษา รหัสนักศึกษา ชื่อนักศึกษา รหัสอาจารย์ ชื่ออาจารย์ 4420001 สมชาย มากมี 1010 พรพิศ งามตา 4420005 ดวงตา ตุงคะ 1000 สมาน คงยืน 4420090 ภาวิณี สง่าดี 2001 อุบล พาศรี FD: {รหัสนักศึกษา}  {ชื่อนักศึกษา, รหัสอาจารย์, ชื่ออาจารย์ } {รหัสอาจารย์}  {ชื่ออาจารย์} transitive FD แอตทริบิวต์ รหัสอาจารย์ ซึ่งเป็นแอตทริบิวต์ที่ไม่ใช่ primary key สามารถระบุค่าของแอตทริบิวต์อื่นๆ ในทูเปิลเดียวกัน คือ ชื่ออาจารย์ที่ปรึกษาได้

Normalization โดย ดร.คอร์ด เป็นผู้คิดค้น ค.ศ.1968 กระทำหลังจากได้ตารางมาจาก ER การทำ normalization เป็นขั้นตอนก่อนที่จะนำตารางไปสร้างเป็นฐานข้อมูลตามซอฟต์แวร์DBMS ที่เลือกใช้

ปัญหาที่เกิดขึ้น หลังจากเริ่มใช้ฐานข้อมูล ถ้าเรานำตารางซึ่งสร้างขึ้นมาเองจากข้อมูลที่สำรวจมาได้ หรือ อาจเป็นตารางที่ได้จากการแปลง ER ไปสร้างเป็นฐานข้อมูล แล้วเก็บข้อมูลต่างๆ ทันที โดยไม่ได้พิจารณาว่าตารางเหล่านั้นเหมาะสมที่จะนำไปสร้างเพื่อใช้งานจริงๆหรือไม่ อาจเกิดความเสียหายดังต่อไปนี้

ข้อบกพร่องจากการออกแบบที่ไม่ถูกต้อง ปัญหาการเพิ่มข้อมูล (Insert Anomalies) ปัญหาการแก้ไขข้อมูล (Update Anomalies) ปัญหาการลบข้อมูล(Delete Anomalies)

ตัวอย่างการออกแบบฐานข้อมูลพนักงาน ฐานข้อมูลเก็บข้อมูลพนักงานทำงานในโครงการ พนักงานแต่ละคนทำงานโครงการเดียว และแต่ละโครงการมีพนักงานทำงานมากกว่า 1 คนได้ มีการออกแบบฐานข้อมูล 2 แบบดังนี้ แบบ A เป็นการออกแบบที่ดี แบบ B เป็นการออกแบบที่ไม่ดี

Design A โครงการ พนักงาน รหัสพนักงาน ชื่อ รหัสโครงการ E1 มานะ P1 E2 ปิติ E3 ชูใจ P3 E4 สมใจ E5 มานี E6 สมคิด P2 E7 ญานี P4 รหัสโครงการ จังหวัด งบประมาณ (ล้านบาท) P1 กรุงเทพ 10 P2 ตาก 26 P3 น่าน 79 P4 ภูเก็ต

Design B มี 1 ตารางชื่อ ทำงาน ตารางนี้นำ 2 ตารางใน design A มา natural join รหัสพนักงาน ชื่อ รหัสโครงการ จังหวัด งบประมาณ E1 มานะ P1 กรุงเทพ 10 E2 ปิติ E3 ชูใจ P3 น่าน 79 E4 สมใจ E5 มานี E6 สมคิด P2 ตาก 26 E7 ญานี P4 ภูเก็ต

ข้อบกพร่องจากการออกแบบ แบบB Insert Anomaly เมื่อต้องการ insert แถวใหม่ ซึ่งแถวใหม่อาจมีข้อมูลไม่ครบถ้วนหรือ มีข้อมูลใหม่แต่ไม่สามารถ insert ใน relation ได้ เช่น กรณีมีพนักงานใหม่ (E8,สมชาย,P2) ข้อมูลนี้ insert ใน relation พนักงาน (แบบA) ได้ถูกต้อง สำหรับแบบ B ต้องรอให้ได้ข้อมูลครบถึงจะ insert ได้

ข้อบกพร่องจากการออกแบบ แบบB Deletion Anomaly เมื่อต้องการลบบางแถวจากตาราง อาจทำให้ข้อมูลบางอย่างถูกลบไปด้วยโดยคาดไม่ถึง เช่น พนักงาน E7 ลาออกไป ดังนั้นเมื่อลบแถว E7 ออกจากตารางจะทำให้ข้อมูลโครงการรหัส P4 ถูกลบออกไปด้วย

ข้อบกพร่องจากการออกแบบ แบบB update Anomaly ข้อมูลใน relation ทำงานของ design B จะพบว่ามีข้อมูลซ้ำซ้อนกันอยู่ คือ ข้อมูลโครงการ ถ้ามีพนักงานมากกว่า 1 คน ทำงานในโครงการเดียวกัน ก็จะมีข้อมูลโครงการและงบประมาณซ้ำซ้อนกันเสมอ

การทำ normalization คืออะไร จากปัญหาทั้ง 3 ที่เกิดขึ้นนี้ เพราะความซ้ำซ้อนกันของข้อมูลและตารางเก็บข้อมูลที่มีโครงสร้างไม่ดีพอ Normalization คือ กระบวนการในแตกรีลชั่นที่ไม่ดี ออกเป็นรีเลชั่นย่อยๆ เพื่อให้รีเลชั่นย่อยนี้อยู่ในรูปแบบบรรทัดฐานที่ต้องการ

รูปแบบบรรทัดฐาน (Normal Form) คือ เงื่อนไขที่รีเลชั่นนั้นต้องปฏิบัติตามเพื่อที่จะมีสภาพอยู่ในรูปแบบบรรทัดฐานนั้นๆ ถ้ารีเลชั่นไหนไม่เป็นไปตามเงื่อนไขของรูปแบบบรรทัดฐานแล้ว รีเลชั่นนั้นก็ไม่มีสภาพอยู่ในรูปแบบบรรทัดฐานนั้น เช่น นักศึกษาที่จบเกียรตินิยม เป็นประเภทหนึ่งของนักศึกษาที่จบการศึกษา เปรียบเหมือนรูปแบบบรรทัดฐานหนึ่ง ซึ่งการทึ่นักศึกษาที่จบเกียรตินิยม ต้องมีเงื่อนไขคือ GPA 3.75 ขึ้นไปและระยะเวลาการศึกษาไม่เกิน 3 ปี

วัตถุประสงค์ของการทำนอร์มัลไลซ์ เพื่อลดความซ้ำซ้อนข้อมูล ทำให้ลดเนื้อที่ในการจัดเก็บข้อมูลได้ เพื่อลดปัญหาที่ข้อมูลไม่ถูกต้อง เพื่อลดปัญหาที่เกิดจากการเพิ่ม ปรับปรุงและลบข้อมูล(Insert, Update, Delete Anomalies) เพื่อหาตัวแทนที่ดีที่สุด

รูปแบบบรรทัดฐาน (Normal Form) โดยเริ่มตั้งแต่ First Normal Form(1NF) ไปจนถึง Fifth Normal Form(5NF)

ความสัมพันธ์ระหว่าง Normal Form ระดับต่างๆ 1NF รูปนี้แทนความหมายว่า Normal Form ที่สูงจะดีกว่า หรือ ทำให้ข้อมูลซ้ำซ้อนน้อยกว่า Normal Form ที่ต่ำกว่าแล้ว นอกจากนั้น ยังแทนความหมายว่า รีเลชั่นใดที่มีคุณสมบัติเป็น normal form ระดับหนึ่งแล้ว ย่อมมีคุณสมบัติเป็น normal form ที่ต่ำกว่าด้วยเสมอ 2NF 3NF BCNF 4NF 5NF

ในการทำ normalization ต้องแตกรีเลชั่น จะต้องคงคุณสมบัติ 2 ข้อ คุณสมบัติการคงรายละเอียดการเชื่อมรีเลชั่น(Lossless Join) คือ การแตกรีเลชั่นหนึ่งเป็นรีเลชั่นย่อย จะแตกในลักษณะที่เมื่อนำเอารีเลชั่นย่อยนั้นมาทำ natural join ต้องได้รีเลชั่นเหมือนเดิมก่อนแตก ซึ่งไม่มี tuple เกินหรือขาดหายไป R แตก R1 R2 join R

ในการทำ normalization ต้องแตกรีเลชั่น จะต้องคงคุณสมบัติ 2 ข้อ 2. การคง Functional Dependency ได้อย่างครบถ้วน (Dependency Preservation) เมื่อแตกรีเลชั่นแล้ว FDต้องอยู่ครบเหมือนเดิม จะไม่มี FD ใดหายไป (ยกเว้นการแตกเพื่อให้รีเลชั่นอยู่ในรูปแบบบรรทัดฐาน BCNF อาจมี FD บางตัวหายไป)

รูปแบบบรรทัดฐานที่หนึ่ง (First Normal Form: 1NF) รูปแบบบรรทัดที่หนึ่ง มีเงื่อนไขว่า รีเลชั่นที่จะอยู่ในรูปของ 1NF ก็ต่อเมื่อ ค่าข้อมูลของแต่ละ attribute ภายใน 1 tuple ต้องเป็นค่าเดียว(single value) จากโดเมนของ attribute ซึ่งต้องไม่มีคุณสมบัติเชิงประกอบ(composite attribute) และไม่มีคุณสมบัติหลายค่า (multivalued attribute)

ตัวอย่าง ตารางใบสั่งซื้อสินค้า เลขที่ใบสั่ง วันที่สั่ง รายการสั่งซื้อ รหัสสินค้า จำนวน 123 4/5/2007 P1 10 P2 20 P3 124 5 P4 125 5/5/2007 -ตารางใบสั่งซื้อไม่เป็น 1NF เพราะ attribute รายการสั่งซื้อ เป็น composite attribute แบ่งได้เป็น รหัสสินค้า และ จำนวน - และ 1 ใบสั่งซื้อคือ 1 แถว ทำให้ attribute สินค้าและจำนวนมีค่าหลายๆค่า(multivalued attribute)

ตัวอย่าง ตารางใบสั่งซื้อสินค้า : 1NF เลขที่ใบสั่ง วันที่สั่ง รหัสสินค้า จำนวน 123 4/5/2007 P1 10 P2 20 P3 124 5 P4 125 5/5/2007 -นำตารางใบสั่งซื้อมาปรับให้เป็น relation 1NF โดยไม่เกิด multivalued attribute และ composite attribute ค่าข้อมูลของแต่ละ attribute ภายใน 1 แถวมีค่าเพียงค่าเดียวเสมอ

ตัวอย่าง ตารางพนักงาน ตารางนี้ไม่เป็น 1NF เพราะ attribute ลักษณะเป็น composite attribute แยกได้เป็น ความสูง น้ำหนัก สีผม แสดงว่า โดเมนของ attribute ลักษณะประกอบด้วยค่าที่ไม่ atomic หรือค่าที่แบ่งรายละเอียดย่อยได้อีก รหัสพนักงาน วันเกิด ลักษณะ 999 19/9/1799 ความสูง 173 ซม น้ำหนัก 50 กก. สีผม ดำ 888 18/8/1788 ความสูง 160 ซม น้ำหนัก 55 กก. สีผม น้ำตาล

ตัวอย่าง ตารางพนักงาน : 1NF รหัสพนักงาน วันเกิด ความสูง น้ำหนัก สีผม 999 19/9/1799 173 50 ดำ 888 18/8/1788 160 55 น้ำตาล การปรับตารางพนักงาน โดยสร้าง Attribute ใหม่ขี้นมาเท่ากับ จำนวนข้อมูลใน attribute ลักษณะ

ตัวอย่าง ตารางการใช้บัตรเครดิต ไม่ใช่ relation : UNF Relation:1NF รหัสลูกค้า หมายเลขบัตร 001 111-555-9 112-557-1 115-225-9 002 114-256-0 111-999-9 003 115-236-5 รหัสลูกค้า หมายเลขบัตร 001 111-555-9 112-557-1 115-225-9 002 114-256-0 111-999-9 003 115-236-5

ตัวอย่าง ตาราง First Multivalued attribute S# P# City Status QTY S1 P1 London 20 300 P2 200 P3 400 P4 P5 100 P6 S2 Paris 10 S3 S4 Multivalued attribute

วิธีปรับตาราง First เป็น 1NF P# City Status QTY S1 P1 London 20 300 P2 200 P3 400 P4 P5 100 P6 1. แยกคอลัมน์ที่มีมากกว่า 1 ค่าออกเป็นแถวใหม่ 2. เพิ่มข้อมูลที่เหมาะสมเข้าไปในคอลัมน์ที่ว่างอยู่ของแถวที่เกิดขึ้นใหม่ 3. กำหนด Primary Key ให้กับรีเลชั่น

ตาราง First อยู่ใน 1NF S# P# City Status QTY S1 P1 London 20 300 P2 200 P3 400 P4 P5 100 P6 S2 Paris 10 S3 S4

คุณสมบัติ 1NF ยังไม่เพียงพอ แม้ว่าตาราง First จัดอยู่ใน 1NF แล้วก็ตาม ก็ยังมี data redundancy ได้ คือ 2 แถวใดๆ ที่มี S# เท่ากัน ก็จะมี City ซ้ำกันเสมอ แต่ P# จะไม่ซ้ำกัน นี่คือตัวอย่างซึ่งอธิบายว่า 1NF ยังไม่เพียงพอ นอกจากนั้นยังพบปัญหา 3 ปัญหาอีกในตาราง First ดังนั้นต้องมีบรรทัดฐานขั้นต่อไปที่ดีกว่า หรือสูงกว่า คือ 2NF

ปํญหาที่พบของตาราง First ปัญหาการ insert ไม่สามารถเพิ่ม supplier คนใดคนหนึ่งที่อยู่เมืองใดเมืองหนึ่งได้ จนกว่า supplier คนนั้นจะต้องส่งของเสียก่อน ปัญหาการ delete ถ้าต้องการลบ S3 ส่ง P2 ไป 100 ชิ้น ถ้าต้องการลบ 3 ฟิลด์ ก็ต้องลบ 2 ฟิลด์ที่เหลือด้วย ปัญหาการ update ถ้าต้องการแก้ไขชื่อเมืองทั้งหมด ต้องเสียเวลามากและอาจแก้ไขไม่หมดได้

กรณีแปลงรีเลชั่นมาจาก ER รีเลชั่นที่ได้มาจาก ER นั้น จะอยู่ในรูปของ 1NF แล้ว เพราะใน ER-model มี single attribute, multivalued attribute,และ composite attribute ให้เราใช้งานแล้ว ดังนั้น composite และ multivalued attribute ถูกกำจัดตั้งแต่การแปลง ER มาเป็นรีเลชั่นแล้ว ซึ่งทำให้ไม่ปรากฎ mulivalued และ composite attribute ในรีเลชั่นที่ได้จากการแปลง

รูปแบบบรรทัดฐานที่สอง (Second Normal Form: 2NF) ทุกๆ nonkey attribute ต้องไม่ partially functional dependency บน Candidate Key ของรีเลชั่น หรือ ทุกๆ nonkey attribute ต้องขึ้นอยู่กับ Candidate key แบบ Full functional dependency Nonkey attribute คือ attribute ที่ไม่ได้เป็นสมาชิกของ Candidate Key ตัวใดเลย

รูปแบบบรรทัดฐานที่สอง (Second Normal Form: 2NF) ถ้า nonkey attribute ไม่ขึ้นอยู่กับ Candidate key แบบ Full FD ต้องแตก รีเลชั่นออก เพื่อให้ nonkey attribute ขึ้นอยู่กับ Candidate key แบบ Full FD จึงจะได้รีเลชั่นอยู่ในรูป 2NF เช่น ตาราง First ไม่อยู่ในรูป 2NF

พิจารณา ตาราง First ตาราง First( S#,P#,Status,City,QTY) อยู่ใน 1NF FD-diagram ของตาราง First City S# QTY P# Status

พิจารณา ตาราง First (con.) จาก FD : {S#,P#}  {City} พบว่า nonkey (City) ไม่ขึ้นกับ primary key แบบ Full FD เนื่องจากพบว่ามี FD: {S#}  {City} ตัวนี้เกิดขึ้น แสดงว่า FD : {S#,P#}  {City} ไม่เป็น Full FD และ FD : {S#}  {City} ตัวนี้เรียกว่า Partial FD จาก FD : {S#,P#}  {Status} พบว่า nonkey (Status) ไม่ขึ้นกับ primary key แบบ Full FD เนื่องจากพบว่ามี FD: {S#}  {Status} ตัวนี้เกิดขึ้น แสดงว่า FD : {S#,P#}  {Status} ไม่เป็น Full FD และ FD : {S#}  {Status} ตัวนี้เรียกว่า Partial FD

การแตกตารางที่ไม่อยู่ใน 2NF ตาราง First ไม่อยู่ในรูป 2NF ดังนั้นต้องแตกรีเลชั่น เพื่อให้รีเลชั่นเป็น 2NF ถ้าพบ R รีเลชั่นใดๆ ที่ R(A,B,C,D) และมี FD: A D แล้วจะแตกตารางได้ R1(A,D) R2(A,B,C)

แตกตาราง First ตาราง First อยู่ใน 1NF Second( S#,Status,City} SP( S#,P#,QTY} ทั้ง Second และ SP อยู่ในรูปของ 2NF แล้ว ดังนั้นตาราง Second และ SP นี้จะนำมาใช้แทนที่ตาราง First เพราะ Second และ SP ได้ความหมายครบถ้วนเทียบเท่าตาราง First และดีกว่าเพราะไม่มีข้อมูลซ้ำซ้อน

จุดสังเกต ของตาราง First ตาราง First เก็บ 2 เรื่องไว้ด้วยกัน คือ Shipment และข้อมูล Supplier ดังนั้นตาราง First ต้องแยกเป็น 2 ตารางคือ Second( S#,Status,City) SP( S#,P#,QTY)

ตัวอย่าง ตาราง R1 R1(A,B,C,D) และ FD = { A,B}{C} และ {B}{D} Nonkey attribute คือ C, D {A,B} {C} แสดงว่า C Full Functional Dependency บน Primary Key {B}{D} แสดงว่า D Partial Functional Dependency บน Primary Key ( คือ D functional dependency บน B โดย B เป็น attribute บางส่วนของ Primary key {A,B} ) ดังนั้น ตาราง R1 ไม่อยู่ในรูป 2NF

ตัวอย่าง ตาราง R2 R2(A,B,C,D) และ FD = { A,B}{C} และ {A,B}{D} Nonkey attribute คือ C, D {A,B} {C} แสดงว่า C Full Functional Dependency บน Primary Key {A,B}{D} แสดงว่า D Full Functional Dependency บน Primary Key ดังนั้น ตาราง R2 อยู่ในรูป 2NF

ตัวอย่าง ตารางการทำงาน รหัสพนักงาน รหัสโครงการ งบโครงการ (ล้านบาท) ระยะเวลาทำงานของพนักงานในโครงการ (วัน) 111 Proj1 15 30 113 112 Proj2 25 24 Proj3 45 60 65 114 40

ตัวอย่าง ตารางการทำงาน(ต่อ) nonkey attribute คือ งบโครงการ และ ระยะเวลาทำงาน รีเลชั่นการทำงาน ไม่อยู่ในรูป 2NF เพราะงบโครงการ partial FD บน Primary key จะเห็นว่า 1 โครงการมีงบประมาณเดียวเสมอ แสดงว่าโครงการเดียวกัน ต้องงบเท่ากัน ดังนั้น 2 แถวใดๆในตารางที่มีรหัสโครงการเท่ากัน ก็พบว่ามีค่างบโครงการซ้ำกัน เพื่อขจัดข้อมูลงบโครงการที่ซ้ำซ้อนกัน ต้องแตกตารางการทำงาน ออกเป็น ตาราง โครงการ และ ตารางพนักงาน

ตัวอย่าง ตารางการทำงาน(ต่อ) โครงการ พนักงาน รหัสโครงการ งบโครงการ Proj1 15 Proj2 25 Proj3 30 รหัสพนักงาน รหัสโครงการ ระยะเวลา 111 Proj1 30 113 15 112 Proj2 24 Proj3 45 60 65 114 40

ตัวอย่าง ตารางการทำงาน(ต่อ) ตารางโครงการ(รหัสโครงการ,งบโครงการ) nonkey คือ งบโครงการ FD: {รหัสโครงการ}  {งบโครงการ} งบโครงการ ซึ่ง Full Functional Dependency บน Primary Key ดังนั้น ตารางโครงการ อยู่ในรูป 2NF ตารางพนักงาน(รหัสพนักงาน,รหัสโครงการ,ระยะเวลาทำงาน) Nonkey คือ ระยะเวลาทำงาน FD: {รหัสโครงการ,รหัสพนักงาน}  {ระยะเวลาทำงาน} ระยะเวลาทำงาน ซึ่ง Full Functional Dependency บน Primary Key ดังนั้น ตารางพนักงาน อยู่ในรูป 2NF

ไม่อยู่ใน 2NF ตารางพนักงาน ตารางโครงการ อยู่ใน 2NF ตารางการทำงาน ไม่อยู่ใน 2NF แตก ตารางพนักงาน ตารางโครงการ อยู่ใน 2NF ตารางโครงการ และพนักงาน ยังคงมีข้อมูลครบถ้วนเหมือนตารางการทำงาน ไม่มีข้อมูลสูญหาย หรือ มีข้อมูลเกินเพิ่มเข้ามา พิสูจน์โดยนำ ตารางโครงการ มา natural join กับตารางพนักงาน จะได้ผลลัพธ์เท่ากับตารางการทำงาน Join ตารางการทำงาน

จุดสังเกต ตารางโครงการ มี primary key คือ รหัสโครงการ และพนักงาน มี foreign key คือ รหัสโครงการ อ้างอิงไปยังตารางโครงการ การนำ 2 ตารางมา join กัน จึงเชือมโยงด้วยค่า foreign key = primary key ทำให้ได้ผลลัพธ์ถูกต้องและครบถ้วน เหมือนตารางการทำงาน

รูปแบบบรรทัดฐานที่สาม (Third Normal Form: 3NF) ทุกๆ nonkey attribute ต้องไม่มีTransitive Functional Dependency บน Candidate key ของรีเลชั่น หรือพูดง่ายๆว่า ไม่เกิด FD ระหว่าง nonkey attribute 3NF เป็นอีกขั้นบรรทัดฐานที่สูงกว่า 2NF จะทำให้ data redundancy ลดลงไปอีก

ตัวอย่าง ตาราง R1 R1(A,B,C,D) FD: {A,B}  {C} , {A,B}  {D} Nonkey คือ C,D {A,B} C แสดงว่า C Full FD บน PK {A,B} D แสดงว่า D Full FD บน PK ดังนั้น R1 อยู่ในรูป 2NF {A,B} C แสดงว่า C ไม่ Transitive FD บน PK {A,B} D แสดงว่า D ไม่ Transitive FD บน PK ดังนั้น R1 อยู่ในรูป 3NF

ตัวอย่าง ตาราง R2 R2(A,B,C,D) FD: {A,B}  {C} , {C}  {D} Nonkey คือ C,D สำหรับ C ; {A,B} C แสดงว่า C Full FD บน PK สำหรับ D ; {A,B} C และ C D จะได้ว่า {A,B}  D {A,B}  D แสดงว่า D Full FD บน PK ดังนั้น R2 อยู่ในรูป 2NF {A,B} C แสดงว่า C ไม่ Transitive FD บน PK {A,B}  D แสดงว่า D Transitive FD บน PK ดังนั้น R2 ไม่อยู่ในรูป 3NF

การแตกตารางที่ไม่อยู่ใน 3NF ถ้าพบ R รีเลชั่นใดๆ ที่ R(A,B,C,D) และมี FD: B  C แล้ว จะแตกตารางได้ R1(B,C) R2(A,B,D)

ตัวอย่าง ตัวอย่างตารางที่อยู่ใน 2NF แต่ไม่อยู่ใน 3NF ตาราง Second( S#,City,Status) FD-Diagram 1 S# City 2 3 Status

ตัวอย่าง(ต่อ) พบว่ามี Transitive Dependency คือ S#  Status ต้องการกำจัด Transitive Dependency จึงต้องแตกเป็น 2 ตารางคือ ตาราง SC( S#,City) ตาราง CS( City,Status) ทั้ง 2 ตารางนี้อยู่ใน 3NF แล้ว

ตัวอย่าง การแตกตารางเพื่อคงรักษา FD ให้อยู่ครบถ้วน ตาราง Second( S#,City,Status) มี FD 3 ตัวคือ {S#}  {City} {City}  {Status} {S#} {Status} แตกตารางแบบ A ได้ SC(S#,City) CS(City,Status) แตกตารางแบบ B ได้ SS(S#,Status)

ตัวอย่าง การแตกตารางเพื่อคงรักษา FD ให้อยู่ครบถ้วน จะเห็นว่าแบบ A เป็นการแยกที่ดีกว่า แบบ B เพราะว่ายังคงได้ FD ทั้ง 3 ตัวครบคือ {S#}  {City} {City}  {Status} {S#} {Status} แตกแบบ B ได้ FD 2 ตัวคือ

รูปแบบบรรทัดฐานบอยซ์คอด (Boyce/Codd Normal Form: BCNF) เป็น normal form ที่ดีกว่า 3NF จะทำให้ data redundancy ลดน้อยลงไปอีก นิยามของ BCNF แตกต่างจาก 2NF,3NF กล่าวคือ 2NF มีเงื่อนไขผูกพันว่าต้องเป็น 1NF 3NF มีเงื่อนไขผูกพันว่าต้องเป็น 2NF แต่ BCNF จะไม่มีเงื่อนไขว่าต้องเป็น 1NF,2NFหรือ 3NF มาก่อนเลย การพิจารณารีเลชั่นว่ามีคุณสมบัติ BCNF จึงง่ายกว่า และถ้ารีเลชั่นใดเป็น BCNF แล้ว ย่อมเป็น 1NF,2NF และ 3NF แล้ว ในขณะที่รีเลชั่นใดเป็น 3NF แล้วอาจไม่เป็น BCNF ก็ได้

รูปแบบบรรทัดฐานบอยซ์คอด (Boyce/Codd Normal Form: BCNF) 1. Candidate key ตั้งแต่ 2 ตัวขึ้นไป 2. Candidate key ตั้งแต่ 2 ตัวขึ้นไป และ เป็น Composite key ด้วย 3. Candidate key ตั้งแต่ 2 ตัวขึ้นไป และ เป็น Composite key และมีบางส่วนซ้ำซ้อนกัน(Overlapped)เช่น CK คือ {S,J} กับ {S,T} การเริ่มพิจารณากระทำได้เลย ไม่ต้องเริ่มที่ 1NF,2NF,3NF โดยดูคุณสมบัติของตาราง เป็นไปตามข้อกำหนดข้อใดข้อหนึ่งข้างบนหรือไม่ ถ้าพบว่าเป็นไปตามข้อกำหนด ก็ ดูคำนิยามของ BNCF แต่ถ้าไม่พิจารณาข้อกำหนด 3 ข้อนี้ ก็ต้องเริ่มพิจารณาตั้งแต่ 1NF,2NF,3NF และ BCNF

รูปแบบบรรทัดฐานบอยซ์คอด (Boyce/Codd Normal Form: BCNF) ไม่มีส่วนใดส่วนหนึ่งของ primary key หรือ candidate key ที่ขึ้นกับ nonkey แอตทริบิวต์ Determinant ทุกตัวต้องเป็น Candidate key

ตัวอย่าง ตาราง R1 R1(A,B,C,D) Candidate Key คือ AB FD: {ABC} ,{ABD} Determinant ของ R1 คือ AB ดังนั้น R1 มีคุณสมบัติ BCNF

ตัวอย่าง ตาราง R2 R2(A,B,C,D) Candidate Key คือ AB FD: {ABC} ,{CD} Determinant ของ R2 คือ AB, C Determinant AB เป็น Candidate Key Determinant C ไม่เป็น Candidate Key ดังนั้น R2 ไม่มีคุณสมบัติ BCNF

ตัวอย่าง ตาราง R3 R3(A,B,C,D) Candidate Key คือ AB, C, D FD: {ABC} ,{CD}, {DAB} Determinant ของ R2 คือ AB, C, D Determinant AB เป็น Candidate Key Determinant C เป็น Candidate Key Determinant D เป็น Candidate Key ดังนั้น R3 มีคุณสมบัติ BCNF

ตัวอย่าง ตารางการสอน ผู้สอนแต่ละคนสอนได้ 1 วิชาเท่านั้นใน 1 เทอม และแต่ละวิชาใน 1 เทอม แบ่งเป็นหลายกลุ่ม (ถูกแบ่งเป็นกี่กลุ่มก็ตาม ต้องมีผู้สอนคนเดียวเท่านั้น) คนเดียวสอนทุกกลุ่มของวิชาเดียวกันในเทอมเดียวกัน ชื่อผู้สอน เทอม ชื่อวิชา กลุ่ม จำนวนนักศึกษา สมคิด 1/2548 ฐานข้อมูลเบื้องต้น Sec1 40 ฐานข้อมูลเบื่องต้น Sec2 30 กานดา โครงสร้างข้อมูล 45 สมาน 2/2548 ระบบสื่อสารข้อมูล

ตัวอย่าง ตารางการสอน(ต่อ) Candidate Key มี 2 ตัว คือ {ชื่อวิชา,เทอม,กลุ่ม} {ชื่อผู้สอน,เทอม,กลุ่ม} FD : {ชื่อผู้สอน,เทอม}  {ชื่อวิชา} {ชื่อวิชา,เทอม}  {ชื่อผู้สอน} {ชื่อวิชา,เทอม,กลุ่ม}  {จำนวนนักศึกษา} มี determinant 3 ตัว คือ {ชื่อผู้สอน,เทอม} , {ชื่อวิชา,เทอม} , {ชื่อวิชา,เทอม,กลุ่ม} Nonkey attribute คือ จำนวนนักศึกษา

ตัวอย่าง ตารางการสอน(ต่อ) ตารางการสอน นี้ ควรพิจารณา BCNF เพราะ Candidate Key มี 2 ตัว ซึ่งเป็น composite key และ Overlapped ด้วย ตารางการสอน ไม่เป็น BCNF เพราะ determinant {ชื่อผู้สอน,เทอม} ไม่เป็น CK determinant {ชื่อวิชา,เทอม} ไม่เป็น CK เมื่อตรวจสอบ normal form ตารางการสอนพบว่า เป็น 1NF แล้ว เป็น 2NF แล้ว เพราะ จำนวนนักศึกษา Full FD บน Primary key ดูจาก FD: {ชื่อวิชา,เทอม,กลุ่ม}  {จำนวนนักศึกษา} เป็น 3NF แล้ว เพราะจำนวนนักศึกษา ไม่ Transitive FD บน Primary Key

ตัวอย่าง ตารางการสอน(ต่อ) สังเกตว่า ข้อมูลในตารางการสอน มีข้อมูลซ้ำซ้อน แม้ว่าตารางนี้จัดเป็น 3NF ก็ตาม จาก FD : {ชื่อผู้สอน,เทอม}  {ชื่อวิชา} จะได้ว่า 2 แถวใด ที่มีชื่อผู้สอนคนเดียวกันและสอนในเทอมเดียวกัน ก็จะมีชื่อวิชาเดียวกันหรือชื่อวิชาซ้ำกัน และ {ชื่อผู้สอน,เทอม} ไม่ได้เป็น Candidate Key ด้วย จาก FD : {ชื่อวิชา,เทอม}  {ชื่อผู้สอน} จะได้ว่า 2 แถวใด ที่มีชื่อวิชาเดียวกันและสอนในเทอมเดียวกัน ก็จะมีชื่อผู้สอนเดียวกันหรือชื่อผู้สอนซ้ำกัน และ {ชื่อวิชา,เทอม} ไม่ได้เป็น Candidate Key ด้วย จะขจัดความซ้ำซ้อนดังกล่าวออกไป ทำได้โดยแตกเป็น 2 ตารางคือ R1(ชื่อผู้สอน,เทอม,ชื่อวิชา) R2(เทอม,ชื่อวิชา,กลุ่ม,จำนวนนักศึกษา)

ตัวอย่าง ตารางการสอน(ต่อ) R1(ชื่อผู้สอน,เทอม,ชื่อวิชา) FD: {ชื่อผู้สอน,เทอม}  {ชื่อวิชา} , {ชื่อวิชา,เทอม}  {ชื่อผู้สอน} Candidate Key คือ {ชื่อวิชา,เทอม}, {ชื่อผู้สอน,เทอม} Determinant คือ {ชื่อวิชา,เทอม}, {ชื่อผู้สอน,เทอม} ไม่มี nonkey attribute ดังนั้น ตาราง R1 เป็น BCNF แล้ว เพราะ Determinant {ชื่อผู้สอน,เทอม} เป็น Candidate Key ของ R1 Determinant {ชื่อวิชา,เทอม} เป็น Candidate Key ของ R1

ตัวอย่าง ตารางการสอน(ต่อ) R2(เทอม,ชื่อวิชา,กลุ่ม,จำนวนนักศึกษา) FD: {ชื่อวิชา,เทอม,กลุ่ม}  {จำนวนนักศึกษา} Candidate Key คือ {ชื่อวิชา,เทอม,กลุ่ม} Determinant คือ {ชื่อวิชา,เทอม,กลุ่ม} nonkey attribute คือ จำนวนนักศึกษา ดังนั้น ตาราง R2 เป็น BCNF แล้ว เพราะ Determinant {ชื่อวิชา,เทอม,กลุ่ม} เป็น Candidate Key ของ R2

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

ตัวอย่างตารางที่ไม่อยู่ใน BCNF ตาราง SSP( S#,SName, P#,QTY) มี Candidate Key 2 ตัวคือ {S#,P#} {SName,P#}

ตัวอย่างตารางที่ไม่อยู่ใน BCNF มี FD 4 ตัวคือ {S#}  {SName} {SName}  {S#} {S#,P#} {QTY} {SName,P#} {QTY} จะเห็นว่าจาก FD มีdeterminant 2 ตัว ที่ไม่ใช่ CK ดังนั้นตาราง SSP ไม่อยู่ใน BCNF จึงต้องแตกเป็น 2 ตารางคือ SS( S#,SName) SP( S#,P#,QTY) 2 ตารางนี้อยู่ใน BCNF

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

Denormalization การนำเอารีเลชั่นย่อยๆ R1,R2…Rn ทั้งหมดมา join กัน ได้เป็น R ในกรณีที่บางรีเลชั่นถูกออกแบบ โดยการไม่ทำให้อยู่ในรูปแบบบรรทัดฐานที่เป็นไปตามกฏเกณฑ์ที่กำหนดไว้ เช่น รีเลชั่นนั้นๆ ควรจะปรับให้อยู่ใน 3NF แต่หยุดอยู่เพียงรูปแบบ 2 NF อาจเป็นเพราะเหตุผลในเรื่องของประสิทธิภาพในการเรียกดูหรือค้นหาข้อมูลและยอมให้เกิดความซ้ำซ้อนของข้อมูลได้

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