2. การขึ้นต่อกันของข้อมูล
• Data Dependency = การขึ้นต่อกันของข้อมูล
• เกิดจาก Attribute หนึ่งมีความสัมพันธ์กับอีก Attribute หนึ่ง
• แบ่งออกเป็น 3 ประเภท
– Functional Dependency
– Multivalued Dependency
– Join Dependency
• ในคอร์สนี้จะศึกษาเพียง Functional Dependency เท่านั้น
3. ฟังก์ชันการขึ้นต่อกัน
• Functional Dependency (FD) = ฟังก์ชันการขึ้นต่อกัน
• FD จะเกิดขึ้นเมื่อมีค่าของ Attribute หนึ่งสอดคล้องกับอีก
Attribute หนึ่งเพียงหนึ่งค่า
– นิยาม เมื่อ R เป็น Relation และให้ A, B เป็นส่วนหนึ่งของ Attribute ที่อยู่ใน
R ถ้าหากค่า A นั้นสอดคล้องกับค่า B เพียงหนึ่งค่า จะกล่าวได้ว่า “B นั้นขึ้นต่อ A”
หรือ “A เป็นตัวกาหนด B” หรือ A -> B
– เราจะเรียก A ว่าตัวกาหนด (Determinant) และ B ว่าตัวถูกระบุค่า
(Dependent)
• Functional Dependency มีผลต่อการเลือก PK และการทา NF
4. ลักษณะของฟังก์ชันการขึ้นต่อกัน
• Trivial Functional Dependency
– ความสัมพันธ์ระหว่าง Determinant Set กับ Determinant Subset
– ไม่รู้ความหมายอะไรในตาราง ก็สามารถบอก Dependent ได้
– ไม่ค่อยสาคัญเท่าไร
• Nontrivial Functional Dependency
– ความสัมพันธ์ระหว่าง Determinant Attribute Set กับ Attribute อื่น
– ต้องเข้าใจความหมาย ความสัมพันธ์ เงื่อนไขของ Attribute ในตาราง ถึง
จะบอก Dependent ได้
5. Trivial Functional Dependency
id char_name hair_id skin_color level class_name
thep444 Adolescence 2 f0e7c8 34 Archer
thep444 AcetoOrceiN 17 f0e7c8 68 Knight
madoka555 QBayDesu 15 ffffff 57 Magician
• ในตารางนี้มี Trivial Functional Dependency เท่าไร
6. Nontrivial Functional Dependency
id char_name hair_id skin_color level class_name
thep444 Adolescence 2 f0e7c8 34 Archer
thep444 AcetoOrceiN 17 f0e7c8 68 Knight
madoka555 QBayDesu 15 ffffff 57 Magician
• ในตารางนี้มี Nontrivial Functional Dependency
– {char_name} {id, hair_id, skin_color, level, class_name}
8. Nontrivial Functional Dependency
รหัสพนักงาน ชื่อพนักงาน รหัสแผนก วันที่ทางาน เวลาเข้างาน เวลาออกงาน
226 Keiseiie Hara FKnL 2100/6/28 7:45 18:10
227 Kawada I. Inoue LL 2100/6/30 8:01 19:24
226 Keiseiie Hara FKnL 2100/6/30 6:19 17:16
228 Moriyama Aiko HR 2100/7/1 8:59 16:44
229 Keiseiie Kune CP 2100/7/1 7:33 20:54
229 Keiseiie Kune CP 2100/7/3 7:42 19:17
• ในตารางนี้มี Nontrivial Functional Dependency อะไรบ้าง?
9. รูปแบบของฟังก์ชันการขึ้นต่อกัน
• Full Functional Dependency
– เกิดจากทุก Attribute ใน Determinant Set กาหนดค่า Attribute ทั้งหมด
– ถ้า Determinant Set D สามารถกาหนดทุกค่าใน Attribute แล้ว D จะเป็น
Primary Key
• Partial Dependency
– เกิดจาก Dependent Set ขึ้นกับบางส่วนของ Attribute ที่เป็น PK
• Transitive Dependency
– เกิดจาก Dependent Set ขึ้นกับบางส่วนของ Attribute ที่ไม่เป็น PK
10. Full Functional Dependency
รหัสพนักงาน ชื่อพนักงาน รหัสแผนก ตาแหน่งงาน เงินเดือน
226 Keiseiie Hara FKnL L Hand General Knight 14800
227 Kawada I. Inoue LL Linguistics Lecturer 13900
228 Moriyama Aiko HR Salary Manager 10430
229 Keiseiie Kune CP Computer Programmer 12040
230 Tadachizu Yoichi FKnL L Hand Security Guard 9400
231 Meira Meiji P Super General Priest 9000
• {รหัสพนักงาน} --> {ชื่อพนักงาน, รหัสแผนก, ตาแหน่งงาน, เงินเดือน}
11. Partial Functional Dependency
id project_id staff_name project_name Advisor_id dept_id
104450 1 Thunder Storm 1.. 2… 3… Go! 21004 O01
104450 2 Thunder Storm True Love Camp 32850 H32
104451 1 Bipinnaria Larva 1.. 2… 3… Go! 21004 O01
• {id} {staff_name}
• {project_id} {project_name, advisor_id, dept_id}
12. Transitive Functional Dependency
proj_name staff_id job_class job_id เงินเดือน
AbBeaw Project 120 Presenter 20540 6100
AbBeaw Project 145 Presenter 20540 6100
Makenai Camp 228 First Aid Manager 31001 8020
Makenai Camp 130 Director 90001 15400
Makenai Camp 144 Presenter 20540 7800
Makenai Camp 210 Entertainer 90100 8020
• {job_id} {job_class}
• {job_class} {job_id}
14. Normalization
• Normalization = การทาบรรทัดฐาน, การทาให้เป็นมาตรฐาน
• กระบวนการหนึ่งที่มีอยู่ในการออกแบบฐานข้อมูล
– การแก้ไขตารางข้อมูลให้มีการซ้าซ้อนของข้อมูลน้อยลง
– นิยมทาไปพร้อมกันกับการออกแบบ ER Diagram
• Normalization จะทาตามลาดับไปเรื่อย ๆ
– แต่ละระดับเรียกว่า Normal form
– Normal Form (NF) = รูปแบบบรรทัดฐาน
15. Normal Form
• ข้อกาหนดในการแก้ไขตารางภายในฐานข้อมูล
• รูปแบบที่มีตัวเลขมาก ข้อกาหนดยิ่งมากขึ้น แต่ฐานข้อมูลที่ได้ยิ่งดีขึ้น
– รูปแบบบรรทัดฐานที่ 1 (1NF) จะดีกว่ารูปแบบบรรทัดฐานที่ 0 (0NF)
– รูปแบบบรรทัดฐานที่ 2 (2NF) จะดีกว่ารูปแบบบรรทัดฐานที่ 1
– ...
• ในปัจจุบันรูปแบบบรรทัดฐานหลักมีทั้งหมด 9 รูปแบบ[1]
– 1NF, 2NF, 3NF, EKNF, BCNF, 4NF, 5NF, DKNF, 6NF
• ส่วนใหญ่นิยมแก้ไขถึงรูปแบบบรรทัดฐานที่ 3 (3NF)
16. ข้อเสียของตารางที่ไม่ทา Normal Form
• ปัญหาการเพิ่มข้อมูล (Insertion Anomalies)
– การเพิ่มข้อมูลที่มีข้อมูลไม่ครบตาม Schema
– อาจใส่ค่า null แต่ null เป็นค่าที่เราไม่อยากได้
• ปัญหาการแก้ไขข้อมูล (Update Anomalies)
– การแก้ไขข้อมูลที่มีความซ้าซ้อนกันในตาราง
– ไล่แก้ไปเรื่อย ๆ
• ปัญหาการลบข้อมูล (Deletion Anomalies)
– ข้อมูลใน Attribute นั้นไม่อยากลบ แต่ข้อมูลนั้นอยู่ที่ Tuple ที่อยากลบ
17. Insertion Anomalies
id char_name hair_id skin_color level class_name
thep444 Adolescence 2 f0e7c8 34 Archer
0816581025 Sensation 10 eed99b 11 Novice
madoka555 QBayDesu 15 ffffff 57 Magician
darni_maria FuxkYeah-_-!! 14 ffffee 7 Archer
kodman_cs นู๋IปJIทย 7 f0e7c8 13 Novice
id
thunderstrom
18. Update Anomalies
id char_name hair_id skin_color level class_name
thep444 Adolescence 2 f0e7c8 34 Archer
0816581025 Sensation 10 eed99b 11 Archer
madoka555 QBayDesu 15 ffffff 57 Magician
darni_maria FuxkYeah-_-!! 14 ffffee 7 Archer
kodman_cs นู๋IปJIทย 7 f0e7c8 13 Archr
0876551000 n๐IIหล 1 343232 1 Novice
19. Deletion Anomalies
id char_name hair_id skin_color level class_name
thep444 Adolescence 2 f0e7c8 34 Archer
0816581025 Sensation 10 eed99b 11 Archer
madoka555 QBayDesu 15 ffffff 57 Magician
darni_maria FuxkYeah-_-!! 14 ffffee 7 Archer
kodman_cs นู๋IปJIทย 7 f0e7c8 13 Archr
0876551000 n๐IIหล 1 343232 1 Novice
20. รูปแบบบรรทัดฐานที่ 1
• รูปแบบบรรทัดฐานที่ 1 = First Normal Form (1NF)
• ตารางในข้อกาหนด 1NF ต้องมี Attribute ใด ๆ อยู่ภายใน Attribute
– ถ้ามี Attribute ซ้อนอยู่ จะเอา Composite Attribute ออก
• ข้อมูลแบบ Multivalue ต้องแยกเป็นแต่ละแถว
• ทุก ๆ Attribute ต้องขึ้นกับ Primary Key
• Schema ที่แปลงจาก ER Diagram จะเป็น 1NF ในทันที
21. การทาตารางเป็น 1NF
Serv Server Board Charac Character Character Info
ID
ID Name Name ter ID Name LV Class Name Job Name
0 Mochi 1 Adolescence 34 Archer
thep44 Nopakun~* Fighter
1 Adolescence 41 Scout
Takoyaki
thanyapol thanyapol 15 NeoS Backpacker Mechanic
1 99
78 parazettamon Bard
Takoyaki kunemata kunemata Spell User
150 Sufflez 76 Sage
0 Mochi 104 Harasama 64 Dark Stalker
Fighter
olfactory harasama 119 Reizinixc 99 Bounty Hunter
1 Takoyaki
183 ReizinixcII 36 Backpacker Tatarabe
22. การทาตารางเป็น 1NF
• Attribute ใดที่ซ้อนกับ Attribute ให้เอา Composite Attribute ออก
Serv Server Board Charac Character Character Info
ID
ID Name Name ter ID Name LV Class Name Job Name
Serv Server Board Charac Character
ID LV Class Name Job Name
ID Name Name ter ID Name
23. การทาตารางเป็น 1NF
• ข้อมูลแบบ Multivalue ต้องแยกเป็นแต่ละแถว
Serv Server Board Charac Character
ID LV Class Name Job Name
ID Name Name ter ID Name
0 Mochi thep44 Nopakun~* 1 Adolescence 34 Fighter Archer
1 Takoyaki thep44 Nopakun~* 1 Adolescence 41 Fighter Scout
1 Takoyaki thanyapol thanyapol 15 NeoS 99 Backpacker Mechanic
1 Takoyaki kunemata kunemata 78 parazettamon 99 Spell User Bard
1 Takoyaki kunemata kunemata 150 Sufflez 76 Spell User Sage
0 Mochi olfactory harasama 104 Harasama 64 Fighter Dark Stalker
1 Takoyaki olfactory harasama 119 Reizinixc 99 Fighter Bounty Hunter
1 Takoyaki olfactory harasama 183 ReizinixcII 36 Backpacker Tatarabe
24. การทาตารางเป็น 1NF
• ทุก Attribute ต้องขึ้นกับ Primary Key
Serv Server Board Charac Character
ID LV Class Name Job Name
ID Name Name ter ID Name
0 Mochi thep44 Nopakun~* 1 Adolescence 34 Fighter Archer
1 Takoyaki thep44 Nopakun~* 1 Adolescence 41 Fighter Scout
1 Takoyaki thanyapol thanyapol 15 NeoS 99 Backpacker Mechanic
1 Takoyaki kunemata kunemata 78 parazettamon 99 Spell User Bard
1 Takoyaki kunemata kunemata 150 Sufflez 76 Spell User Sage
0 Mochi olfactory harasama 104 Harasama 64 Fighter Dark Stalker
1 Takoyaki olfactory harasama 119 Reizinixc 99 Fighter Bounty Hunter
1 Takoyaki olfactory harasama 183 ReizinixcII 36 Backpacker Tatarabe
25. รูปแบบบรรทัดฐานที่ 2
• รูปแบบบรรทัดฐานที่ 2 = Second Normal Form (2NF)
• มีหลายเหตุผลที่ต้องทาตารางให้เป็น 2NF
– ปัญหาความซ้าซ้อนของข้อมูล
• ตาราง 2NF ต้องผ่านคุณสมบัติทั้งหมดของ 1NF มาก่อน
• 2NF จะไม่มี Dependent Set ใด ๆ ขึ้นกับบางส่วนของ Primary Key
– ไม่มี Partial Dependency
26. การทาตารางเป็น 2NF
• พิจารณา Partial Dependency ของตาราง
Serv Server Board Charac Character
ID LV Class Name Job Name
ID Name Name ter ID Name
{Serv ID, Character ID} {Server Name, ID, Board Name, Character
Name, LV, Class Name, Job Name}
{Serv ID} {Server Name}
27. การทาตารางเป็น 2NF
• แยกตาราง โดยย้าย Dependent Set ให้ไปอยู่ที่ตารางใหม่ และให้
ตารางใหม่มี PK คือ Determinant Set
• ตั้งชื่อ Schema ใหม่ที่แยกออกมา
Serv Server
ตารางรายชื่อเซิร์ฟเวอร์ ID Name
ตารางลักษณะตัวละคร
Serv Board Character Character
ID LV Class Name Job Name
ID Name ID Name
28. รูปแบบบรรทัดฐานที่ 3
• รูปแบบบรรทัดฐานที่ 3 = Third Normal Form (3NF)
• ในบางครั้ง การทาตาราง 2NF ยังไม่พอ
– ปัญหาความซ้าซ้อนของข้อมูลอีกแล้ว
• ตาราง 3NF ต้องผ่านคุณสมบัติทั้งหมดของ 2NF มาก่อน
• 3NF จะไม่มี Dependent Set ใด ๆ ขึ้นกับ Attribute ใด ๆ ที่ไม่เป็น
Primary Key
– ไม่มี Transitive Dependency
29. การทาตารางเป็น 3NF
• พิจารณา Transitive Dependency ของตาราง
• อย่าลืมพิจารณาตารางที่ถูกแยกจาก 2NF ด้วย
Serv Server
ตารางรายชื่อเซิร์ฟเวอร์ ID Name
ตารางลักษณะตัวละคร
Serv Board Character Character
ID LV Class Name Job Name
ID Name ID Name
{ID} {Board Name}
{Job Name} {Class Name}
30. ECO Job System[2]
1st Class 2nd Class 3rd Class 1st Class 2nd Class 3rd Class 1st Class 2nd Class 3rd Class
Blademaster Sorcerer Blacksmith
Swordman Gladiator Wizard Force Master Tatarabe Maestro
Bounty Hunter Sage Machinery
Knight Elementer Alchemist
Fencer Guardian Shaman Astralist Farmer Harvest
Dark Stalker Enchanter Marionette
Assasin Druid Explorer
Scout Eraser Vates Cardinal Ranger Strider
Commando Bard Treasure Hunter
Striker Cabalist Trader
Archer Hawker Warlock Soultaker Merchant Royal Dealer
Gunner Warlock Gambler
Fighter Class Spell User Class Backpacker Class
31. การทาตารางเป็น 3NF
• แยกตาราง โดยย้าย Dependent Set ให้ไปอยู่ที่ตารางใหม่ และให้
ตารางใหม่มี PK คือ Determinant Set
• ตั้งชื่อ Schema ใหม่ที่แยกออกมา
ตารางลักษณะตัวละคร
Serv Character Character
ID LV Job Name
ID ID Name
ตารางรายชื่อเซิร์ฟเวอร์ ตารางชื่อในเว็บบอร์ด ตารางคลาสอาชีพ
Serv ID Server Name ID Board Name Job Name Class Name
32. รูปแบบบรรทัดฐานบอยซ์คอดด์
• ในเชิงธุรกิจ การทาตารางถึง 3NF นั้นเพียงพอแล้ว แต่บางครั้งก็ยังไม่พอ
• การพิจารณา BCNF ไม่ต้องพิจารณา 1NF, 2NF, 3NF ก็ได้
• ลักษณะของ Relation ที่สามารถนามาพิจารณา BCNF
– มี Candidate Key ตั้งแต่ 2 ตัวขึ้นไป
– Primary Key เป็น Composite Key
– Candidate Key บางตัวมีการใช้ Attribute เดียวกันเป็นส่วนหนึ่งของ
Candidate Key
• BCNF จะไม่มี Attribute บางส่วนที่เป็น PK ขึ้นกับบาง Attribute ที่ไม่
เป็น PK
33. การทาตารางเป็น BCNF
• ผู้ พั ฒ นาระบบคนหนึ่ ง อยากให้ พิ จ ารณาว่ า ตารางการสอนของ
มหาวิทยาลัย S นั้นอยู่ใน BCNF หรือไม่
Teacher Name Semester Year Course ID sec Capacity
Mera Meiji 1 2001 02358230 1 300
Mera Meiji 2 2001 02358230 2 300
Keiseiie Kune 1 2001 02358101 1 300
Edogawa Asaki 1 2002 01411103 1 40
Inoue Shuichi 1 2002 01411103 2 40
Keiseiie Hara 2 2002 01999610 1 30
Inoue Fumiko 2 2002 01420101 1 300
34. การทาตารางเป็น BCNF
• ภายในตารางไม่พบ Transitive Dependency, Partial Dependency
ดังนั้นตารางนี้เป็นตาราง 3NF
• ตารางนี้ไม่เป็น BCNF เพราะ {Semester, Year, Course ID, sec} เป็น
ตัวกาหนดให้กับ {Teacher Name}
Teacher Name Semester Year Course ID sec Capacity
35. การทาตารางเป็น BCNF
• การเปลี่ยนให้เป็น BCNF ทาได้โดยเปลี่ยน Determinant Set ที่ไม่ใช่
PK มาเป็น PK แทน ส่วน Dependent Set นั้นเปลี่ยนเป็น Attribute
ธรรมดา
Teacher Name Semester Year Course ID sec Capacity
Teacher Name Semester Year Course ID sec Capacity
36. การทาตารางเป็น BCNF
• ในกรณีที่ Determinant Set เป็น Attribute ที่ไม่ได้อยู่ใน PK ทั้งหมด
การเปลี่ยนเป็น BCNF อาจทาให้เกิด Partial Dependency ได้
A B C D E
C B D A E
B C A
B C D E
37. รูปแบบบรรทัดฐานที่ 4
• รูปแบบบรรทัดฐานที่ 4 = Fourth Normal Form (4NF)
• ส่วนใหญ่ไม่นิยมทากัน
• ตาราง 4NF ต้องผ่านคุณสมบัติทั้งหมดของ BCNF มาก่อน
• คอร์สนี้ไม่มีเรื่อง 4NF
38. Denormalization
• ข้อมูลที่ผ่าน Normalization แล้ว จะทาให้ข้อมูลซ้าซ้อนลดลง และ
Schema มากขึ้น
• การคืนสภาพของตาราง schema ที่ Normalized แล้ว จะใช้วิธี
Natural Join
– ยิ่ง schema มาก record ที่ใช้ในการ Natural Join จะยิ่งมากขึ้นเรื่อย ๆ
• Denormalization ช่วยเพิ่มความเร็วในการ query ยิ่งขึ้น
• การตัดสินใจ Denormalization ขึ้นกับจุดประสงค์ที่ใช้งานตาราง
40. ประเภทของ Physical Storage
• Physical = ทางกายภาพ, Storage = หน่วยเก็บ
• Volatile
– เมื่อไฟดับ ข้อมูลภายในหายทั้งหมด
• Non-Volatile
– เมื่อไฟดับ ข้อมูลที่เก็บไว้ภายในยังอยู่คงเดิม
– เหมาะสาหรับการสารองข้อมูล, ทา Backup
41. Volatile Physical Storage Media
• Cache
– หน่วยความจาที่มีความเร็วสูงสุด
– แต่ราคาแพงสุดเหมือนกัน
– จัดการโดย Hardware ของ Computer
• Main Memory
– เวลาในการเข้าถึงช้ากว่า Cache แต่ยังถือว่าเร็วมาก (ระดับนาโนวินาที)
– ปัจจุบันราคาเริ่มถูกลงและความจุมากขึ้นเรื่อย ๆ
• เมื่อไฟดับ ข้อมูลใน Cache และ Main Memory จะหายทั้งหมด
42. Non-Volatile Physical Storage Media
• Flash Memory
– สามารถเขียนแล้วลบใหม่ในจานวนครั้งที่จากัด
– การอ่านไว แต่เขียนและลบช้า โดยเฉพาะการลบ
– นิยมใช้ในกล้องดิจิทัล, USB Drive, โทรศัพท์
• Magnetic Disk
– ข้อมูลถูกเก็บในจานหมุน ใช้อานาจแม่เหล็กในการอ่าน/เขียน
– ใช้สาหรับเก็บ DB ทั้งหมด
– สามารถเข้าถึงข้อมูลได้โดยตรง
– มีความจุข้อมูลมาก และมากขึ้นไปอีกในอนาคต
43. Non-Volatile Physical Storage Media
• CD-Rom, DVD, Blu-ray Disk
– ใช้แสงในการอ่านข้อมูล
– ความเร็วในการอ่านและเขียนต่ากว่า Magnetic Disk
• Tape Storage
– สมัยก่อนนิยมใช้กับการ Backup ข้อมูล
– สามารถเข้าถึงข้อมูลแบบลาดับ
– มีความจุข้อมูลมาก
– เทปสามารถดึงออกจาก Drive ได้
– เทปราคาถูก แต่ Drive ราคาแพง
44. Storage Hierarchy
• Primary Storage
– รวดเร็ว แต่ Volatile
– Cache, Main Memory
• Secondary Storage (On-line Storage)
– เร็วในโดยรวม และ Non-Volatile
– Flash Memory, Magnetic Disk
• Tertiary Storage (Off-line Storage)
– เวลาในการเข้าถึงช้า Non-Volatile
– Magnetic Tape, Optical Disk
47. กลไกของ Magnetic HDD
• หัวอ่าน/เขียน
– อยู่ใกล้มาก ๆ กับผิวของจานแม่เหล็ก (เกือบจะสัมผัสกัน)
– สาหรับการอ่าน/เขียนข้อมูลในรูปแม่เหล็ก
– 1 หัวต่อ 1 จานแม่เหล็ก
• Tracks
– ส่วนที่แบ่งจานแม่เหล็กออกเป็นส่วน ๆ
– Tracks แบ่งเป็นวงกลมย่อย ๆ ตามวงของจานแม่เหล็ก
– 1 Tracks ใช้ได้ทั้งด้านบนและล่าง
– HDD 1 จาน มี Track 50K ~ 100K
48. กลไกของ Magnetic HDD
• Sectors
– หน่วยที่เล็กที่สุดที่สามารถอ่าน/เขียนได้
– ส่วนใหญ่มีขนาด 512 bytes
– Tracks ภายในมี Sector ประมาณ 0.5 ~ 1K ภายนอกมีประมาณ 2 เท่า
• วิธีการอ่าน/เขียน Sector
– แขนจะขยับไปยังตาแหน่ง Track ที่ถูกต้อง ขณะที่จานแม่เหล็กหมุนไปเรื่อย ๆ
– ข้อมูลถูกอ่าน/เขียนผ่าน Sector ที่อยู่ใต้หัวอ่าน/เขียน
– สาเหตุที่ทาให้การเข้าถึงข้อมูลช้า
49. กลไกของ Magnetic HDD
• ความคงทนของ HDD
– สมัยก่อนผิวบนจานแม่เหล็กประกอบด้วยเหล็กออกไซด์
– แตก, พัง, สลายได้ หากได้รับการกระเทือน
– HDD ปัจจุบันนี้มีความไวต่อการกระทบกระเทือนน้อยลง
– ส่วนใหญ่เสียเพราะ Bad Sector, Sector พัง
50. Disk Controller
• ตัวกลางเชื่อมต่อระหว่างระบบคอมพิวเตอร์กับ HDD ส่วน Hardware
– รับคาสั่งอ่าน/เขียนจากระบบคอมพิวเตอร์
– ควบคุมให้แขนขยับไปยัง Track ที่ต้องการและอ่าน/เขียนข้อมูล
– คานวณและใส่ Checksum ลงไปในแต่ละ Sector เพื่อความถูกต้องเมื่ออ่าน
ข้อมูลกลับ
– มีการอ่านข้อมูลที่เขียนไปแล้วเพื่อตรวจสอบความถูกต้องอีกครั้ง
• สาเหตุที่ทาให้การอ่าน/เขียนช้า
– Remapping of Bad Sector
• หากมี HDD หลายตัว ทุกตัวจะเชื่อมต่อกับ Disk Controller ทั้งหมด
51. Disk Controller
• หากมี HDD หลายตัว ทุกตัวจะเชื่อมต่อกับ Disk Controller ทั้งหมด
– แต่หน้าที่ของ Controller ส่วนใหญ่ HDD จะจัดการของตนเอง
• ลดภาระให้กับ Controller
• มาตรฐานตัวกลางในการเชื่อมต่อ
– ATA (AT Adaptor)
– SATA (Serial ATA)
– SCSI (Small Computer System Interconnect)
– SAS (Serial Attached SCSI)
• ปัจจุบันนิยมใช้ SATA
52. การสร้างที่เก็บไฟล์ไว้ใช้ร่วมกัน[3]
• SAN (Storage Area Network)
– ระบบเครือข่ายของที่เก็บข้อมูล โดยการนาอุปกรณ์ที่เก็บข้อมูลมาต่อกันเป็น
เครือข่าย
– สามารถดึงข้อมูล และเก็บข้อมูลปริมาณมากได้ในเวลาสั้น ๆ
– มีความยืดหยุ่นสูง สามารถปรับระบบให้ทางานตามการใช้งานได้
• NAS (Network Attached Storage)
– ระบบไฟล์เซิร์ฟเวอร์ที่เข้าถึงทาง TCP/IP
– ดูแลรักษาง่าย สามารถจัดการผ่าน GUI บน Web Browser ได้
– ไม่เหมาะกับข้อมูลที่มีขนาดใหญ่
53. ตัววัดประสิทธิภาพ HDD
• เวลาเข้าถึงข้อมูล (Access Time) เกิดจาก
– เวลาแสวงหา (Seek Time) = เวลาที่ Arm ขยับหาตาแหน่ง Track ที่ถูกต้อง
– เวลาที่จานหมุนหมุน Sector ให้ไปอยู่ที่หัวอ่าน/เขียน
– ใช้เวลารวมประมาณ 0.022 วินาที
• อัตราการย้ายข้อมูล (Data-Transfer Rate)
– ในกรณีที่มี HDD มาก ๆ Controller มีผลกับอัตรานี้
• เวลาใช้งานโดยเฉลี่ย (Mean Time to Failure (MTTF))
– เวลาเฉลี่ยที่ HDD สามารถทางานได้โดยไม่เสีย
– HDD ส่วนใหญ่จะมี MTTF 3 ~ 5 ปี
54. Block
• Sector ที่อยู่ติดกันบน Track
• ใช้ในการอ่าน/เขียนข้อมูลระหว่าง HDD กับ Main Memory
– ขนาดเล็ก ใช้เวลาเพื่อย้ายข้อมูลมาก
– ขนาดใหญ่ เกิดพื้นที่เหลือในกรณีข้อมูลมีความจุน้อยกว่า Block
• ข้อมูลเดียวกัน ไม่จาเป็นต้องอยู่ Blocks ติดกัน
– ถ้าไม่มีข้อมูลอื่นคั่น ข้อมูลเดียวกันจะเขียน Blocks ติดกันเรื่อย ๆ
– ถ้ามีข้อมูลอื่นคั่น ข้อมูลเดียวกันอาจอยู่กระจัดกระจาย
• มีผลต่อประสิทธิภาพ HDD
– แก้ได้โดยการ Defragment ซึ่งไม่ค่อยมีใครชอบทากัน
55. Redundant Arrays of Independent Disks [4]
• การนา HDD หลายตัวมาต่อกัน และมองให้เป็น HDD ตัวเดียว
• RAID ทาให้ประสิทธิภาพการเก็บข้อมูลดีขึ้น
– ความจุมากขึ้น RAID นั้นประกอบด้วย HDD หลายตัว
– ความเร็วมากขึ้น ข้อมูลเดียวกัน แบ่งกันเก็บ ทาให้อ่าน/เขียนได้เร็วขึ้น
– ความน่าเชื่อถือมากขึ้น มีการเก็บข้อมูลเดียวกันไว้หลาย HDD
• RAID สามารถทาสาเนาข้อมูล (Mirroring) ได้
– เกิดการซ้าซ้อนกันของข้อมูล (Redundancy)
– ในกรณีที่ HDD ตัวใดตัวหนึ่งเสียหรือซ่อม ข้อมูลจะไม่สูญหายไป
– สามารถใช้ข้อมูลได้จากทั้ง HDD ต้นแบบกับ HDD สาเนา
56. ระดับ RAID
• RAID 0: Block Striping, non-redundant
– มีการแบ่งข้อมูลกันเก็บอย่างเดียว
– เหมาะกับข้อมูลที่ต้องการความเร็วในการเข้าถึง
– เมื่อ HDD ตัวใดเสียข้อมูลจะหายทั้งหมด
• RAID 1: Mirrored Disk[4]
– มีการทาสาเนา (Mirroring) เพียงอย่างเดียว
– เวลาในการเข้าถึงช้ากว่า RAID 0
– เมื่อ HDD ตัวใดตัวหนึ่งเสีย ข้อมูลจะไม่หายไป
– เน้นด้านความปลอดภัยของข้อมูล
57. ระดับ RAID [4]
• RAID 1+0
– ต้องการ 4 HDDs ขึ้นไป
– นาเอาข้อดีของ RAID 0 และ RAID 1 มารวมกัน
– ทาสาเนา HDD ก่อน แล้วค่อยแบ่งเก็บข้อมูลของต้นฉบับและสาเนา
– เหมาะสาหรับข้อมูลที่ต้องการความเร็วในการเข้าถึงและความจุไม่มาก
• RAID 2
– มี HDD สาหรับเก็บข้อมูลไว้ตรวจสอบและแก้ไขส่วนที่ผิดพลาด (ECC)
– เมื่อ HDD ใดเสียหาย ข้อมูลสามารถกู้คืนได้จากไฟล์ที่เหลือกับค่า ECC
– HDD ทางานช้า และต้องมีที่ HDD ไว้เก็บ ECC ด้วย
– แบ่งข้อมูลเก็บเป็นระดับ Bit
58. ระดับ RAID [4]
• RAID 3: Bit-Interleaved Parity
– ใช้ Parity แทน ECC ในการตรวจสอบข้อผิดพลาดของข้อมูล
– HDD จะเก็บ Parity เพียง 1 HDD เท่านั้น
– แบ่งข้อมูลเก็บเป็น Byte แทน Bit
– Parity ที่มี HDD เดียว ทาให้เวลาเขียนข้อมูลมาก ๆ ทาได้ช้าลง
• RAID 4: Block-Interleaved Parity
– ระบบการทางานคล้าย RAID 3
– มีการแบ่งข้อมูลเป็นระดับ Block แทน Byte
– ยังคงปัญหาเรื่องเวลาการเขียนข้อมูล
59. ระดับ RAID [4]
• RAID 5: Block-Interleaved Distributed Parity
– แก้ปัญหาคอขวดของ Parity โดยให้ Parity เก็บรวมไปกับข้อมูล
– Parity Block จะเก็บเรียงลาดับตาม HDD ไปเรื่อย ๆ จนครบ
– การแบ่งข้อมูลและระดับการแบ่งเป็นหน่วย Block (เหมือนกับ RAID 4)
– มีระบบ Hot Swap สามารถเปลี่ยน HDD ที่เสียได้ในขณะที่ระบบทางานอยู่
– เหมาะกับการเก็บข้อมูลบน Server ต่าง ๆ ทั่วไป
60. ระดับ RAID [4]
• RAID 6: P+Q Redundancy
– คล้ายกับ RAID 5
– มีการสร้าง Parity Block เพิ่มอีก 1 Block
– สามารถ Hot Swap 2 HDDs ได้
• ในกรณีที่ HDD เสียสองตัวพร้อมกัน RAID 6 ยังสามารถทางานต่อได้
– เหมาะกับข้อมูลที่ต้องการความเสถียรภาพ
• RAID 7
– เหมาะสาหรับองค์กรขนาดใหญ่
– พื้นฐานมาจาก RAID 4 แต่ HDD ทางานโดยอิสระ ไม่ต้องรอกัน
– มี Real-Time Operating System คอยควบคุมการทางานของ RAID
61. การเลือกระดับ RAID
• ปัจจัยหลักในการตัดสินใจ
– ราคา
– ประสิทธิภาพการอ่าน/เขียน
– ประสิทธิภาพเมื่อ HDD บางตัวใน Logical Disk เกิดเสีย
– ประสิทธิภาพการกู้ข้อมูลกลับคืน
• RAID 0 สาหรับข้อมูลที่เน้นความเร็ว และไม่ค่อยสาคัญ
• RAID 2, 4 ถูกแทนด้วย RAID 3, 5 และ RAID 3 ถูกแทนด้วย RAID 5
• RAID 5 นิยมใช้เก็บข้อมูลที่ไม่ค่อยเปลี่ยนแปลงและปริมาณมาก
• RAID 1 มีความเร็วในการเขียนมากกว่า RAID 5 แต่ใช้พื้นที่มากกว่า
• ระดับ RAID ที่นิยมใช้ RAID 0, 1, 1+0, 5
62. ประเภทระเบียน
• ระเบียนจากัดขนาด (Fixed-Length Records)
– บอกขนาดที่แน่นอนแต่ละระเบียน และขนาดตารางได้
– อาจเกิดช่องว่างในกรณีที่ข้อมูลมีขนาดน้อยกว่าความจุที่กาหนดไว้
– เข้าถึงแต่ละระเบียนได้ง่าย
• ระเบียนขนาดแปรผันได้ (Variable-Length Records)
– ขนาดของระเบียนขึ้นกับข้อมูลที่เก็บจริง
– มี Null Bitmap ไว้บอกจุดสิ้นสุดของระเบียน
63. การจัดการระเบียน
• Heap ระเบียนสามารถใส่ได้ทุกที่ที่มีพื้นที่ว่าง
• Sequential เก็บระเบียนแบบเรียงลาดับโดยขึ้นกับ Search-Key
• Hash เก็บข้อมูลโดยอาศัย Hash Function กาหนดตาแหน่ง Block
• Multitable Clustering การเก็บระเบียนโดยค่าที่อยู่ใน Schema อื่น
สามารถเก็บไว้ในที่เดียวกันได้
• ในคอร์สนี้ยกตัวอย่างเพียง Sequential กับ Multitable Clustering
68. Data Dictionary
• ใช้เก็บข้อมูลของข้อมูล (metadata)
– ข้อมูลเกี่ยวกับ Schema
• ชื่อ ประเภท ความจุของ Attribute และชื่อ Schema
• ชื่อและนิยามของ Views
• เงื่อนไขบังคับของข้อมูล (Integrity Constrains)
– User Account ที่ใช้เข้าถึงฐานข้อมูล
– ข้อมูลต่าง ๆ ภายใน Schema
– ข้อมูลเกี่ยวกับ Index
– ข้อมูลการเก็บไฟล์ทางกายภาพ
• วิธีการเก็บ Schema และที่อยู่ของไฟล์ที่เก็บ
70. Buffer
• ส่วนของ Main Memory ที่สามารถเก็บ Blocks ของข้อมูลได้
– ลดจานวนครั้งการอ่านจาก HDD โดยอ่านทีเดียวและเก็บไว้ที่นี่
• เกิดจากการอ่าน/เขียนของ HDD ทาได้ช้า
– มีการเคลื่อนไหวของแขนและจานหมุน ซึ่งช้ามากเมื่อเทียบกับ Main Memory
– ยิ่งอ่าน/เขียนหลาย ๆ ครั้ง ก็ยิ่งช้า
• ทาให้การอ่าน/เขียน Blocks เร็วขึ้น
– อ่าน/เขียน Blocks จาก Main Memory ได้โดยตรง
• ยิ่งมีพื้นที่มาก การเขียน/อ่านกับ HDD ก็น้อยลงตาม
71. Buffer Manager
• ระบบย่อยในการจัดการ Buffer
• ทางานเมื่อโปรแกรมต้องการข้อมูลต้องการ Blocks จาก HDD
– หากใน Buffer มี Blocks ที่ต้องการ จะให้ Pointer ของ Blocks นั้นกลับไป
– หากไม่มี Block ที่ต้องการใน Buffer
• อาจเอาบาง Blocks ใน Buffer ออก โดย Blocks ที่เอาออกนั้นหากมีการเปลี่ยนแปลง
จะเขียน Blocks นั้นลง HDD ก่อน
• อ่าน Blocks ที่ต้องการจาก HDD ไว้ใน Buffer จากนั้นให้ Pointer ของ Blocks ที่
อ่านมากลับไปยังโปรแกรมที่ต้องการ Blocks นั้น
• ส่วนใหญ่ Blocks ใน Buffer ที่ไม่ค่อยได้ใช้จะถูกเอาออก (LRU
Strategy) เมื่อต้องการพื้นที่สาหรับ Blocks ใหม่ที่จะอ่าน
73. Query Processing
• Parsing & Translation
– ตรวจสอบความถูกต้องของคาสั่ง SQL
– เปลี่ยนคาสั่ง SQL เป็น Relational Algebra
• Evaluation
– Query-execution Engine เริ่มสร้าง Query-evaluation plan
– ประมวลผลจากคาสั่งตาม Query-evaluation plan ที่วางไว้
– ส่งคาตอบที่ประเมินได้เป็น Result Set
75. Query Cost
• วัดจากเวลาที่ใช้ตั้งแต่สั่ง Query จนได้ Result Set กลับมา
– การเข้าถึงข้อมูลจาก HDD + เวลาประมวลผล CPU + ความเร็วเครือข่าย + ...
• ส่วนใหญ่แล้ว Cost เกิดจากการเข้าถึงข้อมูลใน HDD
– เวลาโดยประมาณที่ใช้ในการเข้าถึง HDD คานวณจากเวลาที่เข้าถึง b Blocks
+ เวลาที่ใช้กับการ Seek S ครั้ง
(b * tT) + (S * tS)
– tT =เวลาที่ใช้ในการเคลื่อนย้าย 1 Block, tS = เวลาที่ใช้ Seek 1 ครั้ง
– สามารถลดการเข้าถึง HDD ได้ด้วย Buffer
76. Selection Operation
• Linear Search Algorithm การเข้าไปอ่านแต่ละ Blocks และดูว่าแต่ละ
ระเบียนนั้นตรงตามเงื่อนไขที่กาหนดหรือไม่
– Cost โดยประมาณคานวณจากจานวน Blocks ที่เก็บ Relation r ทั้งหมด +
การ Seek 1 ครั้ง
br blocks transferred + 1 seek
– หากเงื่อนไขที่กาหนดเป็น Key Attribute สามารถจานวนได้จาก
(br/2) blocks transferred + 1 seek
– Linear Search สามารถนาไปใช้กับการเลือกระเบียนตามเงื่อนไขหรือการ
เรียงลาดับระเบียน
77. การเลือกโดยใช้ดัชนี
• Index Scan การค้นหาข้อมูลโดยใช้ดัชนี (Index)
• Primary Index, equality on key
– เลือกระเบียนที่ตรงกับเงื่อนไขการเลือกเพียงระเบียนเดียว
Cost = (hi + 1) * (tT + tS)
– hi = ความสูงของต้นไม้ B-Tree
• Primary Index, equality on non-key
– เลือกระเบียนที่ตรงเงื่อนไขทั้งหมด โดยระเบียนจะอยู่ Block ที่ต่อเนื่อง
ตามลาดับ
Cost = hi * (tT + tS) + tS + (tT * b)
78. การเลือกโดยใช้ดัชนี
• Secondary Index, equality on nonkey
– เลือกเพียงระเบียนเดียว หาก key ที่ใช้ค้นเป็น candidate key
Cost = (hi + 1) * (tT + tS)
– เลือกหลายระเบียน ถ้า key ที่ใช้ค้นไม่เป็น candidate key
• ระเบียนที่ตรงกับเงื่อนไข n ระเบียน แต่ละระเบียนอาจไม่ได้อยู่ใน block เดียวกัน
• ทุกครั้งที่อ่านข้อมูลใหม่มีการ Seek เกิดขึ้น
Cost = (hi + n) * (tT + tS)
79. การเรียงลาดับ
• การสร้าง index ของ schema และใช้ index ในการอ่าน schema โดย
อ่านแบบเรียงลาดับ สามารถทาให้ใช้เพียง 1 block ในการเข้าถึงแต่ละ
ระเบียนได้
• สาหรับ schema ที่มีขนาดค่อนข้างพอดีกับหน่วยความจา จะนิยมใช้
Quicksort ในการเรียงลาดับ แต่หากไม่พอดีจะใช้ External sort-merge
แทน
80. Join Operation
• การ Join มีหลากหลาย Algorithms
– Nested-Loop-Join
– Block Nested-Loop Join
– Indexed Nested-Loop Join
– Merge-Join
– Hash-Join
• เลือกวิธีใด ขึ้นกับ Cost โดยประมาณ
81. Nested-Loop Join
• Algorithms
foreach tuple tr in r:
foreach tuple ts in s:
if pair (tr, ts) satisfy the join condition:
add tr•ts to the result.
• r = outer relation, s = inner relation
• ไม่ต้องใช้ index และใช้กับการ join ได้ทุกแบบ
• จะเกิดอะไรขึ้น หากใช้กับข้อมูลนี้
– Schema student ที่มี 5000 tuples และ 100 blocks
– Schema takes ทีมี 10000 tuples และ 400 blocks
่
82. Nested-Loop Join
• กรณีแย่ที่สุด: เมื่อ buffer สามารถเก็บแต่ละ schema ได้เพียง 1 block
(nr * bs) + br block transfers + nr + br seeks
– หากเลือก student เป็น Outer relation
• 5000 * 400 + 100 = 2,000,100 block transfers
• 5000 + 100 = 5100 seeks
– หากเลือก takes เป็น Outer relation
• 10000 * 100 + 400 = 1,000,400 block transfers
• 10000 + 400 = 5100 seeks
• การเลือก Outer relation เป็น Schema ที่มีข้อมูลมากจะไวขึ้น
83. Block Nested-Loop Join
• วนรอบเปรียบเทียบ โดยทุก block ใน inner relation จับคู่กับทุก
block ใน outer relation
foreach block Br of r:
foreach block Bs of s:
foreach tuple tr in Br:
foreach tuple ts in Bs:
if (tr, ts) satisfy the join condition:
add tr•ts to the result.
• Algorithm นี้ให้ผลที่ดีกว่า Nested-Loop Join อย่างไร
84. Block Nested-Loop Join
• กรณีที่ดีที่สุดคานวณได้จาก
br + bs block transfers + 2 seeks
• กรณีที่แย่ที่สุดคานวณ Cost โดยประมาณได้จาก
(br * bs) + br block transfers + 2 * br seeks
– แต่ละ Block ใน Inner Relation อ่านเพียงครั้งเดียวสาหรับทุก Blocks ที่อยู่
ใน Outer Relation
85. Transaction Concept
• Transaction คือ หน่วยการทางานที่มีการเข้าถึงและเปลี่ยนแปลงข้อมูล
จากข้อมูลหนึ่งเป็นอีกข้อมูลหนึ่ง
– การฝากเงิน, ถอนเงิน, โอนเงิน
– การลงทะเบียนเรียน, การ Drop รายวิชา
• ในบางครั้งการทางานเพียงคาสั่งเดียวอาจไม่พอ
86. Transaction Concept[5]
1 CREATE PROCEDURE transfer_funds (from_account INT,
to_account INT, amount NUMERIC(10,2))
2 SET AUTOCOMMIT = 0;
3 UPDATE account_balance SET balance = balance –
amount WHERE account_id = from_account;
4 UPDATE account_balance SET balance = balance +
amount WHERE account_id = to_account;
5 INSERT INTO journal (from_acount_id, to_account_id,
transfer_amount) VALUES (from_account, to_account,
amount);
6 COMMIT;
87. Transaction Concept
1 read(A)
2 A := A – 50
3 write(A)
4 read(B)
5 B := B + 50
6 write(B)
• สิ่งที่อาจเกิดขึ้นเมื่อทาคาสั่งนี้
– เกิดความเสียหายทางด้าน Software หรือ Hardware
• ปลั๊กหลุด
– มีการทา Transaction แบบเดียวกัน
88. Transaction Concept
• จะเกิดอะไรเมื่อมีอีก Transaction ถูกทางาน และผังทางานเป็นดังนี้
1 read(A)
2 A := A – 50
3 write(A)
1 read(A)
4 read(B)
5 B := B + 50
2 read(B)
3 print(A + B)
6 write(B)
• A + B ของ Transaction ที่ 2 เหมือนกับ Transaction ที่ 1 ?
89. Transaction Concept
• สมมติว่าเงินคุณ A คงเหลือ 100G และคุณเหลือเงิน 200G
1 read(A) 100
2 A := A – 50 50
3 write(A)
1 read(A) 50
4 read(B) 200
5 B := B + 50 250
2 read(B) 200
3 print(A + B) 250
6 write(B)
• A + B ของ Transaction ที่ 2 เหมือนกับ Transaction ที่ 1 ไหม?
90. คุณสมบัติของ ACID
• เนื่องจาก Transaction อาจประกอบด้วยการทางานย่อย ๆ โดยเฉพาะ
การอ่าน/เขียนข้อมูล เพื่อรักษาความบูรณภาพ (Integrity) ของข้อมูลไว้
ระบบของฐานข้อมูลต้องมีคุณสมบัติ ACID
– ความเป็นอันหนึ่งอันเดียวกัน (Atomicity)
• งานย่อยภายใน Transaction ต้องสาเร็จทั้งหมด ไม่เช่นนั้นจะ Roll back กลับทั้งหมด
– ความเสมอต้นเสมอปลาย (Consistency)
• ข้อมูลหลังจากที่ทา Translation แล้วต้องสอดคล้องกับการเปลี่ยนแปลง
– ความเป็นส่วนตัว (Isolation)
• Transaction ที่ยังทาไม่เสร็จจะมี Transaction อื่นเข้าถึงส่วนต่าง ๆ ไม่ได้
– ความมั่งคง (Durability)
• Transaction ที่ทาเสร็จแล้ว ข้อมูลที่เปลี่ยนไปต้องคงอยู่ถาวร
91. สถานะของ Transaction
• Active: สถานะเมื่อ Transaction กาลังทางาน
• Partially Committed: สถานะหลังจากคาสั่งสุดท้ายใน Transaction
ทางานเสร็จ
• Failed: สถานะเมื่อพบว่า Transaction ไม่สามารถทางานได้
• Aborted: สถานะที่ Transaction ถูก Roll back และฐานข้อมูลกลับมา
เป็นเหมือนก่อน Transaction เริ่มทางาน
– Transaction จะทาใหม่ (Restart) เมื่อไม่มีปัญหาด้าน Logic
– เลิกทา (Kill)
• Committed: สถานะที่ Transaction ทางานได้สาเร็จ
93. การ Execute ร่วมกัน
• Transaction หลาย ๆ ตัวสามารถรันไปพร้อมกันได้ในระบบ
– เพิ่มประสิทธิภาพการทางานของ CPU และการใช้ Disk
– ลดเวลาการทางานโดยรวม
• Transaction จะถูกคุมโดยกลไก Concurrency Control Schemes
– ช่วยควบคุมให้ Transaction ทางานเป็นส่วนตัว ไม่ให้คุณสมบัติ Consistency
และ Isolation เสียไป
94. ลาดับการทางาน
• ลาดับการทางาน (Schedule) เป็นลาดับของงานย่อยที่จะ execute
โดยเรียงตามเวลาที่ถูก execute
– ลาดับการทางานของ Transaction Set ต้องประกอบด้วยงานย่อยทั้งหมดที่อยู่
ใน Transaction Set
– แต่ละงานย่อยใน Transaction ต้องคงลาดับการทางานใน Transaction ของ
ตนเอง
• Transaction จะทาสาเร็จก็ต่อเมื่อได้สถานะ Committed
– โดยปกติแล้ว การทา Transaction สุดท้ายเสร็จก็จะ Commit ทันที
• Transaction ที่ทางานไม่สาเร็จจะถูกยกเลิกและได้สถานะ Aborted
95. ลาดับการทางาน
• สมมติ ใ ห้ ฐ านข้ อ มู ล หนึ่ ง มี 2
Transactions ที่ต้องการ Execute
โดย T1 แทนการโอนเงิน 50G จาก
คุณ A ไปคุณ B และ T2 แทนการ
โอนเงิน 10% กลับให้คุณ A
• ล าดั บ การท างานแบบต่ อ เนื่ อ ง
(serial) โดยให้ T1 ทางานก่อนตาม
ด้วย T2
96. ลาดับการทางาน
• ล าดั บ การท างานแบบต่ อ เนื่ อ ง
โดยให้ T2 ทางานก่อนตามด้วย T1
• มีสิ่งใดแตกต่างไปจากลาดับการ
ทางานที่แล้วหรือไม่
97. ลาดับการทางาน
• ลาดับการทางานแบบไม่ต่อเนื่อง
แ ต่ ก า ร จั ด ล า ดั บ ก า ร ท า ง า น นี้
เหมือนกับตารางลาดับการทางาน 1
• ลาดับการทางานที่ 1, 2 และอัน
นี้ เมื่อทั้ง 2 Transactions ถูก
Committed แล้ว ถ้านา A + B
แล้วค่าที่ได้จะเท่ากันหรือไม่
98. ลาดับการทางาน
• ตารางลาดับการทางานนี้ เมื่อทั้ง
2 Transactions ถูก Committed
แล้ว ถ้านา A + B แล้วค่าที่ได้จะ
เหมือนกันกับตารางลาดับที่ 1, 2, 3
หรือไม่
100. Conflict Serializability
• การ Conflict ของงานย่อย เกิดจากงานย่อยของ 2 Transaction ขึ้นไป
มีการใช้งานการอ่าน/เขียนใน Data Item เดียวกัน และเมื่อสลับงานย่อย
ของ Transaction กันแล้วจะทาให้ผลลัพธ์เปลี่ยนไป
– สมมติให้ Ii และ Ij แทนงานย่อยของ Ti และ Tj และพบว่า Ii มีการทางานใน
ลาดับการทางานก่อน Ij
• ถ้า Ii = read(Q) และ Ij = read(Q) ไม่เกิด Conflict
• ถ้า Ii = read(Q) และ Ij = write(Q) เกิด Conflict
• ถ้า Ii = write(Q) และ Ij = read(Q) เกิด Conflict
• ถ้า Ii = write(Q) และ Ij = write(Q) เกิด Conflict
101. Conflict Serializability
• Conflict Serializable คือ ชื่อเรียกของลาดับการทางานแบบ
Concurrent ที่มี Conflict Equivalent กับ Serial Schedule
• ลาดับการทางานที่ Conflict Serializable สามารถสลับคาสั่งย่อยได้โดย
ไม่ Conflict จนได้เป็น Serial Schedule
104. View Serializability
• การ View Equivalent ของลาดับการทางาน เกิดจาก 2 ลาดับการ
ทางานที่มี Transactions เดียวกัน และมีคุณสมบัติ 3 ข้อดังต่อไปนี้
– หากลาดับการทางาน i ที่ Transaction t มีการอ่านค่า data item D จากค่า
เริ่มต้น ลาดับการทางาน j ที่ t ต้องมีการอ่านค่า D จากค่าเริ่มต้นด้วยเช่นกัน
– หากลาดับการทางาน i ใน Transaction t มีการอ่านค่า data item D จาก
ค่าที่เขียนใน Transaction s ลาดับการทางานที่ j ใน t จะต้องอ่านค่า D จาก s
ด้วย
– หากลาดับการทางานที่ i Transaction t เป็น Transaction ที่มีการสั่งเขียน
data item D ครั้งสุดท้าย ในลาดับการทางานที่ j นั้น t จะต้องเป็น Transaction
ที่เขียน D เป็นครั้งสุดท้ายด้วยเช่นกัน
105. View Serializability
• View Serializable คือ ชื่อเรียกของลาดับการทางานแบบ concurrent
ที่ View Equivalent กับ Serial Schedule
• ลาดับการทางานที่เป็น View Serializable จะสามารถสลับคาสั่งย่อย
โดยเมื่อสลับแล้ว View Equivalent จนได้เป็น Serial Schedule
• หากลาดับการทางานเป็น Conflict Serializable แล้วจะเป็น View
Serializable ทันที
– ถ้าพบว่าเป็น View Serializable แล้วจะเป็น Conflict Serializable หรือไม่
– (P -> Q) ^ (Q -> P) = T ?
106. View Serializability
• ตารางนี้เป็น View Serializable และ Conflict Serializable หรือไม่
• ตารางนี้เป็น View Serializable แต่ไม่เป็น Conflict Serialzable
– การสลับ write(Q) ของ T28 กับ write(Q) ของ T27 ไม่ผิดกฎของ View
Equivalent และสลับแล้วจะได้ Serial Schedule <T27, T28, T29>
– write(Q) ของ T28 กับ write(Q) ของ T27 เกิด Conflict ของคาสั่งย่อย
108. Cascading Rollbacks
• เหตุการณ์ที่มี Transaction หนึ่งเข้าสู่สถานะ Abort และทาให้
Transaction อื่น ที่กาลังทางานอยู่บางส่วน Abort ตามไปด้วย
– Transaction ที่ Aborted จะโดน roll back
• สาเหตุเกิดจากบาง Transaction ยังไม่ commit เมื่อทางานเสร็จ
– การ commit Transaction เมื่อทางานเสร็จ ทาให้ข้อมูลถูกเขียนลง DB ทันที
โดยที่ Transaction อื่นยังทางานไม่เสร็จ
• ในบางครั้ง Transaction ที่สาคัญอาจโดน roll back โดยไม่ได้ตั้งใจ
109. Cascading Rollbacks
• จากลาดับการทางานนี้ T10, T11, T12 จะถูกยกเลิกการทางาน
• ปัญหานี้สามารถแก้ได้ด้วย Cascadeless Schedule
– หากต้องการอ่านข้อมูลที่เกิดจาก Transaction อื่นเขียน ต้องอ่านเมื่อ
Transaction นั้น committed แล้วเท่านั้น
110. การทดสอบ Conflict Serializable [6]
• การทดสอบ Serializability ของลาดับการทางาน สามารถทดสอบด้วย
การวาด Precedence Graph
• Node ของ Graph เป็น Transaction ทั้งหมดในลาดับการทางาน
• Edge ของ Graph เป็นความสัมพันธ์การ Conflict ของ Data Item
– เมื่อ Transaction t read(D) ก่อน Transaction s write(D)
– เมื่อ Transaction t write(D) ก่อน Transaction s read(D)
– เมื่อ Transaction t write(D) ก่อน Transaction s write(D)
• ถ้าลาดับการทางาน S สามารถเขียน Precedence Graph ได้โดยไม่เกิด
Cycle จะได้ว่า S เป็น Conflict Serializable
114. Lock-Base Protocol
• การ Lock เป็นกลไกในการควบคุมการเข้าถึง data items พร้อม ๆ กัน
– ล็อกข้อมูลที่กาลังอ่าน/เขียน ไม่ให้ Transaction อื่นมาร่วมยุ่งด้วย
• Data items สามารถ lock ได้ 2 แบบ
– Exclusive (X) Mode: ล็อก data items สาหรับการอ่าน/เขียน
– Shared (S) Mode: ล็อก data items สาหรับอ่านอย่างเดียว
• การส่งคาขอการล็อกจะส่งไปยัง Concurrency-Control Manager และ
Transaction จะทางานได้ก็ต่อเมื่อคาขอได้รับการอนุญาตเท่านั้น
115. Lock-Base Protocol
• ตารางความเข้ากันได้ของประเภทการ lock
– Transaction จะสามารถล็อก data items ได้ ถ้าประเภทการ lock ที่ร้องขอ
ไปเข้ากันได้กับประเภทของ lock ที่มีอยู่ที่ data items นั้น ๆ
• Shared lock สามารถล็อก data items ได้เท่าไรก็ได้
• Exclusive lock สามารถล็อก data items ได้เพียงครั้งเดียวเท่านั้น
– หากไม่ได้รับอนุญาตในการล็อก Transaction ต้องรอจนกว่า Transaction
อื่นจะปลดล็อกจนสามารถล็อก data item ได้
116. ข้อผิดพลาดของ Lock-Base Protocol
• การ lock ที่สั้นเกินไป อาจทาให้ Serializability หายไปได้
• การ lock ที่ยาวเกินไป ก็ทาให้เกิดปัญหาเช่นเดียวกัน
• พิจารณาลาดับการทางานนี้
• Schedule นี้มีสิ่งที่ผิดปกติหรือไม่?
117. ข้อผิดพลาดของ Lock-Base Protocol
• จากตารางที่แล้วพบว่า T3 และ T4 ไม่สามารถทางานต่อไปได้
– T4 รอการปลด X-lock ของ T3 และ T3 รอการปลด S-lock ของ T4
• T3 และ T4 เกิดสภาวะ Deadlock
– Transaction ที่ค้างอยู่ต้อง roll back ทั้งหมด
• ในบางครั้ง Concurrency Control ที่ออกแบบมาไม่ดี อาจเกิดสภาวะ
Starvation ด้วยเช่นกัน
119. Deadlock Handling
• สภาวะ Deadlock เกิดจาก transaction หนึ่งใน transaction set มี
การรอ transaction หนึ่งที่อยู่ในเซตเดียวกัน
• ปัญหา Deadlock สามารถแก้ได้ 2 รูปแบบ
– Wait-Die Scheme: transaction ที่ทางานทีหลังแล้วเกิด deadlock จะถูก
rollback
– Wound-Wait Scheme: transaction ที่ทางานก่อนแล้วเกิด deadlock จะ
ถูก rollback
• rollback น้อยกว่าแบบ Wait-Die
– Timeout-Based Schemes
• กาหนดเวลาการร้องขอ หากใช้เวลาเกินกาหนดจะถูก rollback
122. Two-Phase Locking Protocol
• Protocol ชนิด Two-Phase Locking จะมีการ lock เป็น 2 ช่วง
– Growing Phase ช่วงที่สามารถ lock ได้เท่านั้น
– Shrinking Phase ช่วงที่สามารถ unlock ได้เท่านั้น
• การใช้ Protocol นี้ทาให้ลาดับการทางาน serializable แต่ยังเกิด
Deadlock และ Cascade rollback ได้อยู่
• Cascade rollback แก้ได้ด้วย Strict Two-Phase Locking Protocol
– Exclusive Lock จะ lock จนกว่า transaction จะ committed
123. Locking Conversions
• Locking Conversions เป็นส่วนเพิ่มเติมของ Two-Phase Locking
Protocol
• มี 2 ช่วงเช่นเดียวกับ Two-Phase Locking Protocol
– First Phase: สามารถล็อก S-lock, X-lock, เปลี่ยนจาก S-lock เป็น X-lock
– Second Phase สามารถปลดล็อก S-lock, X-lock หรือเปลี่ยน X-lock เป็น
S-lock
• การใช้ Protocol นี้ทาให้ลาดับการทางาน serializable แต่
โปรแกรมเมอร์ต้องเขียนวิธีการ lock เพิ่มเติมให้กับโปรแกรมด้วย
124. Automatic Acquisition of Locks
• Read data item algorithm
if Ti has a lock on D:
read(D)
else:
if necessary wait until no other transaction
has a lock-X on D:
grant Ti a lock-S on D
read(D)
125. Automatic Acquisition of Locks
• Write data item algorithm
if Ti has a lock-X on D:
write(D)
else:
if necessary wait until no other transaction
has any lock on D:
if Ti has a lock-S on D:
upgrade lock on D to lock-X
else:
grant Ti a lock-X on D
write(D)
126. Implementation of Locking
• การล็อกจะทาผ่าน Lock Manager
– Process ถูกแยกจาก DB อย่างชัดเจน
• Lock Manager มีหน้าที่คอยตอบกลับคาร้องขอการล็อกโดยการส่ง
lock grant messages
– อาจส่ง rollback messages ในกรณีที่เกิด deadlock
• transactions ที่ส่งคาร้องแล้วจะรอจนกว่าจะได้รับการตอบกลับ
• Lock Manager จะคอยปรับปรุง Lock Table เพื่อจาว่า data item ใด
ได้อนุญาตให้ล็อก หรือพิจารณาคาร้องขออยู่
127. Tree-Protocol
• Graph-Based Protocol เป็นอีกหนึ่งวิธีนอกจาก Two-Phase Locking
Protocol
– อาจเรียกอีกชื่อว่า Tree-Protocol
• Database Graph เป็นกราฟที่ไม่มีวัฏจักร แสดงความสัมพันธ์ระหว่าง
data item
– data item d -> data item e หมายถึงต้องเข้าถึง d ก่อนจึงจะเข้าถึง e ได้
• สามารถล็อกได้เพียง Exclusive lock (X-lock) เท่านั้น
128. Tree-Protocol
• ใน transaction ใด ๆ การล็อกครั้ง
แรกสามารถล็อกได้ทุก node อย่าง
อิสระ
• การล็ อ กครั้ ง ที่ ส องนั้ น จ าเป็ น ต้ อ ง
ล็อก parent node ของ node ที่
ต้องการล็อกก่อนจึงสามารถล็อกได้
• การปลดล็ อ กท าได้ ทุ ก เวลา แต่
node ที่ล็อกและปลดล็อกไปแล้ว จะ
ไม่สามารถล็อกได้อีกใน transaction
นั้น ๆ
129. Tree-Protocol
• Graph-Based Protocol ทาให้ลาดับการทางานเป็น conflict
serializable และไม่เกิด deadlock
• Graph-Based Protocol ปลดล็อกข้อมูลได้ก่อน Two-Phase Locking
Protocol
– ลดเวลาการทางานลง เพิ่มประสิทธิภาพมากขึ้น
• Graph-Based Protocol อาจเกิด Cascade Rollback และอาจกู้คืน
ข้อมูลไม่ได้
• การล็อกข้อมูลเกินจาเป็น
– การล็อกต้องใช้เวลามากขึ้น
130. Multiple Granularity
• Granular = เป็นเม็ดเล็ก ๆ
• สามารถเขียน data items เป็น node ต่าง ๆ โดยข้อมูลที่ใหญ่กว่าจะ
เป็น parent node ให้กับข้อมูลที่ย่อยลงไป
– ห้ามสับสนกับ Tree-Locking Protocol เด็ดขาด
• เมื่อ Transaction ล็อก node ใด ๆ child node ทั้งหมดของ node
นั้นจะถูกล็อกด้วย
• การล็อกมี 2 ประเภท
– Fine Granularity การล็อก node ที่มี level สูง
– Coast Granularity การล็อก node ที่มี level ต่า
132. Multiple Granularity
• ใน Multiple Granularity มีวิธีการล็อกเพิ่มอีก 3 แบบ
– Intention-Shared (IS) การล็อกเพื่อบ่งบอกว่า child node ลงไป มีการ S-
Lock
– Intention-Exclusive (IX) การล็อกเพื่อบอกว่า child node ลงไป มีการ S-
Lock หรือ X-Lock
– Shared and Intention-Exclusive (SIX) node ที่ล็อกด้วย SIX จะเป็น S-
Lock ส่วน child node ลงไปจะเป็น IX
• Intention Lock จะทาให้ node ที่เป็น coarse สามารถ S-Lock หรือ
X-Lock โดยไม่ต้องตรวจสอบ child nodes
134. Timestamp-Based Protocols
• เมื่อระบบเริ่มทางาน แต่ละ transaction จะได้รับ timestamp
• transaction ที่ใหม่กว่า จะมีค่าใน timestamp สูงกว่า
– ถ้า transaction i มีค่าใน timestamp คือ TS(i) และ transaction j มีค่าใน
timestamp คือ TS(j) ถ้า j ใหม่กว่า i จะได้ว่า TS(j) > TS(i)
• Timestamp-Based Protocol สามารถทาให้ลาดับการทางานเป็น
Conflict Serializable โดยการเปลี่ยนค่า timestamp ของ data item
– W-Timestamp(D) มีค่าเป็น timestamp ที่มากที่สุดของ transaction ที่
สามารถ write(D) ได้สาเร็จ
– R-Timestamp(D) มีค่าเป็น timestamp ที่มากที่สุดของ transaction ที่
สามารถ read(D) ได้สาเร็จ
135. Timestamp-Based Protocols
• สมมติให้ transaction i กาลังทาคาสั่งย่อย read(Q)
• หาก TS(i) น้อยกว่า W-Timestamp(Q) จะถือว่า i กาลังอ่านข้อมูลที่
ถูกเขียนหลัง i
– transaction i จะถูก reject และ roll back
• หาก TS(i) มากกว่าหรือเท่ากับ W-Timestamp(Q) จะถือว่า i กาลังอ่าน
ข้อมูลที่เขียนก่อน i
– I จะสามารถอ่าน data item Q ได้ และ R-Timestamp จะเปลี่ยนเป็น
ค่าสูงสุดระหว่าง TS(i) หรือ R-Timestamp(Q)
136. Timestamp-Based Protocols
• สมมติให้ transaction i กาลังทาคาสั่งย่อย write(Q)
• หาก TS(i) น้อยกว่า R-Timestamp(Q) จะถือว่า i กาลังจะเขียน
ข้อมูลที่มี transaction ใด ๆ ที่ทาทีหลังแต่อ่านข้อมูลไปก่อนแล้ว
– transaction i จะถูก reject และ roll back
• หาก TS(i) น้อยกว่า W-Timestamp(Q) จะถือว่า i กาลังเขียนข้อมูลที่
มี transaction ที่ทาทีหลังแต่เขียนข้อมูลไปก่อนหน้าแล้ว
– transaction i จะถูก reject และ roll back
• ถ้า TS(i) ไม่ตรงกับเงื่อนไขทั้งสอง i จะสามารถเขียนข้อมูลลงบน data
item Q ได้ และ W-Timestamp(Q) จะเปลี่ยนเป็น TS(i)
138. Timestamp-Based Protocols
• นอกจาก Timestamp-Based Protocols จะไม่มีปัญหาเรื่อง Conflict
Serializable แล้ว ยังไม่มีปัญหา Deadlock อีกด้วย
• Timestamp-Based Protocols ยังไม่สามารถกู้ข้อมูลได้ , เกิด
Cascade rollback และ transaction อาจถูก rollback บ่อย
– แก้โดยให้คาสั่งเขียนนั้นทาเมื่อคานวณค่าต่าง ๆ เสร็จแล้ว
– ขณะที่มีการเขียน บังคับไม่ให้ transaction ทางาน
– transaction ที่ aborted จะกลับมาทาใหม่พร้อม timestamp ใหม่
– ข้อมูลจะอ่านได้ ต้อง committed จาก transaction ก่อน
139. Recovery System
• ความผิดพลาดของ transaction เกิดขึ้นได้ 2 แบบ
– Logical Error เกิดจากคาสั่งย่อยใน transaction หรือความผิดพลาดภายใน
– System Error เกิดจากระบบ เช่น Deadlock
• ระบบเสียหาย (System Crash) อันเนื่องจาก Hardware, Software,
ไฟฟ้า
• ความผิดพลาดของจานแม่เหล็ก (Disk Failure)
– หัวอ่าน/เขียนไม่สามารถใช้งานได้
– บางส่วนของข้อมูลเสียหายจนไม่สามารถอ่านบางข้อมูลขึ้นมาได้
140. Storage Structure
• Volatile Storage
– เมื่อระบบเสียหาย ข้อมูลจะหายทันที
– Main Memory, Cache Memory
• Non-Volatile Storage
– ข้อมูลไม่หายไปเมื่อระบบเสียหาย แต่บางครั้งข้อมูลอาจหายบางส่วนหรือเสีย
– Tape, HDD, Disk, Flash Memory
• Stable Storage
– ไม่ว่าอะไรจะเกิด ข้อมูลก็ไม่หายไป
– สามารถทาได้จากอุปกรณ์ที่เป็น Non-Volatile
142. Data Access
• Physical Blocks: Blocks ที่อยู่บนจานแม่เหล็ก
• Buffer Blocks: Blocks ที่เก็บชั่วคราวอยู่บน main memory
• การย้ายข้อมูลระหว่าง main memory กับ disk จะใช้ 2 คาสั่งด้วยกัน
– input(B) ย้าย Blocks จากจานแม่เหล็กเข้าสู่ Main Memory
– output(B) ย้าย Blocks จาก Main Memory เข้าสู่จานแม่เหล็ก
• แต่ละ transaction ที่ทางานอยู่ภายใน main memory จะมี local
variables เป็นของตนเอง
– การทางานของ transaction กับตัวแปรจะมีการเปลี่ยนแปลงค่าที่ local
variable ของ transaction ตนเอง
143. Data Access
• การเปลี่ยนแปลงข้อมูลระหว่าง Buffer Blocks กับ Transaction Local
Variables จะใช้ 2 คาสั่งเช่นเดียวกัน
– read(B) อ่าน data item B จาก Buffer Blocks มาไว้ที่ local variable
– write(B) เขียน data item B ใน local variable ไว้ที่ Buffer Blocks
• การ write กับ output บางครั้งอาจไม่เกิดพร้อมกัน
• การทางานครั้งแรก data item จะถูกอ่านมาเก็บที่ local variables ถ้า
data item เพิ่งอ่านเป็นครั้งแรก
• Local variables จะถูกเขียนลง Buffer Blocks หลังจาก transaction
committed
144. Data Access
buffer
Buffer Block A input(A)
X A
Buffer Block B Y B
output(B)
read(X)
write(Y)
x2
x1
y1
work area work area
of T1 of T2
memory disk
