1. Functional Dependency คืออะไร แบ่งเป็นกี่ประเภท
Functional Dependencies
ตอบ
Functional dependency (FD) คือความสัมพันธ์ระหว่าง attribute ใน Relation โดยมีลักษณะความสัมพันธ์คือ ข้อมูลของ attribute หนึ่ง (หรือกลุ่มหนึ่ง) ขึ้นอยู่กับค่าของ attribute หนึ่ง (หรือกลุ่มหนึ่ง) อย่างเป็นฟังก์ชัน
Functional Dependency สามารถแบ่งออกเป็น 4 ประเภท ดังนี้
1. Functional Dependency ที่เกิดจากความสัมพันธ์ระหว่าง Determinant และ Dependency อย่างละ 1 คำ เช่น ความสัมพันธ์ระหว่างหมายเลขบัตรประชาชนและชื่อเจ้าของบัตร
2. Functional Dependency ที่เกิดจากความสัมพันธ์ระหว่าง Determinant 1 ค่ากับ Dependency หลายค่า เช่น ความสัมพันธ์ระหว่างหมายเลขบัตรประชาชนและข้อมูลที่ปรากฏอยู่บนบัตรประชาชน
3. Functional Dependency ที่มีความสัมพันธ์ 2 ทาง ซึ่งเป็น Functional Dependencyที่ทั้ง Determinant และ Dependency ต่างสามารถทำหน้าที่ของอีกฝ่ายหนึ่งได้ เช่น ความสัมพันธ์ ระหว่างชื่อผู้จัดการโครงการ (Attribute “MANAGER”)กับชื่อโครงการ(Attribute“PROJECT_NO”)ซึ่ง ถ้าทราบชื่อของโครงการจะสามารถทราบได้ถึงชื่อของโครงการที่ผู้จัดการนั้น เป็นเจ้าของได้ และเมื่อทราบชื่อโครงการก็จะสามารถทราบถึงชื่อของผู้จัดการโครงการนั้นเช่น เดียวกัน
4. Functional Dependency ที่ต้องใช้ Determinant มากกว่า 1 ค่า เพื่ออ้างถึง Dependency เช่น ความสัมพันธ์ระหว่างจำนวนสินค้าที่ผลิตได้ของสินค้าแต่ละชนิดภายใต้สายการผลิตต่าง ๆ
นิยาม X à Y ก็ต่อเมื่อ ทุกค่าของ X ใน R สัมพันธ์กับค่าของ Y เพียงค่าเดียว
นั่นคือ หากรู้ว่าค่า X เป็นอะไร ก็จะระบุค่า Y ได้
เช่น SCode à SName, Faculty, Birthday
Birthday à Age
{ อำเภอ, จังหวัด } à รหัสไปรษณีย์
รหัสไปรษณีย์ à { อำเภอ, จังหวัด }
คุณสมบัติของ Functional Dependency
- FD ไม่สามารถสรุปมากจาก Relation state ได้โดยอัตโนมัติ ในบางกรณี สถานะหนึ่งของ relation อาจสอดคล้องต่อ FD บางอย่าง แต่พอมีการเปลี่ยนแปลงข้อมูล อาจจะขัดแย้งต่อ FD นั้นได้
- FD มักได้มาจากคุณสมบัติ หรือ semantic (ความหมาย) ของ attribute ใน relation
- Relation หนึ่งๆ มีข้อกำหนดเกี่ยวกับ FD หรือ FD constraints , legal relation state หรือ legal extension คือ relation state ที่สอดคล้องกับ FD constraints ของ relation นั้น
2. จงอธิบายความหมายของ Repeating Group พร้อมยกตัวอย่าง
ตอบ
Repeating Group หมายถึง รีเลชั่น ของตารางเกิดมีกลุ่มข้อมูลซ้ำกันหรือกล่าวอีกนัยหนึ่งคือแต่ละช่องเซลของรีเลชั่นจะถูกจัดเก็บข้อมูลมากกว่า 1 ค่า ส่งผลให้รีเลชั่น นี้ มีโครงสร้างที่ไม่สอดคล้องตามคุณสมบัติของ 1NF
ยกตัวอย่างเช่น ตาราง Oder สังเกตว่าลูกค้า(Attribute“CUST_NO”) 1 คนสามารถมีรายการสั่งซื้อ (Attribute “ORDER_CONTENT”) ได้มากกว่า 1 รายการ ดังนั้นจึงกล่าวได้ว่า (Attribute“CUST_NO”) นี้ มีความสัมพันธ์กับ(Attribute“ORDER_CONTENT”) ในแบบ Repeating Group ส่งผลให้รีเลชั่น นี้ มีโครงสร้างที่ไม่สอดคล้องตามคุณสมบัติของ 1NF
3. จงอธิบายความหมายของ Transitive Dependency พร้อมยกตัวอย่าง
ตอบ
Transitive Dependency หมายถึง รีเลชั่น ของตารางเกิดมี Attribute บางตัวที่ไม่ได้เป็นคีย์หลัก มีคุณสมบัติในการกำหนดค่าของอื่นที่ไม่ใช่คีย์หลักในตารางรีเลชั่นหรือกล่าวอีกนัยหนึ่งคือ มี 2 Attribute ที่ไม่ใช่คีย์หลัก ที่สามารถระบุค่าระหว่างกันได้
ยกตัวอย่างเช่น ในตาราง Oder สินค้าของลูกค้าจาก รีเลชั่น “Cust” มีค่าของ Attribute “CITY” และ Attribute “ZONE_SALE” ปรากฏข้อมูลซ้ำกันเป็นคู่ ๆ หรือกล่าวอีกนัยหนึ่งคือ ทั้ง 2 Attribute สมารถระบุค่าระหว่างกันได้ กล่าวคือ เมื่อระบุค่าให้กับ Attribute “ZONE_SALE” จะสามารถทราบถึงเมืองใน Attribute “CITY” ได้ ดังนั้นจึงทำให้ รีเลชั่นนี้ขาดคุณสมบัติของ 3NF และยังก่อให้เกิดปัญหาความผิดพลาดทางด้าน Anomaly
4.จงตรวจสอบตารางต่อไปว่าอยู่ในรูปของ 1NF 2NF และ 3NF แล้วหรือยัง ถ้ายัง Normalization ให้อยู่ในรูปดังกล่าว
P_ID | P_Name | E_ID | E_ Name | Job_Calss | Chg_Hour | Hour |
11 | EAU Web Site | 103 | สมชาย ไม้ดี | SA | 500 | 23.8 |
101 | แท่น งามยิ่ง | Database Designer | 450 | 19.4 | ||
105 | ชาย ดีศรี | Database Designer | 450 | 35.7 | ||
106 | แม็ก ยอดยิ่ง | Programmer | 400 | 12.6 | ||
102 | อมร ดีศรี | SA | 500 | 23.8 |
จากตารางจะสังเกตว่าไม่มีคุณสมบัติครบเป็น 1NF เพราะเป็นรีเลชั่นที่มีคีย์หลักของรีเลชั่น คือ มี (Attribute “P_ID”) เป็นคีย์หลัก แล้วแต่มีกลุ่มข้อมูลซ้ำซ้อน (Repeating Group) อยู่ในรีเลชั่นหรือในแต่ละช่องหรือเซล ของรีเลชั่นมีการเก็บข้อมูลหลายค่าคือ Attribute “E_ID”นี้มีความสัมพันธ์กับ Attribute “P_Name” ในแบบ Repeating Group ส่งผลให้ Relation นี้ มีโครงสร้างที่ไม่สอดคล้องตามคุณสมบัติของ 1NF
P_ID | P_Name | E_ID | E_ Name | Job_Calss | Chg_Hour | Hour |
11 | EAU Web Site | 103 | สมชาย ไม้ดี | SA | 500 | 23.8 |
11 | EAU Web Site | 101 | แท่น งามยิ่ง | Database Designer | 450 | 19.4 |
11 | EAU Web Site | 105 | ชาย ดีศรี | Database Designer | 450 | 35.7 |
11 | EAU Web Site | 106 | แม็ก ยอดยิ่ง | Programmer | 400 | 12.6 |
11 | EAU Web Site | 102 | อมร ดีศรี | SA | 500 | 23.8 |
P_ID | P_Name | E_ID | E_ Name | Job_Calss | Chg_Hour | Hour |
11 | EAU Web Site | 103 | สมชาย ไม้ดี | SA | 500 | 23.8 |
11 | EAU Web Site | 101 | แท่น งามยิ่ง | Database Designer | 450 | 19.4 |
11 | EAU Web Site | 105 | ชาย ดีศรี | Database Designer | 450 | 35.7 |
11 | EAU Web Site | 106 | แม็ก ยอดยิ่ง | Programmer | 400 | 12.6 |
11 | EAU Web Site | 102 | อมร ดีศรี | SA | 500 | 23.8 |
22 | BU Reglstration | 114 | สุรศักดิ์ ดีงาม | Application Designer | 300 | 24.6 |
22 | BU Reglstration | 118 | กมล ไม้งาม | General Support | 200 | 45. |
22 | BU Reglstration | 104 | นาย ยิ่งยอด | SA | 500 | 32.4 |
22 | BU Reglstration | 106 | แม็ก ยอดยิ่ง | Programmer | 400 | 20 |
22 | BU Reglstration | 112 | ธิดา ไม้งาม | Database Designer | 450 | 44.0 |
22 | BU Reglstration | 105 | ชาย ดีศรี | Database Designer | 450 | 44.0 |
ไม่มีคุณสมบัติเป็นไปตาม 2NF เพราะจะเห็นได้ว่า Relation ของตาราง จะมี Attribute (E_ID ,P_ID) เป็น Attribute ที่ทำให้ข้อมูลในแต่ละ Tuple มีค่าไม่ซ้ำกัน ดังนั้น Attribute ทั้ง 2 จึงทำหน้าที่เป็น Relation Key และพิจารณาค่าของ Attribute “E_ID”, “E_ Name” , “Job_Calss”, “Chg_Hour”,“ Hour ” จะสังเกตเห็นว่า Tuple ที่ประกอบขึ้นจาก Attribute เหล่านี้ จะมีข้อมูลซ้ำกันเป็นชุด ๆ และมีเพียง Attribute “P_Name” เท่านั้นที่มีค่าแปรเปลี่ยนตามค่าของ Relation Key ดังนั้นจึงสามารถเขียนด้วย Functional Dependency เพิ่มเติมได้ดังนี้
- d1: E_ID, P_ID P_Name
- d2: E_ID E_ Name ,Job_Calss ,Chg_Hour, Hour
ใน d2 จะสังเกตเห็นว่า Attribute “E_ Name” , “Job_Calss”, “Chg_Hour”และ “ Hour ”, เป็น Nonprime Attribute ของ Relation ที่ไม่ได้ขึ้นอยู่กับเฉพาะ Relation Key แต่กลับขึ้นอยู่กับค่าของ Attribute “E_ID” ด้วย แสดงว่า d2 นี้ไม่เป็นไปตามคุณสมบัติข้อ 2
ดังนั้น Relation นี้ จึงไม่มีคุณสมบัติเป็นไปตามคุณสมบัติของ 2NF จึงต้องแยก Relation นี้ ออกเป็น 2 Relation ตาม d1และ d2 ดังนี้
E P_Name
E_ID | P_ID | P_Name |
103 | 11 | EAU Web Site |
101 | 11 | EAU Web Site |
105 | 11 | EAU Web Site |
106 | 11 | EAU Web Site |
102 | 11 | EAU Web Site |
114 | 22 | BU Reglstration |
118 | 22 | BU Reglstration |
104 | 22 | BU Reglstration |
106 | 22 | BU Reglstration |
112 | 22 | BU Reglstration |
105 | 22 | BU Reglstration |
E
E_ID | E_ Name | Job_Calss | Chg_Hour | Hour |
103 | สมชาย ไม้ดี | SA | 500 | 23.8 |
101 | แท่น งามยิ่ง | Database Designer | 450 | 19.4 |
105 | ชาย ดีศรี | Database Designer | 450 | 35.7 |
106 | แม็ก ยอดยิ่ง | Programmer | 400 | 12.6 |
102 | อมร ดีศรี | SA | 500 | 23.8 |
114 | สุรศักดิ์ ดีงาม | Application Designer | 300 | 24.6 |
118 | กมล ไม้งาม | General Support | 200 | 45. |
104 | นาย ยิ่งยอด | SA | 500 | 32.4 |
106 | แม็ก ยอดยิ่ง | Programmer | 400 | 20 |
112 | ธิดา ไม้งาม | Database Designer | 450 | 44.0 |
105 | ชาย ดีศรี | Database Designer | 450 | 44.0 |
จาก Relation นี้ ถึงแม้จะมีโครงสร้างเป็นไปตามคุณสมบัติ 2NF แต่จะเห็นว่าค่าของ Attribute “Job_Calss” , “Chg_Hour”และ “ Hour ” ยังปรากฏข้อมูลที่มีซ้ำกันอยู่เป็นคู่ ๆ หรือกล่าวอีกนัยหนึ่งทั้ง 2 Attribute สามารถรับบุค่าระหว่างกันได้ ดังนั้น Relation นี้จึงขาดคุณสมบัติของ 3NF และยังก่อให้เกิดปัญหาความผิดพลาดทางด้าน Anomaly
จากปัญหา Anomaly ที่เกิดขึ้นจาก Transitive Dependency เหล่านี้จึงต้องทำการแยก Attribute ที่ทำให้เกิด Transitive Dependency ของ Relation นี้ ออกมาเป็น Relation ใหม่ ซึ่งจากตารางได้แก่ Attribute “Job_Calss” , “Chg_Hour”และ “ Hour ” ดังนี้
E2
E_ID | E_ Name | Job_Calss |
103 | สมชาย ไม้ดี | SA |
101 | แท่น งามยิ่ง | Database Designer |
105 | ชาย ดีศรี | Database Designer |
106 | แม็ก ยอดยิ่ง | Programmer |
102 | อมร ดีศรี | SA |
114 | สุรศักดิ์ ดีงาม | Application Designer |
118 | กมล ไม้งาม | General Support |
104 | นาย ยิ่งยอด | SA |
106 | แม็ก ยอดยิ่ง | Programmer |
112 | ธิดา ไม้งาม | Database Designer |
105 | ชาย ดีศรี | Database Designer |
Job Chg Hour
Job_Calss | Chg_Hour | Hour |
SA | 500 | 23.8 |
Database Designer | 450 | 19.4 |
Database Designer | 450 | 35.7 |
Programmer | 400 | 12.6 |
SA | 500 | 23.8 |
Application Designer | 300 | 24.6 |
General Support | 200 | 45. |
SA | 500 | 32.4 |
Programmer | 400 | 20 |
Database Designer | 450 | 44.0 |
Database Designer | 450 | 44.0 |
5.จงวิเคราะห์และจัดทำ Normalization ระบบการลงทะเบียนของนักศึกษา ให้มีความซ้ำซ้อนน้อยที่สุด
รหัส นศ. | ภาคเรียนที่ | รหัสวิชา | ชื่อวิชา | ประเภทวิชา | ชื่อประเภท | หน่วยกิต | เกรด |
4501 | 1/45 | A01 | คณิตศาสตร์คอม | 02 | ชีพบังคับ | 3 | F |
1/45 | A03 | ภาษาไทย | 01 | พื้นฐาน | 3 | C | |
2/45 | A01 | คณิตศาสตร์คอม | 02 | ชีพบังคับ | 3 | D | |
2/45 | A04 | ภาษาอังกฤษ1 | 01 | พื้นฐาน | 3 | D+ | |
4052 | 1/45 | A01 | คณิตศาสตร์คอม | 02 | ชีพบังคับ | 3 | B |
1/45 | A04 | ภาษาอังกฤษ1 | 01 | พื้นฐาน | 3 | C | |
2/45 | A02 | ระบบฐานข้อมูล | 03 | ชีพเลือก | 3 | B | |
2/45 | A05 | โปรแกรมสำเร็จรูป1 | 02 | ชีพบังคับ | 3 | D | |
4503 | 1/45 | A06 | การสื่อสารข้อมูล | 01 | พื้นฐาน | 3 | A |
1/45 | A04 | ภาษาอังกฤษ1 | 03 | ชีพเลือก | 3 | C | |
2/45 | A05 | โปรแกรมสำเร็จรูป1 | 02 | ชีพบังคับ | 3 | D | |
4506 | 1/45 | A03 | ภาษาไทย | 01 | พื้นฐาน | 3 | B+ |
1/45 | A04 | ภาษาอังกฤษ1 | 01 | พื้นฐาน | 3 | C |
จะได้อยู่ในรูป
รหัส น.ศ. | ภาคเรียน | รหัสวิชา | ประเภทวิชา | เกรด |
4501 | 1/45 | A01 | 02 | F |
4501 | 1/45 | A03 | 01 | C |
4501 | 2/45 | A01 | 02 | D |
4501 | 2/45 | A04 | 01 | D+ |
4052 | 1/45 | A01 | 02 | B |
4052 | 1/45 | A04 | 01 | C |
4052 | 2/45 | A02 | 03 | B |
4052 | 2/45 | A05 | 02 | D |
4503 | 1/45 | A06 | 01 | A |
4503 | 1/45 | A04 | 03 | C |
4503 | 2/45 | A05 | 02 | D |
4506 | 1/45 | A03 | 01 | B+ |
4506 | 1/45 | A04 | 01 | C |
ประเภทวิชา | ชื่อประเภท | หน่วยกิต |
01 | พื้นฐาน | 3 |
02 | ชีพบังคับ | 3 |
03 | ชีพเลือก | 3 |
รหัสวิชา | ชื่อวิชา |
A01 | คณิตศาสตร์คอม |
A02 | ระบบฐานข้อมูล |
A03 | ภาษาไทย |
A04 | ภาษาอังกฤษ1 |
A05 | โปรแกรมสำเร็จรูป1 |
A06 | การสื่อสารข้อมูล |
ไม่มีความคิดเห็น:
แสดงความคิดเห็น