Chapter 8 : นอร์มัลไลเซชัน (Normalization) อ.คเชนทร์ ซ่อนกลิ่น

การออกแบบโมเดลฐานข้อมูลเชิงสัมพันธ์ สามารถออกแบบได้ 2 ทาง คือ ผ่านขั้นตอนการออกแบบโมเดลข้อมูลแบบ E-R กล่าวคือ โมเดลฐานข้อมูลเชิง สัมพันธ์ จะได้จากการแปลงมาจาก โมเดลข้อมูลแบบ E-R ไม่ผ่านขั้นตอนการออกแบบโมเดลข้อมูลแบบ E-R กล่าวคือ นักวิเคราะห์และ ออกแบบ ระบบที่มีประสบการณ์สูง สามารถออกแบบโมเดลฐานข้อมูลเชิง สัมพันธ์ได้โดยตรง โดยไม่ต้องผ่านการออกแบบโมเดลแบบ E-R มาก่อน โดย อาศัยเพียงข้อมูลปฐมภูมิ (Primary Data) เช่น รายงาน หรือแบบฟอร์มต่างๆ เป็นข้อมูลเบื้องต้นในการออกแบบโมเดลฐานข้อมูลเชิงสัมพันธ์

กระบวนการปรับบรรทัดฐาน (Normalization) วิเคราะห์ความต้องการของผู้ใช้ E-R Diagram รีเลชั่นที่มีรูปแบบไม่เป็นบรรทัดฐาน (Unnormalized relation) 1 NF 2 NF กระบวนการปรับบรรทัดฐาน (Normalization) 3 NF บอยด์ คอดด์ 4 NF 5 NF รูปแสดงกระบวนการปรับบรรทัดฐานของรีเลชันในระดับต่างๆ

Normalization Normalization เป็นวิธีที่ใช้ในการปรับโครงสร้างของตารางเพื่อให้ได้ตารางที่ สามารถเก็บข้อมูลได้โดยไม่มีปัญหาใดๆ ตามมาภายหลัง โดยให้อยู่ในรูปแบบที่ เรียกว่า Normal Form (NF) มีเป้าหมายหลัก คือ การลดความซ้ำซ้อนของข้อมูล และรักษาความถูกต้อง ให้แก่ข้อมูล

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

ความซ้ำซ้อนและข้อผิดพลาดจากการแก้ไขข้อมูล (Update anomaly)

ตัวอย่างการออกแบบฐานข้อมูลที่ดี Staff (พนักงาน) Branch (สาขา) รหัสพนักงาน ชื่อ-สกุล ตำแหน่ง เงินเดือน รหัสสาขา SL21 สมบูรณ์ อุ่นใจ ผู้จัดการ 35000 B005 SV37 สุนทรีย์ ทองดี ผู้ช่วย 25000 B003 SG14 สมศรี ต้องตา เลขานุการ 20000 SL41 ดวงใจ ศรีเด่น B007 รหัสสาขา ที่อยู่ B005 เชียงใหม่ B007 กรุงเทพ B003 พิษณุโลก ตัวอย่างการออกแบบฐานข้อมูลที่เกิดปัญหาเรื่องความซ้ำซ้อนของข้อมูล StaffBranch (รวมรายละเอียดของพนักงานไว้ด้วยกันกับรายละเอียดของสาขา) รหัสพนักงาน ชื่อ-สกุล ตำแหน่ง เงินเดือน รหัสสาขา ที่อยู่ SL21 สมบูรณ์ อุ่นใจ ผู้จัดการ 35000 B005 เชียงใหม่ SV37 สุนทรีย์ ทองดี ผู้ช่วย 25000 B003 พิษณุโลก SG14 สมศรี ต้องตา เลขานุการ 20000 SL41 ดวงใจ ศรีเด่น B007 กรุงเทพ

