งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

บทที่ 5 รูปแบบที่เป็นบรรทัดฐาน ( Normal Form). DBMS : Database Management System 5.25.2 Outline Data Dependency Functional Dependency Normalization 1NF.

งานนำเสนอที่คล้ายกัน


งานนำเสนอเรื่อง: "บทที่ 5 รูปแบบที่เป็นบรรทัดฐาน ( Normal Form). DBMS : Database Management System 5.25.2 Outline Data Dependency Functional Dependency Normalization 1NF."— ใบสำเนางานนำเสนอ:

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

2 DBMS : Database Management System Outline Data Dependency Functional Dependency Normalization 1NF 2NF 3NF BCNF

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

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

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

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

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

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

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

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

11 DBMS : Database Management System 5.11 ตัวอย่างตาราง Newlearn Stud_idStud_nameCousre_idSemesterYearGrade 111Jack A 111Jack B+ 111Jack B 111Jack C+ 112John B+ 112John B+ 113Tom A 113Tom B 114Mary B 114Mary C

12 DBMS : Database Management System 5.12 จากตัวอย่าง พบว่าทุกๆ 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= และ semester=1 และ year = 2005 ก็จะ มีเกรดได้ 1 ค่า คือ A ***ถ้าทั้ง 4 นี้ต้องเป็นจริงเสมอ ไม่ว่าจะเป็น นักศึกษาคนไหน หรือ วิชาใด หรือ ภาคใดหรือปี ใดๆก็ได้

13 DBMS : Database Management System 5.13 จากตาราง 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 ขึ้น

14 DBMS : Database Management System 5.14 FD ที่พบใน Relation แบ่งเป็น 2 กลุ่มได้แก่ Trivial Functional Dependency Nontrivial Functional Dependency

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

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

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

18 DBMS : Database Management System 5.18 ตัวอย่าง 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 เป็นต้น

19 DBMS : Database Management System 5.19 ตัวอย่างตาราง SCP S#P#QTYCity S1P1100London S1P2100London S2P1200Paris S2P2200Paris S3P2300Paris S4P2400London S4P4400London S4P5400London

20 DBMS : Database Management System 5.20 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 ที่เราต้องการ

21 DBMS : Database Management System 5.21 FD ของตาราง SCP 10. {S#}  {S#} **trivial FD 11. {P#}  {P#} **trivial FD 12. {S#,P#}  {S#} **trivial FD 13. {S#,P#}  {P#} **trivial FD

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

23 DBMS : Database Management System 5.23 ตัวอย่างตาราง orders Order_id orderDateProduct_idAmount 11112/5/2006P /5/2006P /5/2006P /5/2006P /5/2005P2100

24 DBMS : Database Management System 5.24 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

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

26 DBMS : Database Management System 5.26 ตัวอย่าง ตาราง พนักงาน รหัสพนักงานรหัสแผนกวันที่ทำงานเวลาเข้างานเวลาออกงาน 111D011/1/20078:0019:00 111D012/1/20078:0517:00 112D021/1/20077:3018:25 112D022/1/20076:4517:49 113D011/1/20075:4516:45

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

49 DBMS : Database Management System 5.49 รูปแบบบรรทัดฐาน (Normal Form) รูปแบบบรรทัดฐานเป็นขั้นๆ หรือระดับ แต่ละขั้นบรรทัดฐานเรียกว่า Normal Form โดยเริ่มตั้งแต่ First Normal Form(1NF) ไปจนถึง Fifth Normal Form(5NF)

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

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

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

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

54 DBMS : Database Management System 5.54 ตัวอย่าง ตารางใบสั่งซื้อสินค้า เลขที่ใบสั่งวันที่สั่ง รายการสั่งซื้อ รหัสสินค้าจำนวน 1234/5/2007P110 P220 P /5/2007P15 P /5/2007P310 -ตารางใบสั่งซื้อไม่เป็น 1NF เพราะ attribute รายการสั่งซื้อ เป็น composite attribute แบ่งได้เป็น รหัสสินค้า และ จำนวน - และ 1 ใบสั่งซื้อคือ 1 แถว ทำให้ attribute สินค้าและจำนวนมีค่า หลายๆค่า(multivalued attribute)

55 DBMS : Database Management System 5.55 ตัวอย่าง ตารางใบสั่งซื้อสินค้า : 1NF เลขที่ใบสั่งวันที่สั่ง รหัสสินค้าจำนวน 1234/5/2007P /5/2007P /5/2007P /5/2007P /5/2007P /5/2007P310 -นำตารางใบสั่งซื้อมา ปรับให้เป็น relation 1NF โดยไม่เกิด multivalued attribute และ composite attribute ค่าข้อมูลของแต่ละ attribute ภายใน 1 แถวมีค่าเพียงค่าเดียวเสมอ

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

57 DBMS : Database Management System 5.57 ตัวอย่าง ตารางพนักงาน : 1NF รหัสพนักงานวันเกิดความสูงน้ำหนักสีผม 99919/9/ ดำ 88818/8/ น้ำตาล การปรับตารางพนักงาน โดยสร้าง Attribute ใหม่ขี้นมา เท่ากับ จำนวนข้อมูลใน attribute ลักษณะ

58 DBMS : Database Management System 5.58 ตัวอย่าง ตารางการใช้บัตร เครดิต รหัสลูกค้าหมายเลขบัตร รหัสลูกค้าหมายเลขบัตร ไม่ใช่ relation : UNF Relation:1NF

59 DBMS : Database Management System 5.59 ตัวอย่าง ตาราง First S#P#CityStatusQTY S1P1London20300 P2200 P3400 P4200 P5100 P6100 S2P1Paris10300 P2400 S3P2Paris10200 S4P2London20200 P4300 P5400 Multivalued attribute

60 DBMS : Database Management System 5.60 วิธีปรับตาราง First เป็น 1NF 1. แยกคอลัมน์ที่มีมากกว่า 1 ค่า ออกเป็นแถวใหม่ 2. เพิ่มข้อมูลที่เหมาะสมเข้าไปใน คอลัมน์ที่ว่างอยู่ของแถวที่เกิดขึ้น ใหม่ 3. กำหนด Primary Key ให้กับ รีเลชั่น S#P#CityStatusQTY S1P1London20300 S1P2London20200 S1P3London20400 S1P4London20200 S1P5London20100 S1P6London20100

61 DBMS : Database Management System 5.61 ตาราง First อยู่ใน 1NF S#P#CityStatusQTY S1P1London20300 S1P2London20200 S1P3London20400 S1P4London20200 S1P5London20100 S1P6London20100 S2P1Paris10300 S2P2Paris10400 S3P2Paris10200 S4P2London20200 S4P4London20300 S4P5London20400

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

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

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

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

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

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

68 DBMS : Database Management System 5.68 พิจารณา ตาราง 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

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

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

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

72 DBMS : Database Management System 5.72 ตัวอย่าง ตาราง 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

73 DBMS : Database Management System 5.73 ตัวอย่าง ตาราง 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

74 DBMS : Database Management System 5.74 ตัวอย่าง ตารางการทำงาน รหัสพนักงานรหัสโครงการงบโครงการ (ล้านบาท) ระยะเวลาทำงานของพนักงาน ในโครงการ (วัน) 111Proj Proj Proj Proj Proj Proj Proj33040

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

76 DBMS : Database Management System 5.76 ตัวอย่าง ตารางการทำงาน(ต่อ) รหัสพนักงานรหัสโครงการระยะเวลา 111Proj Proj Proj Proj Proj Proj Proj340 พนักงาน รหัสโครงการงบโครงการ Proj115 Proj225 Proj330 โครงการ

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

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

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

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

81 DBMS : Database Management System 5.81 ตัวอย่าง ตาราง 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

82 DBMS : Database Management System 5.82 ตัวอย่าง ตาราง 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 สำหรับ C ; {A,B}  C แสดงว่า C ไม่ Transitive FD บน PK สำหรับ D ; {A,B}  C และ C  D จะได้ว่า {A,B}  D {A,B}  D แสดงว่า D Transitive FD บน PK ดังนั้น R2 ไม่อยู่ในรูป 3NF

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

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

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

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

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

88 DBMS : Database Management System 5.88 เป็น 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)

