การแปลงแผนภาพ 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

            แต่การสร้างตารางแบบข้างบนจะพบว่ามีการเก็บข้อมูลซ้ำซ้อนกันตรง branchID กับ branchAddress มีการเก็บรหัสและที่อยู่ของสาขาซ้ำๆ เช่น กรุงเทพก็ปรากฏถึง 2 ครั้ง

            แล้วการซ้ำซ้อนเป็นความผิดปกติเป็นปัญหาอย่างไร

1.ปัญหาเวลาจะเพิ่มข้อมูล(insert)

- เวลาเพิ่มข้อมูลพนักงานต้องเสียเวลาเพิ่มข้อมูลสาขาที่พนักงานสังกัดด้วย เสียเวลา

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

2. ปัญหาเวลาเปลี่ยนแปลง(update)

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

            3. ปัญหาเวลาลบข้อมูล(delete)

- สมมติว่าพนักงานรหัส Cha393 นาย ปอปลา ตากลม ต้องการลาออกโดยที่ยังไม่มีพนักงานมาสมัครอยู่สังกัดสาขา CB003 เชียงใหม่ ข้อมูลของสาขานี้จะถูกลบไปทั้งๆที่ยังไม่ได้ปิดกิจการข้อมูลก็หายซะแล้ว

การแก้ไขก็ควรจะแยกตารางที่มีความซ้ำซ้อนเกิดขึ้นมาไว้ในอีกตาราง

CHABUCHABU_EMPLOYEE

CHABUCHABU_BRANCH

การพึ่งพา(Dependencies)

            Partial dependency

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

            Transitive dependency

            Attribute ที่ไม่ได้เป็นคีย์ แต่ระบุค่าของ attribute อื่นๆในความสัมพันธ์ได้

กลับมาที่ normalization

            กล่าวโดยสรุป normalization คือการหลีกเลี่ยง

1. ต้องไม่มี multivalued attribute

2. ไม่มีการซ้ำซ้อน

3. ไม่มีการพึ่งพา