ตัวอย่างปัญหาความซ้ำซ้อนในข้อมูล รีเลชั่น StaffBranch รหัสพนักงาน ชื่อ-สกุล ตำแหน่ง เงินเดือน รหัสสาขา ที่อยู่ SL21 สมบูรณ์ อุ่นใจ ผู้จัดการ 35000 B005 เชียงใหม่ SV37 สุนทรีย์ ทองดี ผู้ช่วย 25000 B003 พิษณุโลก SG14 สมศรี ต้องตา เลขานุการ 20000 SL41 ดวงใจ ศรีเด่น B007 กรุงเทพ ความผิดพลาดจากการเพิ่ม ถ้าต้องการเพิ่มพนักงานใหม่ ที่อยู่สาขา B005 จะต้องกรอก B005 และที่อยู่สาขา คือ เชียงใหม่ เพิ่มอีก

ตัวอย่างปัญหาความซ้ำซ้อนในข้อมูล รีเลชั่น StaffBranch รหัสพนักงาน ชื่อ-สกุล ตำแหน่ง เงินเดือน รหัสสาขา ที่อยู่ SL21 สมบูรณ์ อุ่นใจ ผู้จัดการ 35000 B005 เชียงใหม่ SV37 สุนทรีย์ ทองดี ผู้ช่วย 25000 B003 พิษณุโลก SG14 สมศรี ต้องตา เลขานุการ 20000 SL41 ดวงใจ ศรีเด่น B007 กรุงเทพ ความผิดพลาดจากการเพิ่ม ถ้าต้องการเพิ่มสาขา จะมีปัญหาคือ ตารางนี้มีทั้งข้อมูลพนักงานและข้อมูลสาขาอยู่รวมกัน หากจะเพิ่มเฉพาะ รหัสสาขา และ ที่อยู่ ก็ไม่ได้เพราะ รหัสพนักงาน จะมีค่าว่างไม่ได้เพราะเป็น Primary Key ของตาราง ดังนั้นจะบันทึกได้ก็ต่อเมื่อมีพนักงานแล้ว

ความผิดพลาดจากการลบข้อมูล ถ้าลบข้อมูลหนึ่งแล้วส่งผลกระทบกับข้อมูลอื่น ที่ต้องถูกลบตาม เช่น พนักงานรหัส SL21 ลาออก ก็ลบแถวนั้นออก ข้อมูลสาขา B005 ก็จะหายไปด้วย ข้อผิดพลาดจากการเปลี่ยนแปลง ในกรณีที่ต้องการเปลี่ยนแปลงข้อมูลบางตัวของสาขา เช่น เปลี่ยนที่อยู่ของ B003 ก็ต้องเปลี่ยนหลายที่ ถ้าหากมีพนักงานสังกัดสาขานี้หลายที่ก็ต้องไปตามแก้ทุก ๆ ที่ ดังนั้นเราควรแยกตาราง StaffBranch ออกเป็นสองตาราง คือ ตาราง พนักงาน และตารางสาขา

พนักงาน สาขา รหัสสาขา ที่อยู่ B005 เชียงใหม่ B007 กรุงเทพ B003 รหัสพนักงาน ชื่อ-สกุล ตำแหน่ง เงินเดือน รหัสสาขา SL21 สมบูรณ์ อุ่นใจ ผู้จัดการ 35000 B005 SV37 สุนทรีย์ ทองดี ผู้ช่วย 25000 B003 SG14 สมศรี ต้องตา เลขานุการ 20000 SL41 ดวงใจ ศรีเด่น B007 สาขา รหัสสาขา ที่อยู่ B005 เชียงใหม่ B007 กรุงเทพ B003 พิษณุโลก

Normalization การ Normalization นี้เป็นการดำเนินงานอย่างเป็นลำดับ ที่กำหนดไว้ด้วยกันเป็น ขั้นตอน ตามปัญหาที่เกิดขึ้นในขั้นตอนนั้นๆ ซึ่งแต่ละขั้นตอนจะมีชื่อตาม โครงสร้างข้อมูลที่กำหนดไว้ดังนี้ 1. ขั้นตอนการทำ First Normal Form(1NF) 2. ขั้นตอนการทำ Second Normal Form(2NF) 3. ขั้นตอนการทำ Third Normal Form(3NF) 4. ขั้นตอนการทำ Boyce-Codd Normal Form(BCNF) 5. ขั้นตอนการทำ Fourth Normal Form(4NF) 6. ขั้นตอนการทำ Fifth Normal Form(5NF) (แต่ในที่นี้จะกล่าวถึงเพียง 4 ระดับแรกเท่านั้น)

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

