การแปลงแผนภาพ E-R มาเป็นความสัมพันธ์
เมื่อเขียนแผนภาพเรียบร้อยแล้วสิ่งที่ต้องทำต่อไปก็คือการนำแผนภาพไปสร้างฐานข้อมูลจริงซึ่งการสร้างฐานข้อมูลนั้นไม่ได้ทำได้ด้วยการสร้างแผนภาพแต่เป็นการสร้างตาราง จึงต้องทำการแปลงแผนภาพให้เป็นความสัมพันธ์ในรูปของตาราง
การทำ entity ให้เป็นความสัมพันธ์
เวลาเปลี่ยนแผนภาพมาเป็นความสัมพันธ์ให้เขียน attribute ทั้งหมด
รูป3-1
ความสัมพันธ์ STUDENT คือ stuID, stuName, stuRoom
Composite attribute
ในกรณีของ composite attribute ให้เขียนเฉพาะ attribute ที่อยู่ใน composite attribute ก็พอ เช่น
รูป3-2
ความสัมพันธ์ STUDENT คือ stuID, stuName, houseNo, Province, postalCode
Multivalued attribute
ส่วน multivalued attribute ให้แตกออกมาเป็นอีกหนึ่งตารางแล้วโยงความสัมพันธ์กัน
รูป 3-3
ID, stuID, phone
ได้เป็น
รูป3-4
เมื่อต้องสร้างตารางในฐานข้อมูลให้เอาความสัมพันธ์ที่ได้เขียนไว้ไปสร้างตารางได้เลย
Normalization
Normalization เป็นกระบวนการตรวจสอบกลุ่ม attributes ที่สร้างขึ้นเพื่อให้มีประสิทธิภาพ หน้าที่หลักของ normalization คือการลดปัญหาเรื่องการซ้ำซ้อนของข้อมูลที่จะทำให้การแก้ไขเป็นไปได้ยากก็จะทำให้ประหยัดเนื้อที่จัดเก็บ และการลดปัญหาที่ยุ่งยากเกี่ยวกับตรวจสอบความถูกต้องของข้อมูล ส่วนการทำ normalization คือตอนที่หลังจากวาดแผนภาพเสร็จ ก็นำแผนภาพมาเขียนเป็นความสัมพันธ์แล้วตรวจสอบมีส่วนที่ต้องแก้ไขหรือไม่ ถ้ามีก็ทำการปรับปรุงแก้ไขให้เรียบร้อยจึงเรียกว่า normalization
ความซ้ำซ้อนและสิ่งผิดปกติ(Redundancies and Anomalies)
Normalization เป็นกระบวนแก้ไข ดังนั้นจึงต้องรู้ก่อนว่ามีอะไรที่ต้องแก้ไข ก็ได้แก่สิ่งที่เรียกว่าความซ้ำซ้อนและสิ่งผิดปกติ
สมมติถึงสถานการณ์ของร้านชาบู ชื่อ “ชาบูชาบู้” ที่มีสาขาอยู่หลายสขา และต้องจ้างพนักงานหลายคนในแต่ละสาขา อาจมีการเก็บตารางดังต่อไปนี้
CHABUCHABU_EMPLOYEE
chaempID | gender | chaempName | position | branchID | branchAddress |
Cha153 | M | ตอเต่า เต่าตอ | ผู้จัดการ | CB001 | กรุงเทพ |
Cha110 | F | มอม้า คึกคัก | ผู้จัดการ | CB005 | หัวหิน |
Cha393 | M | ปอปลา ตากลม | พนักงาน | CB003 | เชียงใหม่ |
Cha652 | M | ฌอเฌอ คู่กัน | พนักงาน | CB002 | กระบี่ |
Cha758 | F | ชอช้าง อ้วนจัง | ผู้ช่วยผู้จัดการ | CB001 | กรุงเทพ |
Cha405 | F | นอหนู มากมาย | พนักงาน | CB002 | กระบี่ |
Cha223 | M | มอแมว ไม่มอง | พนักงาน | CB005 | ประจวบคีรีขันธ์ |
แต่การสร้างตารางแบบข้างบนจะพบว่ามีการเก็บข้อมูลซ้ำซ้อนกันตรง branchID กับ branchAddress มีการเก็บรหัสและที่อยู่ของสาขาซ้ำๆ เช่น กรุงเทพก็ปรากฏถึง 2 ครั้ง
แล้วการซ้ำซ้อนเป็นความผิดปกติเป็นปัญหาอย่างไร
1.ปัญหาเวลาจะเพิ่มข้อมูล(insert)
- เวลาเพิ่มข้อมูลพนักงานต้องเสียเวลาเพิ่มข้อมูลสาขาที่พนักงานสังกัดด้วย เสียเวลา
- เวลาเพิ่งทำสาขาใหม่เสร็จจะเพิ่มข้อมูลสาขาใหม่ยังไม่ได้ต้องมีพนักงานสังกัดก่อน เพราะไม่สามารถปล่อยให้มีการเก็บข้อมูลว่างในช่องอื่นๆได้ ยุ่งยาก
2. ปัญหาเวลาเปลี่ยนแปลง(update)
- สมมติว่าสัญญาเช่าตึกของสาขา CB005 หัวหินหมดอายุและได้ทำการไปเช่าตึกใหม่ต้องเปลี่ยนที่อยู่ก็ต้องแก้ไขตรงช่อง branchAddress ในพนักงานทุกคน เสียเวลามากเวลามากและอาจลืมแก้ของพนักงานบางคนอีกทำให้มีความผิดพลาดได้
3. ปัญหาเวลาลบข้อมูล(delete)
- สมมติว่าพนักงานรหัส Cha393 นาย ปอปลา ตากลม ต้องการลาออกโดยที่ยังไม่มีพนักงานมาสมัครอยู่สังกัดสาขา CB003 เชียงใหม่ ข้อมูลของสาขานี้จะถูกลบไปทั้งๆที่ยังไม่ได้ปิดกิจการข้อมูลก็หายซะแล้ว
การแก้ไขก็ควรจะแยกตารางที่มีความซ้ำซ้อนเกิดขึ้นมาไว้ในอีกตาราง
CHABUCHABU_EMPLOYEE
chaempID |
gender |
chaempName |
position |
branchID |
Cha153 |
M |
ตอเต่า เต่าตอ |
ผู้จัดการ |
CB001 |
Cha110 |
F |
มอม้า คึกคัก |
ผู้จัดการ |
CB005 |
Cha393 |
M |
ปอปลา ตากลม |
พนักงาน |
CB003 |
Cha652 |
M |
ฌอเฌอ คู่กัน |
พนักงาน |
CB002 |
Cha758 |
F |
ชอช้าง อ้วนจัง |
ผู้ช่วยผู้จัดการ |
CB001 |
Cha405 |
F |
นอหนู มากมาย |
พนักงาน |
CB002 |
Cha223 |
M |
มอแมว ไม่มอง |
พนักงาน |
CB005 |
CHABUCHABU_BRANCH
branchID |
branchAddress |
CB001 |
กรุงเทพ |
CB002 |
กระบี่ |
CB003 |
เชียงใหม่ |
CB005 |
ประจวบคีรีขันธ์ |
การพึ่งพา(Dependencies)
Partial dependency
ความสัมพันธ์แบบนี้จะเกิดขึ้นได้ก็ต่อเมื่อ relation หนึ่ง ๆ มีคีย์หลักเป็นคีย์ผสม (composite key) นั่นคือ คีย์หลักของ ความสัมพันธ์นั้น ๆ ประกอบด้วย attribute หลาย attribute ความสัมพันธ์ระหว่างค่าของ attribute แบบบางส่วนเกิดขึ้นเมื่อ attribute บางส่วนของคีย์หลักสามารถระบุค่าของ attribute อื่น ๆ ที่ไม่ใช่คีย์หลักของความสัมพันธ์ได้ ซึ่งความสัมพันธ์แบบนี้จะทำให้เกิดปัญหาในเรื่องของความซ้ำซ้อน และการปรับปรุงข้อมูล
Transitive dependency
Attribute ที่ไม่ได้เป็นคีย์ แต่ระบุค่าของ attribute อื่นๆในความสัมพันธ์ได้
กลับมาที่ normalization
กล่าวโดยสรุป normalization คือการหลีกเลี่ยง
1. ต้องไม่มี multivalued attribute
2. ไม่มีการซ้ำซ้อน
3. ไม่มีการพึ่งพา
Tag ที่น่าสนใจ: e-r_diagram entity-relationship normalization composite_attribute multivalued_attribute redundancies anomalies database_design insert_operation update_operation delete_operation normalization_process data_duplication anomalies_in_database_design
หากมีข้อผิดพลาด/ต้องการพูดคุยเพิ่มเติมเกี่ยวกับบทความนี้ กรุณาแจ้งที่ http://m.me/Expert.Programming.Tutor
085-350-7540 (DTAC)
084-88-00-255 (AIS)
026-111-618
หรือทาง EMAIL: NTPRINTF@GMAIL.COM