89 DBMS : Database Management System 5.89 รูปแบบบรรทัดฐานบอยซ์คอด (Boyce/Codd Normal Form: BCNF) รีเลชั่นใดๆ จะถูกพิจารณาว่าอยู่ใน BCNF หรือไม่นั้น ให้ดูว่า รีเลชั่นนั้น มีคุณสมบัติใดคุณสมบัติหนึ่งใน 3 ข้อนี้หรือไม่ 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

90 DBMS : Database Management System 5.90 ถ้ารีเลชั่นใดๆมีคุณสมบัติข้อใดข้อหนึ่งใน 3 ข้อ แล้วนั้น ก็จะพิจารณารีเลชั่นนั้นว่าอยู่ใน BCNF ก็ต่อเมื่อ ไม่มีส่วนใดส่วนหนึ่งของ primary key หรือ candidate key ที่ขึ้นกับ nonkey แอตทริบิวต์ Determinant ทุกตัวต้องเป็น Candidate key รูปแบบบรรทัดฐานบอยซ์คอด (Boyce/Codd Normal Form: BCNF)

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

92 DBMS : Database Management System 5.92 ตัวอย่าง ตาราง 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

93 DBMS : Database Management System 5.93 ตัวอย่าง ตาราง 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

94 DBMS : Database Management System 5.94 ตัวอย่าง ตารางการสอน ผู้สอนแต่ละคนสอนได้ 1 วิชาเท่านั้นใน 1 เทอม และแต่ ละวิชาใน 1 เทอม แบ่งเป็นหลายกลุ่ม (ถูกแบ่งเป็นกี่ กลุ่มก็ตาม ต้องมีผู้สอนคนเดียวเท่านั้น) คนเดียวสอนทุกกลุ่มของวิชาเดียวกันในเทอมเดียวกัน ชื่อผู้สอนเทอมชื่อวิชากลุ่มจำนวนนักศึกษา สมคิด1/2548ฐานข้อมูลเบื้องต้นSec140 สมคิด1/2548ฐานข้อมูลเบื่องต้นSec230 กานดา1/2548โครงสร้างข้อมูลSec145 สมาน2/2548ฐานข้อมูลเบื้องต้นSec140 กานดา2/2548ระบบสื่อสารข้อมูลSec145 กานดา2/2548ระบบสื่อสารข้อมูลSec230

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

96 DBMS : Database Management System 5.96 ตัวอย่าง ตารางการสอน(ต่อ) ตารางการสอน นี้ ควรพิจารณา 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

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

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

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

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

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

102 DBMS : Database Management System มี 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 ตัวอย่างตารางที่ไม่อยู่ใน BCNF

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

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

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


ดาวน์โหลด ppt บทที่ 5 รูปแบบที่เป็นบรรทัดฐาน ( Normal Form). DBMS : Database Management System 5.25.2 Outline Data Dependency Functional Dependency Normalization 1NF.

งานนำเสนอที่คล้ายกัน


Ads by Google