First Normal Form : 1NF Relation หนึ่งๆ จะอยู่ในรูปแบบ 1NF ก็ต่อเมื่อ “ค่าของ Attribute ต่างๆ ในแต่ละ Tuple จะมีค่าของข้อมูลเพียง ค่าเดียว นั่นคือไม่มี Repeating Group และ Multi-valued”

ตัวอย่างตารางข้อมูล EmployeeTraining Emp_ID Emp_Name Dept Salary Course_NO Course_Name D-Complete 110 วิลาวัลย์ ขำคม Account 15,000 01 Acc PAC 12/0602002 03 SPSS 30/4/2002 112 อุษาวดี เจริญกุล 15,100 091 นพพร บุญชู IT 12,000 02 3D Studio max 31/03/2002 010 กสมา ร่มเย็น 11,000 001 วนิดา แซ่ลิ้ม Marketing 12,500 12/06/2002 Repeating Group

วิธีการทำให้อยู่ในรูปแบบ 1NF 1. กำจัด repeating group (กลุ่มซ้ำ) 2. เพิ่มคีย์หลัก

ผลลัพธ์ที่ได้จากการทำ 1NF ตาราง EmployeeTraining Emp_ID Course_NO Emp_Name Dept Salary Course_Name D-Complete 110 01 วิลาวัลย์ ขำคม Account 15,000 Acc PAC 12/06/2002 03 SPSS 30/04/2002 112 อุษาวดี เจริญกุล 15,100 091 02 นพพร บุญชู IT 12,000 3D Studio max 31/03/2002 010 กสมา ร่มเย็น 11,000 001 วนิดา แซ่ลิ้ม Marketing 12,500

Second Normal Form : 2NF Relation หนึ่งๆ จะอยู่ในรูปแบบ 2NF ก็ต่อเมื่อ 1. Relation นั้นๆ ต้องอยู่ในรูปแบบ 1NF 2. Attribute ทุกตัวที่ไม่ได้เป็นคีย์หลัก จะต้องมีความสัมพันธ์กับ Attribute ที่เป็นคีย์หลักทั้งหมด(Fully Functional Dependency) ไม่ใช่แค่ส่วนใดส่วนหนึ่งของคีย์หลัก หรือกล่าวง่ายๆ ว่า ไม่มี Partial Dependency เกิดขึ้น

จากผลลัพธ์ที่ได้จากการทำ 1NF ตาราง EmployeeTraining Emp_ID Course_NO Emp_Name Dept Salary Course_Name D-Complete 110 01 วิลาวัลย์ ขำคม Account 15,000 Acc PAC 12/06/2002 03 SPSS 30/04/2002 112 อุษาวดี เจริญกุล 15,100 091 02 นพพร บุญชู IT 12,000 3D Studio max 31/03/2002 010 กสมา ร่มเย็น 11,000 001 วนิดา แซ่ลิ้ม Marketing 12,500

เขียน Dependency Diagram ได้ดังนี้ Full Functional Dependency Course_NO Course_Name Emp_ID Emp_Name Dept Salary D-Complete Partial Dependency Partial Dependency เพราะฉะนั้นตาราง EmployeeTraining ไม่ได้อยู่ในรูป 2NF เนื่องจากมี Partial Dependency ต้องทำการแตก Relation เพื่อลดความซ้ำซ้อนของข้อมูล ดังนี้ EmployeeTraining(Emp_ID,Course_No,D_Complete) Employee(Emp_ID,Emp_Name,Dept,Salary) Course(Course_No,Course_Name)

ตารางนี้เมื่อทำให้อยู่ในรูป 2NF จะได้ 3 ตารางดังนี้ EmployeeTraining Emp_ID Course_NO Emp_Name Dept Salary Course_Name D-Complete 110 01 วิลาวัลย์ ขำคม Account 15,000 Acc PAC 12/06/2002 03 SPSS 30/04/2002 ตารางนี้เมื่อทำให้อยู่ในรูป 2NF จะได้ 3 ตารางดังนี้ Employee Course EmployeeTraining Emp_ID Emp_Name Dept Salary 001 วนิดา แซ่ลี้ Marketing 12,500 010 กสมา ร่มเย็น IT 11,000 Course_No Course_Name 01 Acc PAC 02 3D Studio max 03 SPSS Emp_ID Course_No D_Complete 110 01 12/06/2002 03 30/04/2002

Third Normal Form : 3NF Relation หนึ่งๆ จะอยู่ในรูปแบบ 3NF ก็ต่อเมื่อ 1. Relation นั้นๆ ต้องอยู่ในรูปแบบ 2NF 2. Attribute ทุกตัวที่ไม่ได้เป็นคีย์หลัก ไม่มีคุณสมบัติในการ กำหนดค่าของ Attribute อื่นที่ไม่ใช่คีย์หลัก หรือกล่าวง่ายๆ ว่า ไม่มี Transitive Dependency เกิดขึ้น

ตัวอย่างตารางข้อมูลที่ไม่ได้อยู่ในรูป 3 NF Dependency Diagram Emp_ID Emp_Name Job_Class Chg_Hour Transitive Dependency เพราะฉะนั้นตาราง Employee ไม่ได้อยู่ในรูป 3NF เนื่องจากมี Transitive Dependency ต้องทำการแตก Relation เพื่อลดความซ้ำซ้อนของข้อมูล ดังนี้ Employee(Emp_ID,Emp_Name,Job_Class) Job(Job_Class,Chg_Hour)

ตัวอย่างตารางข้อมูลที่ไม่ได้อยู่ในรูป 3 NF 4.25 รหัสพนักงาน ชื่อสกุล รหัสแผนก ชื่อแผนก เงินเดือน P001 นพเกศ แก้วใส A001 บัญชี 25000 P002 วารุณี รวดเร็ว F001 การเงิน 30000 คีย์หลักของตารางนี้คือ รหัสพนักงาน จากตารางยังมีฟังก์ชั่นการขึ้นต่อกันแบบ Transitive Dependency อยู่ คือ รหัสแผนก ซึ่งไม่ใช่คีย์หลักของตาราง แต่สามารถระบุค่า ชื่อแผนก ได้ คือ ถ้ารู้รหัสแผนก ก็จะ รู้ชื่อแผนก จากตารางข้างบน ทำให้อยู่ในรูป 3NF จะได้ 2 ตารางข้างล่างนี้ รหัสพนักงาน ชื่อสกุล เงินเดือน P001 นพเกศ แก้วใส 25000 P002 วารุณี รวดเร็ว 30000 รหัสแผนก A001 F001 รหัสแผนก ชื่อแผนก A001 บัญชี F001 การเงิน

ดีเพนเดนซีไดอะแกรม (Dependency Diagram)

แสดงขั้นตอนของการทำ Normalization Entity ที่มีข้อมูลซ้ำซ้อน กำจัดกลุ่มข้อมูลซ้ำซ้อน กำจัด Partial Dependency 1NF 2NF กำจัด Transitive Dependency 3NF

Boyce/Codd Normal Form : BCNF Relation หนึ่งๆ จะอยู่ในรูปแบบ BCNF ก็ต่อเมื่อ 1. Relation นั้นๆ ต้องอยู่ในรูปแบบ 3NF 2. ไม่มี Attribute อื่นใน Relation ที่สามารถระบุค่าของ Attribute ที่เป็นคีย์ หลักหรือส่วนหนึ่งส่วนใดของคีย์หลักในกรณีที่คีย์หลักเป็นคีย์ผสม (Composite Key)

Boyce/Codd Normal Form : BCNF ลักษณะ 3NF ที่ไม่ใช่ BCNF สังเกตุว่ายังมี Attribute หนึ่งยังสามารถระบุค่า Attribute ที่เป็นส่วนหนึ่ง ของ Primary key คือ (C B)

Boyce/Codd Normal Form : BCNF เช่น หากเลือก S# และ P# เป็นคีย์หลักแล้วจะเกิดปัญหาใน Relation นี้คือ SNAME จะมีคุณสมบัติในการระบุค่าของ Attribute S# ได้ S# SNAME P# QTY

Boyce/Codd Normal Form : BCNF ลักษณะ 3NF ที่ ไม่ใช่ BCNF S# SNAME P# QTY ทำให้อยู่ในรูปแบบ BCNF ได้ดังนี้ SNAME P# QTY SNAME S#

Boyce/Codd Normal Form : BCNF

ประเด็นที่ควรคำนึงถึงในการทำให้เป็น รูปแบบบรรทัดฐาน (Normal Form) การแตก relation มากเกินไป (Overnormalization) การดีนอร์มอลไลเซชัน (Denormalization)

การแตก relation มากเกินไป (Overnormalization) วัตถุประสงค์ของการทำให้เป็นรูปแบบบรรทัดฐาน คือ เพื่อลดปัญหาในด้านความซ้ำซ้อนของข้อมูล เพื่อลดปัญหาในเรื่องการเพิ่ม การลบ หรือการปรับปรุงข้อมูล โดยทั่วไปการออกแบบในระดับแนวคิด ผู้ออกแบบจะพยายามวิเคราะห์ relation ให้อยู่ในรูปแบบ 3NF กรณีที่เกิดปัญหาต่างๆ ที่จำเป็นต้องทำต่อไปถึงรูปแบบ BCNF, 4NF และ 5NF (เกิดขึ้นน้อยมากในทางปฏิบัติ)

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

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

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

ตัวอย่าง จาก Dependency Diagram จงวิเคราะห์และจัดทำ Normalization B C D E F G

ตัวอย่าง ขั้นที่ 1 ระบุ Partial Dependency และ Transitive Dependency B C D E F G Partial Dependency Transitive Dependency

ตัวอย่าง จากโจทย์ได้อยู่ในรูปแบบของ 1NF แล้ว A B C D E F G Partial Dependency Transitive Dependency

ตัวอย่าง 2NF : 1. อยู่ในรูปแบบ 1NF 2. ต้องไม่มี Partial Dependency B C E F G Transitive Dependency A D

ตัวอย่าง 3NF : 1. อยู่ในรูปแบบ 2NF 2. ไม่มี Transitive Dependency B C E F A D E G

ตัวอย่าง ลักษณะ 3NF ที่ไม่ใช่ BCNF A B C E F สังเกตว่ายังมี Attribute หนึ่งยังสามารถระบุค่า Attribute ที่เป็นส่วนหนึ่งของ Primary key A D E G

ตัวอย่าง ทำให้อยู่ในรูปแบบ BCNF ได้ดังนี้ A C E F C B A D E G

ข้อ 1 จาก Dependency Diagram จงวิเคราะห์และจัดทำ Normalization แบบฝึกหัด ข้อ 1 จาก Dependency Diagram จงวิเคราะห์และจัดทำ Normalization รหัสสมาชิก รหัสความชำนาญ ประเภทความชำนาญ ชม.การทำงาน ชื่อ นามสกุล อายุ รหัสกลุ่ม รหัสเมือง รหัสผู้ควบคุม

ข้อ 2 ให้นักศึกษาแปลงตารางต่อไปนี้ให้อยู่ในรูป 1NF-3NF โดยละเอียด การลงทะเบียนเรียน รหัสนักศึกษา ชื่อนักศึกษา รหัสวิชา ชื่อวิชา หน่วยกิต เกรด 53001 วนิดา AB12 บัญชี 3 A CD01 การเงิน PC09 สถิติ B 53009 สุมาลี