แผนภูมิ ER: ตอน 2

 

 
Home Page  |   รายการบทความ   |   ลิงค์ที่เกี่ยวข้อง   |   laploy.com  |  เกี่ยวกับผู้เขียน

 

แผนภูมิ ER: ตอน 2

 

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

กุญแจสามารถทำหน้าที่เป็นได้ทั้งกุญแจและเป็นดรรชนี เมื่อทำหน้าที่เป็นดรรชนีมันคัดลอกคอลัมน์ในตารางไปทำเป็นโครงสร้างที่ใช้ค้นข้อมูลได้อย่างมีประสิทธิภาพ (เช่นเป็นโครงสร้างแบบต้นไม้ไบนารี) เมื่อทำหน้าที่เป็นกุญแจมันใส่เครื่องหมายพิเศษไว้ในคอลัมน์เพื่อระบุว่าคอลัมน์นั้นทำหน้าที่เชื่อมโยงกับตารางอื่นๆ กุญแจมีสามแบบคือกุญแจหลัก (Primary Key ย่อ PK) กุญแจเอกลักษณ์ (Unique Key ย่อ UK) และกุญแจนอก (Foreign Key ย่อ FK)

 

5.2.1. นิยามกุญแจหลัก
PK ทำหน้าที่แยกแยะความแตกต่างระหว่างข้อมูลแถวต่างๆ ในตาราง การแยกแยะนี้เป็นสิ่งจำเป็น เพราะหากไม่มีเราจะไม่สามารถค้นหาข้อมูลเฉพาะแถวที่ต้องการได้ ภาพ 5-8 แสดง PK ของตาราง Author และตาราง Publication

ภาพ 5-8 : กุญแจหลักทำหน้าที่แยกแยะความแตกต่างระหว่างข้อมูลแถวต่างๆ ในตาราง

 

5.2.2. นิยามกุญแจเอกลักษณ์
UK เหมือน PK คือทำหน้าที่แยกแยะความแตกต่างระหว่างข้อมูลแถวต่างๆ ในตาราง โดยค่าของ UK จะไม่มีการซ้ำกัน ชนิดข้อมูลของ UK มักเป็นแบบเลขจำนวนเต็ม (สาเหตุที่ไม่ใช้ชื่อนักเขียนหรือชื่อหนังสือเป็นค่าของ UK ผู้เขียนจะอธิบายในบทต่อไป) เนื่องจากเราใช้ตัวเลขแทนชื่อเราจึงเรียกกุญแจเอกลักษณ์ได้อีกอย่างหนึ่งว่ากุญแจแทน (Surrogate Key ย่อ SK)

ยกตัวอย่างเช่นตาราง Author มีคอลัมน์ AUTHOR_ID เป็น UK เพราะมันมีค่าเป็นตัวเลขจำนวนเต็มซึ่งแทนชื่อของผู้เขียน (แทนค่าของคอลัมน์ NAME) แม้โอกาสน้อยมากที่จะมีผู้เขียนชื่อซ้ำกันแต่ SK ก็ยังมีประโยชน์ในการเพิ่มประสิทธิภาพ UK ต่างจาก PK ที่เราใช้เพื่อกำหนดความสัมพันธ์ระหว่างตาราง แต่เราจะไม่ใช้ UK เพื่อการนี้

ต่อไปนี้จะยกตัวอย่างตารางที่มี PK และ UK คิวรีในภาพ 5-9 ทำหน้าที่สร้างตาราง Author

ภาพ 5-9 : คิวรีทำหน้าที่สร้างตาราง Author

 

โปรดสังเกตว่าผู้เขียนกำหนดให้คอลัมน์ author_id เป็น PK และกำหนดให้คอลัมน์ name เป็น UK (คือไม่อนุญาตให้มีข้อมูลซ้ำกัน) เพื่อป้องกันไม่ให้ผู้ใช้ป้อนข้อมูลนักเขียนคนเดียวกันซ้ำมากกว่าหนึ่งแถว หรือป้องกันไม่ให้นักเขียนสองคนใช้นามปากกาซ้ำกัน

 

5.2.3. นิยามกุญแจนอก
FK คือสำเนาของ PK ที่ถูกคัดลอกจาก PT ไปใส่ CT เพื่อให้ทั้งสองตารางสามารถเชื่อมโยงกันได้ FK ทำให้เราแยกแยะได้ว่าข้อมูลแถวใดใน CT สัมพันธ์กันข้อมูลแถวใดใน PT

ในภาพ 5-10 จะเห็นตาราง Publication มี FK ชื่อ author_id (FK) เชื่อมโยงกับตาราง Author เพราะนักเขียนหนึ่งคนอาจเขียนหนังสือไว้หลายเล่ม ยกตัวอย่างเช่นผู้เขียนชื่อ Larry Niven (นักเขียนนิยายวิทยาศาสตร์ที่ผู้เขียนชื่นชอบ) มีรหัสประจำตัว 4 และมีหนังสือสี่เล่ม ดังนั้นในตาราง Author จะมี author_ID ที่เป็น 4 อยู่หนึ่งแถวและในตาราง Publication จะมี author_ID เป็น 4 อยู่สี่แถว

ดูภาพ 5-10 อีกครั้ง โปรดสังเกตว่าตาราง CoAuthor มีการเชื่อมโยงไปยังสองตาราง คือตาราง Author และตาราง Publication ที่เป็นเช่นนั้นเพราะผู้เขียนร่วมอาจเขียนหนังสือร่วมกับนักเขียนมากกว่าหนึ่งคน และในขณะเดียวกันก็อาจมีหนังสือ (ที่ตนเองร่วมเขียน) ได้มากกว่าหนึ่งเล่มด้วย ดังนั้นตาราง CoAuthor จึงมี FK ถึงสองอัน อันแรกชื่อ author_id (FK) ใช้เชื่อมโยงกับตาราง Author และอันที่สองคือ publicaction_ID เพื่อใช้เชื่อมโยงกับตาราง Publication

ภาพ 5-10 : FK ทำให้เราแยกแยะได้ว่าข้อมูลแถวใดใน CT สัมพันธ์กันข้อมูลแถวใดใน PT

 

ภาพ 5-11 เป็นคิวรีเพื่อสร้างตาราง Publication ซึ่งแสดงให้เห็นวิธีสร้างตารางที่มีกุญแจครบทั้งสามแบบ คือมีทั้ง PK, FK และ UK  

 

ภาพ 5-11 : คิวรีเพื่อสร้างตาราง Publication

โปรดสังเกตว่าคิวรีในภาพ 5-11 ผู้เขียนกำหนดให้คอลัมน์ publication_id เป็น PK ส่วน subject_id และ author_id เป็น FK เพื่อใช้เชื่อมโยงกับตาราง Subject และ Author ตามลำดับ ส่วนคอลัมน์ title ถูกกำหนดให้เป็น UK เพื่อป้องกันไม่ให้ผู้ใช้ป้อนข้อมูลชื่อหนังสือซ้ำกัน

 

5.3. สาธิตการออกแบบฐานข้อมูลอย่างง่าย
ในหัวข้อนี้ผู้เขียนจะแสดงวิธีออกแบบตารางสองตารางที่มีการเชื่อมโยงกันอย่างง่ายๆ สมมุติว่าเรามีข้อมูลอย่างที่เห็นในภาพ 5-12 ข้อมูลแต่ละบรรทัดคือข้อมูลของเพลงหนึ่งเพลง คอลัมน์แรก Band name คือชื่อวงดนตรี คอลัมน์ที่สอง Track คือชื่อเพลง คอลัมน์สุดท้าย Description คือคำวิจารณ์ของเพลงนั้น

ภาพ 5-12: ข้อมูลเพื่อสาธิตการออกแบบฐานข้อมูลอย่างง่าย

 

สมมุติว่าผู้เขียนถูกสั่งให้ทำสิ่งต่างๆ ดังนี้
1.    นำข้อมูลนี้มาออกแบบสร้างเป็น PT และ CT ที่เชื่อมโยงกันแบบหนึ่งต่อหลาย
2.    กำหนด PK ให้แก่ตารางทั้งสอง
3.    กำหนด FK ใน CT

 

5.3.1. ตัวอย่างการออกแบบ
ข้อมูลดิบมีสามคอลัมน์ เราต้องสร้างตารางสองตารางจากสามคอลัมน์นี้ ตารางที่ 1 มีหนึ่งคอลัมน์ ตารางที่ 2 มีสองคอลัมน์ การสร้างความสัมพันธ์แบบหนึ่งต่อหลายทำได้โดยดูข้อมูลที่ซ้ำกัน ในภาพ 5-12 อาจดูยากเพราะข้อมูลไม่ได้เรียงแต่กระจายอยู่อย่างไม่มีแบบแผน

การออกแบบตารางตามโจทย์สามข้อนี้มีสิ่งที่ควรพิจารณาดังนี้
1.    วงดนตรีหนึ่งวงปรกติจะมีเพลงมากกว่าหนึ่งเพลง เนื่องจากเราต้องการเชื่อมโยงความสัมพันธ์แบบหนึ่งต่อหลายโดย  ดังนั้น "หนึ่ง" คือ "หนึ่งวงดนตรี" และ "หลาย" คือ "หลายเพลง"
2.    ชื่อวงในคอลัมน์แรกมีการซ้ำกัน แต่คอลัมน์อื่นๆ ไม่มีข้อมูลซ้ำกันเลย ข้อเท็จจริงนี้สนับสนุนแนวคิดในข้อที่หนึ่ง
3.    เนื่องจากคอลัมน์แรกมีข้อมูลซ้ำกัน จึงเหมาะนำมาสร้างเป็น PT คอลัมน์ที่เหลืออีกสองคอลัมน์ไม่มีข้อมูลซ้ำจึงเหมาะนำมาใช้สร้างเป็น CT
4.    ข้อมูลชื่อเพลงจะต้องไม่มีการซ้ำกัน

ภาพข้างล่างแสดงทางเลือกสามแบบในการออกแบบ ทางเลือกที่ 3 ดีที่สุดเพราะ SK ถูกนำมาใช้เป็น PK และ FK  นั้นคือเรากำหนด band_id และ track_id เป็นเลขจำนวนเต็มเพื่อใช้เป็นตัวเชื่อมโยงแทนที่จะใช้ชื่อวงหรือชื่อเพลง ทั้งทางเลือกที่ 3 และที่ 2ใช้การกำหนดความสัมพันธ์แบบจำแนกไม่ได้ คือ CT ไม่ขึ้นกับ PT คือ PK ของ CT ไม่ใช่กุญแจเดียวกันกับ PK ในตารางแม่

ภาพ 5-13 : แผนภูมิ ER แสดงการออกแบบความสัมพันธ์ระหว่างตาราง Band และ Track

 

ส่วนทางเลือกที่ 2 ไม่ค่อยดี (แต่ก็ยังดีกว่าทางเลือกที่ 1) เพราะ PK ในตาราง Band และ FK ในตาราง Track ไม่ได้ใช้ SK (คือไม่ได้ใช้เลขรหัสแทนชื่อวง) จึงมีประสิทธิภาพต่ำกว่าทางเลือกที่ 3 ส่วนทางเลือกที่ 1 มีประสิทธิภาพต่ำที่สุดเพราะใช้ชื่อวง (band_name) เป็นตัวเชื่อมโยง คือใช้ชื่อวงเป็นทั้ง PK ในตาราง Band และ PK ในตาราง Track ด้วย การทำเช่นนี้ทำให้ชื่อวงมีฐานะเป็นกุญแจร่วม (Composite Key หรือ Compound Key ย่อ CK) คือมีข้อมูล (ชื่อวง) ซ้ำกันอยู่ในทั้งสองตารางซึ่งไม่ดี เพราะมีข้อมูลซ้ำกันจำนวนมากซึ่งเป็นสิ่งที่เราต้องการหลีกเลี่ยงตั้งแต่แรก

 

5.3.2. นิยามบูรณภาพสัมพันธ์
บูรณภาพสัมพันธ์ (Referential Integrity ย่อ RI)คือการควบคุมความคงเส้นคงว่าของความสัมพันธ์ระหว่างค่าของ PK และ FK  ซึ่งเป็นค่าที่เราใช้เชื่อมโยง PT และ CT เข้าด้วยกัน การควบคุมทำได้โดยใช้กลไกที่เรียกว่าข้อบังคับ (constraint) โปรแกรม RDBMS ส่วนใหญ่จะมีกลไกนี้ฝังมาในตัวอยู่แล้ว ยกตัวอย่างเช่นใน PT  คอลัมน์ที่เป็น PK จะมีค่าซ้ำกันไม่ได้ ตัวอย่างในหัวข้อที่ผ่านมา PT คือ Band มี PK เป็นชื่อวงดนตรี ค่านี้จะซ้ำกันไม่ได้ เพราะค่านี้ถูกใช้เป็น FK ใน CT  ดังนั้นใน PT จึงมีข้อมูลนี้ได้เพียงแถวเดียวเท่านั้น

เพื่อคงไว้ซึ่ง RI การออกแบบฐานข้อมูลจำเป็นต้องครอบคลุมประเด็นต่างๆ ต่อไปนี้
•    ตารางที่เก็บ PK จะถูกถือว่าเป็น PT และตารางที่เก็บ FK จะถูกถือว่าเป็น CT
•    เมื่อแทรกข้อมูลแถวใหม่เข้าสูง CT ค่าของ FK ของข้อมูลนั้นต้องเป็นค่ามีปรากฏอยู่ใน PT หรือจะเป็นค่า  NULL ก็ได้
•    FK จะมีค่าเป็น  NULL ก็ได้ แต่ PK จะมีค่าเป็น NULL ไม่ได้
•    การเปลี่ยนแปลงค่าใน PT เป็นสิ่งต้องห้าม หากการเปลี่ยนแปลงนั้นกระทบค่าของ PK นอกเสียจากว่าการเปลี่ยนแปลงนี้จะปรับแก้ค่าของ FK ใน CT ที่เชื่อมโยงอยู่ทั้งหมดด้วย
•    การเปลี่ยนแปลงค่าใน CT เป็นสิ่งต้องห้าม หากการเปลี่ยนแปลงนั้นกระทบค่าของ FK นอกเสียจากว่าการเปลี่ยนแปลงนี้จะทำให้ค่าของ FK เป็น NULL หรือมีการตรวจสอบค่า PK ใน PT ด้วย
•    การลบแถวใน PT เป็นสิ่งต้องห้าม นอกเสียจากว่าการลบนั้นจะดำเนินการกับ CT ทุกตาราง คือลบแถวข้อมูลใน CT ทุกแถวที่มี FK ตรงกับแถวข้อมูล PT ที่ถูกลบ

 

5.4. สรุปท้ายบท
แผนภูมิ ERD เป็นเครื่องมือช่วยออกแบบฐานข้อมูลที่ใช้งานได้ง่าย ปัจจุบันมีซอฟต์แวร์ที่ช่วยให้ท่านสร้างแผนภูมิ ERD บนจอภาพแทนการร่างในกระดาษและสามารถผลิตโค้ดภาษา SQL ให้โดยอัตโนมัติ แผนภูมิ ERD แสดงความสัมพันธ์ระหว่างเอนทิตีหรือตาราง ความสัมพันธ์มีหลายแบบ อาทิ หนึ่งต่อหนึ่ง หนึ่งต่อหลาย ความสัมพันธ์ระหว่างตารางมีกุญแจหรือคีย์เป็นสิ่งเชื่อมโยง กุญแจมีหลายแบบ อาทิ กุญแจหลัก กุญแจนอก ในบทต่อๆ ไปท่านจะได้เรียนเรื่องเหล่านี้ในรายละเอียดลึกลงไปอีก

ในบทหน้าท่านจะได้เรียนเรื่องนอร์มัลไลเซชัน ซึ่งเป็นหัวข้อสำคัญอีกหัวข้อหนึ่งในเรื่องการออกแบบฐานข้อมูล

 

5.5. คำถามท้ายบท
1.    ERD มีประโยชน์อย่างไร
2.    ตีนกามีหน้าที่อะไร
3.    ความสัมพันธ์แบบหนึ่งต่อหนึ่งพบได้ในกรณีใด
4.    ความสัมพันธ์แบบหลายต่อหลายคืออะไร
5.    สัญลักษณ์รูปวงกลมและขีดหนึ่งขีดใช้แทนอะไร
6.    ความสัมพันธ์แบบจำแนกได้คืออะไร
7.    ความสัมพันธ์แบบจำแนกไม่ได้เป็นอย่างไร
8.    ตารางผูกพันคืออะไร
9.    กุญแจหลักมีหน้าที่อะไร
10.    กุญแจเอกลักษณ์คืออะไร

 

5.6. แบบฝึกหัดท้ายบท
พิจารณาข้อมูลในภาพ 5-13 แล้วทำสิ่งต่างๆ ดังนี้
1.    นำข้อมูลนี้มาออกแบบสร้างเป็น PT และ CT ที่เชื่อมโยงกันแบบหนึ่งต่อหลาย
2.    กำหนด PK ให้แก่ตารางทั้งสอง
3.    กำหนด FK ใน CT

 

ภาพ 5-13 : ตัวอย่างข้อมูลสำหรับทำแบบฝึกหัดท้ายบท

 

แผนภูมิ ER: ตอน 1

 

 
Home Page  |   รายการบทความ   |   ลิงค์ที่เกี่ยวข้อง   |   laploy.com  |  เกี่ยวกับผู้เขียน

 

แผนภูมิ ER: ตอน 1

 

บทที่ผ่านมาท่านได้เรียนเรื่องการออกแบบฐานข้อมูลเบื้องต้นไปแล้วใน ในบทนี้ท่านจะได้เรียนวิธีใช้แผนภูมิ ER เพื่อช่วยออกแบบฐานข้อมูล และจะได้เรียนนิยามความหมายของคำสำคัญต่างๆ ที่เกี่ยวข้องกับการออกแบบฐานข้อมูล เช่น ความสัมพันธ์แบบต่างๆ ตารางแม่ ตารางลูก กุญแจชนิดต่างๆ และตอนท้ายบทผู้เขียนจะสาธิตการออกแบบฐานข้อมูลอย่างง่ายให้ดูหนึ่งแบบ

หัวข้อต่างๆ ที่ท่านจะได้เรียนในบทนี้คือ
•    นิยามแผนภูมิอีอาร์
     o    ตีนกา
     o    ความสัมพันธ์แบบหนึ่งต่อหนึ่ง
     o    ความสัมพันธ์แบบหนึ่งต่อหลาย
     o    ความสัมพันธ์แบบหลายต่อหลาย
     o    ความสัมพันธ์แบบศูนย์ หนึ่ง และหลายๆ
     o    ตารางแม่ ตารางลูก
     o    ความสัมพันธ์ที่จำแนกได้และไม่ได้
     o    นิยามกุญแจ
     o    นิยามกุญแจหลัก
     o    นิยามกุญแจเอกลักษณ์
     o    นิยามกุญแจนอก
•    สาธิตการออกแบบฐานข้อมูลอย่างง่าย
     o    ตัวอย่างการออกแบบ
     o    นิยามบูรณภาพสัมพันธ์

 

5.1. นิยามแผนภูมิอีอาร์
หากเครื่องมือที่ดีที่สุดของนักเขียนโปรแกรมคือโฟลชาร์ท เครื่องมือที่ดีที่สุดของนักออกแบบฐานข้อมูลก็คือแผนภูมิอีอาร์ (Entity / Relation Diagram ย่อ ERD) เพราะ ERD ช่วยให้เราแสดงภาพความสัมพันธ์ภายในเอนทิตี และระหว่างเอนทิตี ได้เป็นอย่างดี คำว่าเอนทิตี (entity) ในการออกแบบฐานข้อมูลก็คือตารางในฐานข้อมูลนั่นเอง ท่านได้เรียนเรื่อง ERD ไปแล้วเล็กน้อยในบทก่อนหน้านี้ ในบทนี้ท่านจะได้เรียนวิธีอ่านและเขียน ERD เพิ่มเติม

 

ภาพ 5-1 : แผนภูมิอีอาร์หรือ ERD เป็นแผนภูมิง่ายๆ ไม่มีอะไรซับซ้อน เป็นเครื่องมือสำหรับนักออกแบบฐานข้อมูลเพื่อใช้แสดงภาพความสัมพันธ์ในเอนทิตี และระหว่างเอนทิตี

 

5.1.1. ตีนกา
คำว่าตีนกาในหัวข้อนี้ไม่ใช่รอยเหี่ยวย่นข้างดวงตา แต่เป็นสัญลักษณ์ใน ERD ที่ใช้เพื่อแสดงความสัมพันธ์แบบหนึ่งต่อหลาย (one-to-many) หรือหลายต่อหลาย (many-to-many) โดยในด้านที่เป็น "หลาย" จะใช้สัญลักษณ์รูป "ตีนกา" ซึ่งเป็นรูปเส้นสามแฉก เหมือนอย่างรอยที่เกิดหากท่านจับตีนกามาจุ่มหมึก (ถ้ามันยอม) แล้วซับลงบนกระดาษ  (ผู้เขียนไม่แน่ใจเหมือนกันว่าตีนของอีกาอันที่จริงแล้วมีนิ้วอยู่กี่นิ้ว แต่สัญลักษณ์ใน ERD จะเป็นเส้นสามเส้น)

ภาพ 5-2 : ตีนกาคือสัญลักษณ์ที่ใช้เพื่อแสดงความสัมพันธ์ใน ERD ในด้านที่เป็น "หลาย" ยกตัวอย่างเช่นในภาพนี้ แสดงความสัมพันธ์แบบ "หนึ่งต่อหลาย" ด้านที่เป็น "หนึ่ง" คือตาราง Author ด้านที่เป็น "หลาย" คือตาราง Publication นั่นคือนักเขียน (Author) หนึ่งคนอาจมีหนังสือ (Publication) ได้หลายเล่ม

 

5.1.2. ความสัมพันธ์แบบหนึ่งต่อหนึ่ง
ความสัมพันธ์แบบหนึ่งต่อหนึ่งเป็นแบบที่ไม่ค่อยพบบ่อยนัก นอกจากจะจงใจออกแบบให้เป็นเช่นนั้น ท่านจะพบความสัมพันธ์แบบหนึ่งต่อหนึ่งได้ในการแปลงนอร์มัลฟอร์มระดับที่สี่เพื่อขจัดค่า NULL ออกจากตารางแม่ (เพื่อประหยัดเนื้อที่ในฮาร์ดดิสก์ ดูรายละเอียดในบทต่อไป)  เนื่องจากปัจจุบันฮาร์ดดิสก์มีความจุสูงมากและมีราคาถูก และใน SQL2008 มีชนิดข้อมูลที่เปลี่ยนความกว้างได้ ความสัมพันธ์แบบหนึ่งต่อหนึ่งจึงไม่เป็นที่นิยมเพราะมีประสิทธิภาพต่ำ

สัญลักษณ์แทนความสัมพันธ์แบบหนึ่งต่อหนึ่งเป็นขีดเพียงขีดเดียว

ภาพ 5-3 : ความสัมพันธ์แบบหนึ่งต่อหนึ่งแสดงเป็นนัยว่ามีหน่วยข้อมูลหนึ่งหน่วยอยู่ในทั้งสองตาราง สัญลักษณ์จึงใช้ขีดๆ เดียว

 

5.1.3. ความสัมพันธ์แบบหนึ่งต่อหลาย
ความสัมพันธ์แบบหนึ่งต่อหลายเป็นรูปแบบที่พบได้บ่อยที่สุดในฐานข้อมูลสัมพันธ์ นั่นคือข้อมูลหนึ่งแถวในตาราง ก เชื่อมโยงกับข้อมูลหลายแถวในตาราง ข ยกตัวอย่างเหมือนที่เรียนไปแล้วในหัวข้อตีนกา ตาราง Author เก็บข้อมูลนักเขียนหนึ่งแถวคือนักเขียนหนึ่งคน นักเขียนคนเดียวอาจเขียนหนังสือไว้หลายเล่ม ดังนั้นในตาราง Publication ซึ่งเก็บข้อมูลหนังสือหนึ่งเล่มต่อหนึ่งแถวจึงอาจเชื่อมโยงกับตาราง Authorในแบบหนึ่งต่อหลาย

ภาพ 5-4 : ความสัมพันธ์แบบหนึ่งต่อหลายแสดงเป็นนัยว่ามีหน่วยข้อมูลหนึ่งหน่วยในตาราง ก และหลายหน่วยในตาราง ข ตรงตาราง ก จึงใช้รูปขีดๆ เดียว ส่วนตาราง ข ซึ่งมีข้อมูลหลายหน่วยจะใช้สัญลักษณ์รูปตีนกา

 

5.1.4. ความสัมพันธ์แบบหลายต่อหลาย
ความสัมพันธ์แบบหลายต่อหลายหมายถึงทุกๆ แถวในตาราง ก อาจเชื่อมโยงกับหลายๆ แถวในตาราง ข ตัวอย่างคลาสสิกของความสัมพันธ์แบบนี้คือ ตารางเก็บรายชื่อนักเรียนกับตารางเก็บรายชื่อวิชา ปรกตินักเรียนทุกคนจะลงทะเบียนเรียนมากกว่าหนึ่งวิชา (คือไม่มีนักเรียนคนใดลงทะเบียนเรียนเพียงวิชาเดียว) และในทางกลับกัน ทุกๆ วิชาจะมีนักเรียนเข้าเรียนมากกว่าหนึ่งคน (ไม่มีวิชาใดที่มีนักเรียนลงทะเบียนเรียนเพียงคนเดียว) ผลลัพธ์คือความสัมพันธ์แบบหลายต่อหลายระหว่างนักเรียนกับวิชาต่างๆ

การออกแบบฐานข้อมูลให้มีตารางซึ่งมีความสัมพันธ์แบบหลายต่อหลายไม่ได้ทำให้เกิดผลเสียอะไร แต่ถ้าโปรแกรมประยุกต์หรือผู้ใช้ต้องการค้นหานักเรียนแต่ละคนในแต่ละรายวิชา เราจะต้องสร้างตารางขึ้นอีกอันเพื่อการนี้ ยกตัวอย่างเช่นตารางแรกคือ A ตารางที่สองคือ B ตารางที่สามที่ต้องสร้างคือ AB อันเป็นตารางที่รวมข้อมูลจาก A และ B โปรดทราบว่าตาราง AB ไม่ใช่สิ่งจำเป็น เราจะสร้างก็ต่อเมื่อโปรแกรมประยุกต์หรือผู้ใช้ต้องการเท่านั้น

ภาพ 5-5 : ความสัมพันธ์แบบหลายต่อหลายสามารถนำมาสร้างเป็นตารามใหม่ได้อีกหนึ่งตาราง ในภาพนี้ตาราง Publisher เก็บข้อมูลสำนักพิมพ์ ตาราง Publication เก็บข้อมูลหนังสือ สองตารางนี้มีความสัมพันธ์แบบหลายต่อหลาย จึงสามารถนำมาสร้างเป็นตารามใหม่ได้อีกหนึ่งตารางคือ Edition

 

5.1.5. ความสัมพันธ์แบบศูนย์ หนึ่ง และหลายๆ
ความสัมพันธ์ระหว่างตารางต่างๆ อาจเป็นแบบศูนย์ หนึ่ง และหลายๆ ศูนย์หมายถึงไม่มีบรรทัดข้อมูลในตารางเป้าหมายเลย ศูนย์และหนึ่งหมายถึงอาจมีหรือไม่มีข้อมูลก็ได้ หนึ่งโดยไม่มีศูนย์ (คือมีแค่หนึ่งเท่านั้น) หมายถึงจำเป็นต้องมีข้อมูลหนึ่งบรรทัด

ยกตัวอย่างเช่นความสัมพันธ์ระหว่างตาราง Rank และตาราง Edition โดยตาราง Rank เก็บข้อมูลการจัดอันดับของหนังสือ (ว่าได้รับความนิยมเพียงใด) และตาราง Edition เก็บข้อมูลการจัดพิมพ์ในแต่ละครั้ง เนื่องจากในตาราง  Edition จะมีข้อมูลหนังสือเรื่องหนึ่งอยู่หนึ่งแถวมันจึงมีความสัมพันธ์แบบ "หนึ่ง" ส่วนตาราง Rank อาจไม่มีข้อมูลหนังสือเล่มนั้นอยู่เลย หรืออาจข้อมูลหนังสือเล่มนั้นอยู่หนึ่งแถว มันจึงมีความสัมพันธ์แบบ "ศูนย์และหนึ่ง"

ภาพ 5-6 : สัญลักษณ์ที่ใช้เพื่อแสดงความสัมพันธ์แบบศูนย์และหนึ่งคือรูปวงกลม (แทนศูนย์) และขีดหนึ่งขีด (แทนหนึ่ง) อย่างที่เห็นทางกรอบซ้าย ซึ่งแสดงความสัมพันธ์ระหว่างตาราง Rank และ Edition โดยในฝั่ง Rank เป็นแบบศูนย์และหนึ่ง ขณะที่ในฝั่ง Edition เป็นแบบหนึ่ง ดังนั้นความสัมพันธ์ระหว่างตาราง Rank และ Edition จึงเป็นแบบหนึ่งต่อศูนย์และหนึ่ง  ส่วนสัญลักษณ์ที่ใช้เพื่อแสดงความสัมพันธ์แบบศูนย์และหนึ่งหรือหลายๆ คือรูปตีนกาบวกขีดและวงกลมอย่างที่เห็นด้านบนของตารง Edition ทางกรอบขวาในภาพ

 

5.1.6. ตารางแม่ ตารางลูก
ในแบบจำลองฐานข้อมูลสัมพันธ์ท่านจะได้พบความสัมพันธ์แบบตารางแม่ (Parent Table ย่อ PT) และตารางลูก (Child Table ย่อ CT)อยู่เสมอ  นิยามของ PT คือตารางซึ่งมีข้อมูลที่ถูกอ้างถึงใน CT ส่วนนิยามของ CT คือตารางที่อ้างถึงข้อมูลใน PT ยกตัวอย่างเช่น ในภาพ 5-6 ตาราง Publication เป็น PT ของตาราง Edition และพูดได้อีกอย่างหนึ่งว่าตาราง Edition เป็น CT ของตาราง Publication

วิธีดูว่าตารางใดเป็น PT ตารางใดเป็น CT ให้ดูที่ FK หากตาราง ก มี FK ที่เชื่อมโยงไปยังตาราง ข จะถือว่าตาราง ก เป็น CT ของตาราง ข หรือพูดได้อีกอย่างหนึ่งว่าตาราง ข เป็น PT ของตาราง ก ยกตัวอย่างเช่น ในภาพ 5-6 ตาราง Edition มี FK คือคอลัมน์ publication_id ที่เชื่อมโยงไปยังคอลัมน์ชื่อเดียวกันในตาราง Publication

 

5.1.7. ความสัมพันธ์ที่จำแนกได้และไม่ได้
ฐานข้อมูลสัมพันธ์มักมีตารางจำนวนมากเชื่อมโยงกันด้วยความสัมพันธ์แบบกุญแจหลักหรือไพร์มารีคีย์ (PK) และกุญแจนอกหรือฟอร์เรนคีย์ (FK) ความสัมพันธ์เกิดระหว่าง PT และ CT ความสัมพันธ์ที่ว่านี้มีหลายแบบได้แก่


•    ความสัมพันธ์แบบจำแนกได้: คือความสัมพันธ์ที่ CT ถูกแยกแยะโดย PT ในบางส่วน และถูกกำหนดความผู้พันธ์ในอีกบางส่วน ยกตัวอย่างเช่นในภาพ 5-7 ตาราง CoAuthor ซึ่งเก็บชื่อผู้เขียนร่วม มี PT สองตารางคือ Author และตาราง Publication โดยในตาราง CoAuthor จะมี PK เดียวกับ PT ทั้งสอง

•    ความสัมพันธ์แบบจำแนกไม่ได้: คือความสัมพันธ์ที่ CT ไม่ขึ้นกับ PT นั่นคือ PK ของ CT ไม่ใช่กุญแจเดียวกันกับ PK ของ PT

•    ตารางผูกพัน: คือตารางที่มี FK เป็น PK ที่มาจาก PT เช่นตาราง CoAuthor ในภาพ 5-7

•    ตารางไม่ผูกพัน: หรือเอนทิตีอิสระคือตารางที่ไม่มี FK ที่เป็น PK ใน PT เช่นตาราง Publication ในภาพ 5-7

ภาพ 5-7 : แผนภูมิ ER นี้แสดงความสัมพันธ์ที่จำแนกได้และไม่ได้

 

วิธีออกแบบฐานข้อมูล : ตอน 2

 

 
Home Page  |   รายการบทความ   |   ลิงค์ที่เกี่ยวข้อง   |   laploy.com  |  เกี่ยวกับผู้เขียน

 

วิธีออกแบบฐานข้อมูล : ตอน 2

 

4.4. การออกแบบฐานข้อมูลในโลกจริง
ในโลกของความเป็นจริงการออกแบบฐานข้อมูลจะต้องคำนึงถึงผู้ใช้งานเป็นหลัก โดยการกระทำต่างๆ ข้อผู้ใช้จะมีผลมาจากกฎทางธุรกิจ กฎทางธุรกิจคือสิ่งที่เกิดจากธรรมชาติของกิจกรรมในหน่วยงานนั้นๆ เช่นบริษัทที่ผลิตไอศกรีมย่อมมีกฎทางธุรกิจที่แตกต่างจากธนาคาร  กฎทางธุรกิจคือตัวกำหนดการทำงาน ยกตัวอย่างเช่นหากกฎทางธุรกิจกำหนดไว้ว่าไอศกรีมหางเสือจัดเป็นสินค้าประเภท ฮ พนักงานย่อมจะจัดเก็บข้อมูลสินค้าประเภทนี้ไว้ในฐานข้อมูลของสินค้าประเภท ฮ

บางครั้งมุมมองของผู้ใช้กับมุมมองของผู้ออกแบบฐานข้อมูลอาจแตกต่างกัน ขึ้นอยู่กับการตีความกฎทางธุรกิจ แม้จะมองต่างมุมแต่ทั้งผู้ใช้และผู้ออกแบบฐานข้อมูลอาจถูกทั้งคู่ ที่เห็นต่างกันเป็นเพียงการมองปัญหาจากคนละด้าน

คนที่สำคัญสุดในการออกแบบฐานข้อมูลไม่ใช่ตัวท่าน แต่เป็น "ผู้ใช้ระดับล่างสุด" (end-user ผู้ใช้ที่ไม่มีความรู้ด้านคอมพิวเตอร์เลย แต่มักมีความรู้เกี่ยวกับกฎทางธุรกิจเป็นอย่างดี เช่นเจ้าหน้าที่บริหารระดับสูง) ท่านจึงต้องค้นหาความต้องการที่แท้จริงของผู้ใช้ระดับล่างสุดให้ได้ เคล็ดลับคือต้องคุยให้ถูกคน คนที่ท่านควรคุยด้วยคือผู้ใช้ระดับล่างสุดที่รู้ความต้องการทางธุรกิจอย่างรอบด้าน

ท่านต้องสืบให้รู้ว่าพนักงานระดับใดได้รับข้อมูลในขอบเขตใด เพราะบางครั้งผู้ใช้อาจเป็นนักพัฒนาซอฟต์แวร์ หรือเป็นผู้ใช้ระดับล่างสุด หรือแม้กระทั้งเป็นคนจากทั้งสองกลุ่ม พนักงานเหล่านี้ย่อมได้รับข้อมูลในขอบเขตที่แตกต่างกัน ยกตัวอย่างเช่น  พนักงานระดับล่างจะได้รับข้อมูลแคบๆ เฉพาะในส่วนที่ตนเกี่ยวข้อง ขณะที่พนักงานระดับบริหารจะได้รับข้อมูลในมุมกว้างแต่เป็นข้อมูลรวบยอด ท่านจำเป็นต้องรู้ว่าหากต้องการรายละเอียดต้องไปคุยกับพนักงานระดับล่างในแต่ละแผนก หากต้องการภาพรวมต้องไปคุยกับพนักงานระดับบริหาร

 

4.5. กฎทางธุรกิจ
กฎทางธุรกิจ (Business Rules) คือนิยามของกระบวนการ คำจำกัดความและข้อกำหนดต่างๆ ที่จำเป็นต้องนำมาใช้เพื่อให้หน่วยงานสามารถทำงานได้บรรลุเป้าหมาย ยกตัวอย่างกฎทางธุรกิจเช่น "ยอมให้ลูกค้านำสินค้าที่มีปัญหามาเปลี่ยนได้ภายในเจ็ดวันหลังจากซื้อ" หากเราออกแบบฐานข้อมูลมาอย่างสวยงามตามหลักการออกแบบทุกประการ แต่ฐานข้อมูลนั้นไม่สามารถตอบสนองกฎทางธุรกิจได้ฐานข้อมูลนั้นก็ไร้ค่า

โปรดพิจารณาแผนภูมิ ERD ในภาพ 4-2 อันเป็นโครงสร้างฐานข้อมูลร้านขายหนังสือออนไลน์ (ขายในอินเตอร์เน็ต) จะเห็นว่าข้อมูลของหนังสือหนึ่งเล่มถูกแบ่งแยกออกเป็นหกตาราง แต่ละตารางถูกเชื่อมโยงด้วยตัวเชื่อมที่ต่างกัน ยกตัวอย่างเช่นตาราง Publication (เป็นตารางหลักเก็บข้อมูลหนังสือ) ถูกกำหนดให้มีสี่คอลัมน์ คอลัมน์แรกคือ publication_id เป็นคีย์หลักของตารางนี้ subject_id เป็นฟอร์เรนคีย ทำหน้าที่เชื่อมกับตาราง subject ซึ่งเก็บข้อมูลประเภทหรือชนิดของหนังสือ author_id เป็นฟอร์เรนคียเช่นกันทำหน้าที่เชื่อมกับตาราง Author ซึ่งเก็บข้อมูลผู้แต่งหนังสือ และสุดท้ายคือคอลัมน์ title ที่ไม่ได้เชื่อมโยงกับใคร ทำหน้าที่เก็บชื่อหนังสือ

ฐานข้อมูลมีคุณสมบัติต่างๆ อย่างที่กล่าวถึงในย่อหน้าบนเพราะผู้ออกแบบพิจารณากฎทางธุรกิจแล้วนำมาใช้ออกแบบฐานข้อมูล หากเป็นแผนภูมิ ERD ของร้านขายหนังสือออนไลน์ร้านอื่น ที่มีกฎทางธุรกิจแตกต่างจากนี้ โครงสร้างต่างๆ ในแผนภูมิ ERD ย่อมจะแตกต่างไปจากนี้ การทำความเข้าใจกฎทางธุรกิจจะช่วยให้เข้าใจการไหลของข้อมูลที่เกิดขึ้นในการทำงานประจำวัน สิ่งนี่แหละคือหัวใจของการออกแบบฐานข้อมูล

 

4.6. นิยามกฎทางธุรกิจ
นิยามกฎทางธุรกิจคือกระบวนการต่างๆ ที่เกิดขึ้นในการทำงานประจำวัน การที่องค์กรตัดสินใจว่างานต่างๆ จะดำเนินการด้วยกรรมวิธีใด หรือองค์กรมีขึ้นเพื่อทำหน้าที่อะไร มีงานอะไรที่เกี่ยวข้องบ้าง มีรายได้จากอะไร และทำกำไรได้ด้วยวิธีใดมีผลมาจากการนิยามกฎทางธุรกิจ

นิยามกฎทางธุรกิจอาจกว้างและแตกต่างกันไปในระหว่างองค์กร แต่มักหนีไม่พ้นประเด็นต่างๆ ดังนี้
•    นโยบายขององค์กรในทุกรูปแบบและระดับชั้นขององค์กร
•    สูตรคำนวณต่างๆ (เช่นสถาบันการเงินจะมีสูตรคำนวณค่างวดในการซื้อบ้านหรือรถยนต์)
•    กฎระเบียบต่างๆ (อาจเกิดจากกฎหมาย หรือข้อจำกัด หรือมาตรฐานอุตสาหกรรม)

นิยามกฎทางธุรกิจจะเป็นตัวกำหนดโครงสร้างของฐานข้อมูล ยกตัวอย่างเช่นในฐานข้อมูลของร้านขายหนังสือออนไลน์ที่แสดงในแผนภูมิ ERD ที่ผ่านมา มีกฎทางธุรกิจว่าในตาราง Publication หนังสือทุกเล่มอย่างน้อยต้องมีผู้แต่งหนึ่งคน และหนังสือบางเล่มอาจมีผู้แต่งสองคนหรือมากกว่าก็ได้  แต่หนังสือทุกๆ เล่มจะมีผู้แต่งจำนวนศูนย์คนไม่ได้

ตาราง edition เกิดจากกฎทางธุรกิจว่าหนังสือหนึ่งเล่มอาจมีการปรับปรุงและพิมพ์ใหม่ได้หลายครั้ง ดังนั้นหนังสือหนึ่งเล่มจึงมีข้อมูลในตาราง edition ได้หลายบรรทัด แต่จะเป็นศูนย์ไม่ได้  (ต้องมีการพิมพ์อย่างน้อยหนึ่งครั้ง) ส่วนข้อมูลผู้เขียน (ตาราง Author) มีข้อกำหนดว่าผู้เขียนหนึ่งคนอาจมีจำนวนเล่มของหนังสือที่เกี่ยวข้องเป็น ศูนย์ หนึ่ง สอง หรือมากกว่าก็ได้ (แม้ผู้เขียนที่มีหนังสือศูนย์เล่มยังไม่จัดว่าเป็นผู้เขียนจริงๆ แต่กฎทางธุรกิจอนุโลมให้)

 

4.7. ความสำคัญของกฎทางธุรกิจ
ในขั้นตอนการออกแบบฐานข้อมูลผู้เขียนเคยเจอทั้งลูกค้าที่บอกว่า "อย่าใส่กฎทางธุรกิจไว้ในฐานข้อมูล" และลูกค้าที่บอกว่า "กรุณาใส่กฎทางธุรกิจไว้เยอะๆ" ทั้งสองเงื่อนไขที่ว่ามานั้นล้วนเหลวไหล เพราะการออกแบบฐานข้อมูลอย่างไรก็ต้องใส่กฎทางธุรกิจไว้เสมอ แต่การใส่กฎทางธุรกิจไว้เยอะๆ ก็ทำไม่ได้เช่นกัน บางคนอาจต้องการให้สพร็อกซ์เป็นตัวกำหนดกฎทางธุรกิจ ผู้เขียนไม่แนะนำให้ทำเช่นนั้นเพราะจะทำให้ฐานข้อมูลทำงานอย่างไม่มีประสิทธิภาพ (โดยเฉพาะอย่างยิ่งในแบบจำลองฐานข้อมูลสัมพันธ์) แต่การใส่เมธอดไว้คู่กับออพเจ็กต์ฐานข้อมูลกลับให้ผลตรงกันข้าม คือทำให้ฐานข้อมูลมีประสิทธิภาพดีขึ้น (ในแบบจำลองฐานข้อมูลแบบวัตถุ)

เนื่องจากหนังสือเล่มนี้เน้นเฉพาะฐานข้อมูลสัมพันธ์ ผู้เขียนจึงไม่แนะนำให้ใส่กฎทางธุรกิจไว้ในสพร็อกซ์ แต่ให้ใช้โครงสร้างของตาราง และความสัมพันธ์ระหว่างตาราง เป็นตัวสะท้อนกฎทางธุรกิจ ส่วนกฎทางธุรกิจที่มีตรรกะซับซ้อนให้ทำในระดับโค้ดของโปรแกรมประยุกต์ ควรใช้สพร็อกซ์เพื่อทำหน้าที่เชื่อมต่อระหว่างฐานข้อมูลและโปรแกรมประยุกต์ ในหนังสือนี้ท่านจะได้เรียนวิธีสร้างและใช้งานสพร็อกซ์โดยละเอียด ทั้งสพร็อกซ์ ภาษา T-SQL และสพร็อกซ์ภาษา C#

 

4.8. ความสัมพันธ์กับมนุษย์
ฐานข้อมูลและโปรแกรมประยุกต์ล้วนจะถูกใช้งานโดยมนุษย์ทั้งสิ้น ท่านจึงหลีกเลี่ยงไม่ได้ที่จะต้องมีปฏิสัมพันธ์กับมนุษย์ โดยเฉพาะอย่างยิ่งผู้ใช้งานระดับปลายแถวเพราะเป็นเจ้าหน้าที่ระดับที่รู้รายละเอียดปลีกย่อยดีกว่าใคร และเป็นเป็นกลุ่มผู้ใช้กลุ่มใหญ่ที่สุด การพูดคุยและการรับฟังผู้ใช้งานระดับปลายแถวจะทำให้ท่านออกแบบฐานข้อมูลได้ดีขึ้น สิ่งที่ควรคำนึงด้านความสัมพันธ์กับมนุษย์มีดังนี้

•    เปลี่ยนลักษณะเฉพาะให้เป็นลักษณะทั่วไป: นักออกแบบฐานข้อมูลต้องแปลงสิ่งผู้ใช้มองว่าเฉพาะเจาะจงให้เป็น แอบสเทรก (abstract การลดทอนรายละเอียดให้เป็นนามธรรมเพื่อให้เกิดความไม่จำเพาะเจาะจง) ยกตัวอย่างเช่นผู้ใช้มองว่าการขายรถยี่ห้อโตโยต้ากับยี่ห้อฟอร์ดเป็นกระบวนการที่แตกต่างกันโดยสิ้นเชิง เพราะบริษัทผู้ผลิตคนละรายกัน ของแถมต่างๆ ก็ไม่เหมือนกัน บริการหลังการขายก็แตกต่างกัน ฯลฯ แต่ในมุมมองนักออกแบบฐานข้อมูลท่านจะต้องมองว่าทั้งโตโยต้าและฟอร์ดเป็นรถยนต์เหมือนกัน การขายรถยนต์อะไรก็ตามเป็นธุรกรรมแบบเดียวกัน หากต้องแบ่งแยกอาจก็อาจแบ่งว่าเป็นรถเก๋งหรือรถกระบะ แต่ไม่ได้มองว่าการขายรถคนละยี่ห้อเป็นธุรกรรมที่แตกต่างกันโดยสิ้นเชิง

•    คุยให้ถูกคน: จากประสบการของผู้เขียนพบว่าพนักงานบางคนจะมีความรู้ทางเทคนิคดี ขณะที่บางคนไม่ แต่พนักงานที่มีความรู้ทางเทคนิคดีใช่ว่าจะเป็นแหล่งข้อมูลเพื่อการออกแบบฐานข้อมูลดีกว่าคนที่รู้เทคนิคน้อยกว่า ปรกติแล้วในองค์กรเล็กๆ พนักงานที่รู้รายละเอียดของธุรกิจดีที่สุดคือเจ้าหน้าที่บริหารระดับสูง ถ้าเป็นองค์ที่ใหญ่ขึ้นพนักงานที่มีความรู้ในรายละเอียดของธุรกิจดีที่สุดคือเจ้าหน้าระดับผู้จัดการ ถ้าเป็นองค์กรเล็กๆ การเข้าพบเจ้าหน้าที่บริหารระดับสูงจะทำได้ง่าย ในองค์ที่ใหญ่ขึ้นการเข้าพบเจ้าหน้าที่บริหารระดับสูงทำได้ยากหรือทำไม่ได้เลย แต่ถึงจะทำได้ก็อาจไม่เป็นประโยชน์ต่อการออกแบบฐานข้อมูลมากนัก

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

•    รับแต่ข้อมูลที่ถูกต้อง: นักออกแบบฐานข้อมูลจะต้องรู้ว่าควรฟังใครหรือไม่ควรฟังใคร ผู้ใช้บางระดับอาจมีภาพมุมกว้างแต่ขาดรายละเอียด ในขณะที่บางระดับมีภาพมุมแคบแต่มีรายเอียดมาก การพบปะพูดคุยกับผู้ใช้หลายๆ ระดับๆ ละหลายๆ คนจะช่วยให้ได้รับข้อมูลมากขึ้นซึ่งจะช่วยให้ท่านกลั่นกรองได้ว่าข้อมูลใดถูก ข้อมูลใดผิด

•    ระวังการใช้คำ: คำเฉพาะหรือคำจาร์กอนในองค์กรต่างๆ อาจทำให้ไขว้เขวได้ง่าย ผู้เขียนเคยพบโครงการหนึ่งที่ผู้ออกแบบฐานข้อมูลออกแบบผิด เพราะตอนสัมภาษณ์ผู้ใช้เพื่อเก็บข้อมูลเข้าใจผิดความหมายของคำๆ หนึ่งผิดไป  ต่อมาภายหลังเมื่อรู้ว่าผิดก็สายไปแล้ว (เพราะฐานข้อมูลและแอพลิเกชันพัฒนาเสร็จแล้วและระบบเริ่มเดินเครื่องแล้ว) คำที่เข้าใจผิดคือคำว่า "ผนึก" เป็นคำจาร์กอนในองค์กรนั้นหมายถึงขั้นตอนระหว่างกลางในสายการผลิต เป็นการห่อหุ้มชิ้นส่วนก่อนส่งไปยังกระบวนการถัดไป แต่นักออกแบบฐานข้อมูลเข้าใจผิด คิดว่าคำนี้หมายถึงขั้นตอนบรรจุหีบห่ออันเป็นขั้นตอนสุดท้าย การพูดคุยกับผู้ใช้ท่านจะต้องสอบถามความหมายของคำต่างๆ ให้ชัดเจน อย่าอนุมานความหมายไปเอง

 

4.9. ศึกษาจากระบบเดิม
บ่อยครั้งหน่วยงานที่ท่านจะออกแบบสร้างฐานข้อมูลมีระบบฐานข้อมูลเดิมอยู่แล้ว มันอาจเป็นแหล่งข้อมูลที่มีค่าให้ท่านใช้หาข้อมูลสำหรับออกแบบฐานข้อมูลได้ดี ระบบฐานข้อมูลเดิมอาจเป็นเพียงเอกสารกระดาษ ระบบฐานข้อมูลเก่าในเมนเฟรม หรือแม้แต่การจัดเก็บข้อมูลด้วยโปรแกรมเวิร์คชีต จงศึกษาจากระบบเดิมในสิ่งต่างๆ ต่อไปนี้

•    เอกสารกระดาษ: หากระบบเดิมทำงานโดยใช้เอกสารกระดาษ ให้รวบรวมเอกสารให้ได้มากที่สุดแล้วศึกษาจากเอกสารเหล่านั้น การทำเช่นนี้จะทำได้ง่ายขึ้นหากมีพนักงานในองค์กรนั้น ซึ่งเป็นผู้มีความรู้ในระบบเป็นอย่างดี ให้ความช่วยเหลือในการรวมรวมและแยกแยะเอกสาร

•    ระบบฐานข้อมูลเดิม: การศึกษาระบบงานจากฐานข้อมูลเดิมมักทำได้อย่างยากลำบาก เพราะโครงสร้างของฐานข้อมูลเดิมอาจมีขนาดใหญ่และซับซ้อน หรือเข้าถึงได้ยากหรือไม่ได้เลย เช่นเดียวกับเอกสารกระดาษ การศึกษาระบบฐานข้อมูลเดิมจะทำได้ง่ายขึ้นหากได้รับความช่วยเหลือจากพนักงานที่มีความรู้ในระบบเป็นอย่างดี

•    ระบบผสม: มีบางกรณีที่ระบบฐานข้อมูลเดิมขององค์กรเป็นระบบผสม ที่มีข้อมูลจากแผนกต่างๆ ซึ่งใช้เทคโนโลยีแตกต่างกัน เช่นแผนกการผลิตใช้แอพลิเกชันที่สร้างจากภาษา C# แผนกบัญชีใช้ออราเคิล และแผนกบริหารใช้ไมโครซอฟต์เอกเซล ฐานข้อมูลในระบบต่างๆ เหล่านี้เชื่อมโยงกันผ่านฐานข้อมูลกลางหรือเกตเวย์ อันเป็นฐานข้อมูลกลางที่รับข้อมูลจากทุกหน่วยงานมาผสมกัน

•    แปลงจากเวิร์คชีต: เวิร์คชีต (worksheet)หรือสเปรดชีต (spreadsheet) แม้จะคล้ายแฟลตไฟล์แต่เมื่อพิจารณาโดยละเอียดจะพบว่าอาจมีความซับซ้อนกว่า เพราะอาจมีเวิร์คชีตซ้อนกันหลายระดับและอาจมีสูตรคำนวณมากมาย แต่โดยทั่วไปแล้วการศึกษาจากเวิร์คชีตจะง่ายกว่าการศึกษาจากระบบข้อมูลเดิมในเมนเฟรมและระบบผสม

•    ฐานข้อมูลสัมพันธ์เดิม: ในกรณีที่หน่วยงานมีฐานข้อมูลสัมพันธ์อยู่แล้ว แต่ต้องการสร้างฐานข้อมูลใหม่เพราะของเก่ายุ่งเหยิงไม่มีประสิทธิภาพ ในกรณีนี้การศึกษาระบบงานจากฐานข้อมูลเดิมคือการหาว่าปัญหาคืออะไร และมีวิธีแก้ไขอย่างไรบ้าง โดยปรกติแล้วผู้ใช้ที่ไม่พอใจในระบบเดิมจะมีแนวคิดอยู่ในใจแล้วว่าต้องการปรับปรุงอะไรบ้าง

 

4.10. ข้อจำกัดและการตรวจสอบ
ข้อจำกัดคือสิ่งที่กำหนดว่าอะไรทำได้อะไรทำไม่ได้ ยกตัวข้อจำกัดคือ  "ตัวแทนฝ่ายขายภาคกลางจะขายสินค้าที่ภาคเหนือไม่ได้แต่ขายที่ภาคตะวันออกได้" ส่วนการตรวจสอบคือการคัดกรองข้อมูล เพื่อให้ฐานข้อมูลมีความถูกต้อง ยกตัวอย่างการตรวจสอบคือ "ยอดสั่งซื้อต่ำสุดของไอศกรีมหางเสือคือหนึ่งกล่อง"

ท่านสามารถใส่ข้อกำหนดของข้อจำกัดและการตรวจสอบในฐานข้อมูลสัมพันธ์ได้ โดยจะทำในระดับคอลัมน์หรือในระดับตารางก็ได้ ยกตัวอย่างเช่น

•    NOT NULL: ทำหน้าที่กำหนดว่าคอลัมน์นั้นจะเป็น NULL ไม่ได้ คือจะต้องมีข้อมูลอยู่เสมอ
•    Validate Check: ทำหน้าที่ตรวจสอบการใส่ข้อมูลว่าตรงกับข้อกำหนดหรือไม่ ยกตัวอย่างเช่นคอลัมน์ที่ใช้เก็บข้อมูลเพศ กำหนดไว้ว่าให้เป็นตัวอักษรหนึ่งตัว จะต้องเป็น M หรือ F เท่านั้น
•    Key: กำหนดการเป็นกุญแจหรือคีย์ของคอลัมน์ใดๆ เช่นเป็นไพรมารีคีย์ ฟอร์เรนคีย์ และคีย์ที่ห้ามมีค่าซ้ำกัน

 

4.11. สรุปท้ายบท
การออกแบบฐานข้อมูลจำเป็นต้องมีการวางแผนที่ดี โครงสร้างของฐานข้อมูลที่ดีควรเรียบง่าย มีบูรณภาพดี สนับสนุนคิวรีทั้งแบบประจำและแบบเฉพาะกิจ ไม่ควรทำนอร์มัลไลซ์เข้มข้นเกินไปจนยากแก่การเขียนคิวรี สามารถรองรับการเพิ่มขยายและเปลี่ยนแปลงในอนาคตได้ หากท่านออกแบบได้ดังนี้จะมีผลให้ฐานข้อมูลทำงานได้อย่างมีประสิทธิภาพ มีความยืดหยุ่น สร้างแอพลิเกชันได้ง่าย

การวางแผนสร้างฐานข้อมูลจะต้องคำนึงถึงกฎทางธุรกิจ เนื่องจากองค์กรแต่ละแห่งย่อมมีกฎเกณฑ์ในการดำเนินงานที่แตกต่างกัน ดังนั้นในฐานะนักออกแบบฐานข้อมูล ท่านจะต้องรวบรวมข้อมูลจากผู้ใช้งานในองค์กรนั้นๆ รวมทั้งศึกษาระบบงานเดิมที่องค์กรนั้นๆ ใช้อยู่ รับฟังความต้องการและความคาดหวัง เพื่อนำมาออกแบบฐานข้อมูลใหม่ที่สามารถตอบสนองความต้องการทางธุรกิจได้ตรงตามจุดมุ่งหมาย

ในบทต่อไปท่านจะได้เรียนวิธีใช้แผนภูมิ ERD เพื่อการออกแบบฐานข้อมูล

 

4.12. คำถามท้ายบท

1.    ขั้นตอนที่สำคัญสุดในการออกแบบฐานข้อมูลคืออะไร
2.    บูรณภาพของข้อมูลคืออะไร
3.    คิวรีแบบ ad-hoc คืออะไร
4.    ฐานข้อมูลควรเชื่อมต่อกับแอพลิเกชันอย่างไร
5.    ฐานข้อมูลที่มีประสิทธิภาพเป็นอย่างไร
6.    การออกแบบทางแนวคิดคืออะไร
7.    การออกแบบทางตรรกะคืออะไร
8.    กฎทางธุรกิจคืออะไร
9.    การออกแบบฐานข้อมูลสัมพันธ์ควรสะท้อนกฎทางธุรกิจด้วยอะไร
10.    การศึกษาจากระบบเดิมอาจศึกษาจากอะไรได้บ้าง

 

4.13. แบบฝึกหัดท้ายบท
สมมุติว่าท่านไปเก็บข้อมูลเพื่อออกแบบสร้างฐานข้อมูลที่สโมสรกอล์ฟแห่งหนึ่ง เมื่อตรวจสอบแอพลิเกชันฐานข้อมูลเดิมที่ใช้งานอยู่ท่านพบว่ามีหน้าจอให้ป้อนพิมพ์ข้อมูลสมาชิกดังภาพ 4-3

ภาพ 4-3: หน้าจอให้ป้อนพิมพ์ข้อมูลสมาชิกของแอพลิเกชันฐานข้อมูลเดิมที่ใช้งานอยู่

จงออกแบบตารางเพื่อเก็บข้อมูลจากหน้าจอนี้ โดยแบ่งออกเป็นสองตารางคือ ตาราง Member เก็บข้อมูลสมาชิก และตาราง Type เก็บชนิดสมาชิกและจำนวนเงินค่าสมาชิก สองตารางนี้เชื่อมโยงกันด้วยคีย์ที่เหมาะสม

 

วิธีออกแบบฐานข้อมูล : ตอน 1

 

   Home Page  |   รายการบทความ   |   ลิงค์ที่เกี่ยวข้อง   |   laploy.com  |  เกี่ยวกับผู้เขียน

 

วิธีออกแบบฐานข้อมูล : ตอน 1

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

ในบทที่แล้วท่านได้เรียนสิ่งสำคัญเบื้องต้นในการออกแบบฐานข้อมูลไปแล้ว ในบทนี้ท่านจะได้เรียนการออกแบบฐานข้อมูลในระดับที่ลึกขึ้น ซึ่งมีหัวข้อต่างๆ ดังนี้

•    กำหนดเป้าหมาย
•    ฐานข้อมูลที่มีประสิทธิภาพ
•    หลักการออกแบบฐานข้อมูล
•    การออกแบบฐานข้อมูลในโลกจริง
•    กฎทางธุรกิจ
•    นิยามกฎทางธุรกิจ
•    ความสำคัญของกฎทางธุรกิจ
•    ความสัมพันธ์กับมนุษย์
•    ศึกษาจากระบบเดิม
•    ข้อจำกัดและการตรวจสอบ

 

4.1. กำหนดเป้าหมาย
ขั้นตอนที่สำคัญสุดในการวางแผนโครงการอะไรก็ตามมีเพียงอยู่เพียงขั้นตอนเดียว นั่นคือการระบุว่าจุดมุ่งหมายหรือเป้าหมายของงานเป็นอย่างไร การทำโครงการจะเริ่มจากขั้นตอนไหนก็ได้ แต่โครงการที่ประสบความสำเร็จส่วนมากเป็นโครงการที่วางแผนไว้ก่อนอย่างรัดกุม ขั้นตอนแรกสุดของการวางแผนคือการนิยามเป้าหมาย การออกแบบฐานข้อมูลก็เช่นเดียวกัน ท่านควรนิยามเป้าหมายโดยพิจารณาประเด็นต่างๆ ดังนี้


•    โครงสร้าง: หากท่านออกแบบฐานข้อมูลที่ต้องใช้กระดาษ A4 มากถึง 50 หน้านำมาติดไว้บนกำแพง ลากเส้นเชื่อมโยงความสัมพันธ์ระหว่างแผ่น เมื่อไล่ดูความสัมพันธ์แต่ละอย่างต้องใช้เวลาถึง 20 นาที แสดงว่าโครงสร้างนี้มีปัญหาแล้ว การออกแบบฐานข้อมูลจะต้องคำนึงถึงโครงสร้าง ฐานข้อมูลที่ดีควรเรียบง่าย ไม่ซับซ้อนเกินความจำเป็น


•    บูรณภาพของข้อมูล: บูรณภาพหมายถึงกฎที่ใช้ในการออกแบบฐานข้อมูลเพื่อให้มั่นใจว่าข้อมูลจะไม่สูญหายหรือเปลี่ยนแปลงไปโดยไม่เจตนา จะหายไปก็ต่อเมื่อท่านสั่งลบอย่างตั้งใจเท่านั้น การออกแบบฐานข้อมูลจะต้องคำนึงถึงบูรณภาพด้วย


•    คิวรีแบบประจำและแบบจร: คิวรีแบบประจำคือคิวรีที่ผู้สร้างหรือผู้ดูแลฐานข้อมูล (DBA) สร้างเก็บไว้ให้ผู้ใช้เรียกใช้กระทำการต่างๆ กับฐานข้อมูล คิวรีแบบจร (ad-hoc) คือคิวรีที่ผู้ใช้เขียนขึ้นเองสดๆ เพื่อใช้เฉพาะกิจ เนื่องจากผู้เขียนคิวรีแบบจรมักไม่ใช่นักคอมพิวเตอร์ (เช่นอาจเป็นผู้จัดการฝ่ายขาย) จึงไม่รู้วิธีเขียนคิวรีให้มีประสิทธิภาพ คิวรีแบบจรจึงมักถูกห้ามใช้ในสภาพแวดล้อมที่คับขัน (คืองานที่มีผู้ใช้พร้อมกันมาก มีปริมาณข้อมูลไหลมากเช่นในงาน OLTP) แต่อาจใช้ได้ในสภาพแวดล้อมที่ผ่อนคลายกว่า (คืองานที่มีผู้ใช้งานพร้อมๆ กันน้อย มีปริมาณข้อมูลไหลน้อย เช่นในงานคลังข้อมูล)  ในการออกแบบฐานข้อมูลท่านควรพิจารณาว่าจะสนับสนุนคิวรีแบบประจำหรือแบบจร หรือทั้งสองแบบ


•    การคิวรี: ฐานข้อมูลที่ออกแบบมาสำหรับสภาพแวดล้อมที่คับขัน (เช่นในงาน OLTP) อาจเน้นประสิทธิภาพมากเกินไป (คือทำนอร์มัลไลซ์อย่างหนัก) การทำเช่นนั้นจะทำให้เขียนคิวรียาก ส่วนการออกแบบฐานข้อมูลในสภาพแวดล้อมที่ผ่อนคลายกว่า (เช่นในงานคลังข้อมูล) อาจนำฐานข้อมูลเพื่องาน OLTP มาลดการแยกย่อยตารางเพื่อให้นอร์มัลไลซ์มีความเข้มข้นน้อยลง (denornalize) เพื่อให้สะทอนลักษณะทางธุรกิจมากขึ้น ซึ่งจะช่วยให้เขียนคิวรีได้ง่ายกว่า (ดุรายละเอียดเกี่ยวกับการทำนอร์มัลไลซ์ในบทที่ 5 และ 6) ในการออกแบบฐานข้อมูลท่านจะต้องพิจารณาว่าควรทำนอร์มัลไลซ์มากน้อยเพียงใด ด้วยการชั่งน้ำหนักระหว่างประสิทธิภาพและความยากง่ายของการเขียนคิวรี


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


•    การแยก-รวมตาราง: การออกแบบฐานข้อมูลเพื่องาน OLTP ควรแยกย่อยตารางออกเป็นจำนวนมากโดยละเอียด (อาจไม่เป็นเช่นนั้นในทุกๆ กรณี) ส่วนการออกแบบฐานข้อมูลเพื่องานคลังข้อมูลไม่ควรแยกย่อยตาราง แต่ให้รวมข้อมูลเรื่องเดียวไว้ภายในตารางเดียวกัน ในการออกแบบฐานข้อมูลท่านจะต้องพิจารณาว่าควรแยกหรือรวมตารางมากเพียงใดจึงจะเหมาะกับงานนั้นๆ


•    การเพิ่มขยาย: ออกแบบให้รองรับกับปริมาณการใช้งานที่เพิ่มขึ้นอย่างรวดเร็วเป็นหลายเท่าได้ ยกตัวอย่างเช่น โหลดการทำงานของฐานข้อมูลอาจเพิ่มเป็นร้อยหรือพันเท่าได้ภายในชั่วข้ามคืนหากเว็บไซต์ได้รับความนิยมขึ้นอย่างฉับพลัน ในการออกแบบฐานข้อมูลท่านจะต้องหาลู่ทางให้รองรับปริมาณการใช้งานที่เพิ่มขึ้นได้


•    ความเปลี่ยนแปลง: การเปลี่ยนแปลงโครงสร้างของฐานข้อมูลมักส่งผลกระทบกับแอพลิเกชัน วิธีป้องกันไม่ให้เกิดผลกระทบคือลดความผูกพันระหว่างแอพลิเกชันกับฐานข้อมูลโดยสร้างตัวเชื่อมต่อ (เช่นสพร็อกซ์ ดูบทที่ 22) ตัวเชื่อมต่อนี้มีสภาพเป็นกล่องดำ เพราะแอพลิเกชันสามารถเรียกใช้งานได้โดยไม่ต้องรู้การทำงานภายในของมัน เมื่อแอพลิเกชันต้องการติดต่อกับฐานข้อมูลต้องทำโดยผ่านกล่องดำเท่านั้น หากภายหลังมีการเปลี่ยนแปลงโครงสร้างของฐานข้อมูล ท่านก็เพียงแต่แก้ไขเฉพาะกล่องดำไม่ต้องแก้ไขแอพลิเกชัน การออกแบบฐานข้อมูลท่านจะต้องทำให้ฐานข้อมูลเชื่อมต่อกับแอพลิเกชันอย่างหลวมๆ (loose coupling) โปรดจำไว้ว่าการเชื่อมหลวมๆ คือดี การเชื่อมต่อแบบแน่นๆ  (tight coupling) ไม่ดี

 

ภาพ 4-1 : เว็บไซต์อย่าง ebay.com มีผู้เข้าทำธุรกรรมจากทั่วโลกวันละหลายๆ ล้านรายการ

 

4.2. ฐานข้อมูลที่มีประสิทธิภาพ
การออกแบบฐานข้อมูลให้บรรลุเป้าหมายทั้งหมดตามหัวข้อที่ผ่านมาอาจเป็นงานที่น่าปวดหัว แต่ก็คุ้มค่าเพราะหากทำได้จะเกิดข้อดีต่างๆ หลายอย่างดังนี้
•    ทำงานได้ดี: ฐานข้อมูลทำงานตอบสนองความต้องการได้ทุกข้อ กินทรัพยากรน้อย ผู้ใช้ทุกคนสามารถใช้งานได้อย่างไม่ติดขัด
•    คิวรีง่าย: เขียนคิวรีแล้วไม่เกิดปัญหาต่างๆ เช่น บูรณภาพของข้อมูล ความสัมพันธ์ระหว่างตารางผิด ตารางออกแบบไม่ได้ ฯลฯ
•    สร้างแอพลิเกชันง่าย: การออกแบบฐานข้อมูลให้สร้างแอพลิเกชันได้ง่ายเป็นสิ่งดี โดยเฉพาะอย่างยิ่งในงาน OLTP เพราะผู้ใช้ต้องใช้งานฐานข้อมูลทางอ้อมผ่านแอพลิเกชันโปรแกรม แต่ฐานข้อมูลในงานคลังข้อมูลอาจไม่จำเป็น เพราะผู้ใช้มักคิวรีฐานข้อมูลเองโดยตรงไม่ได้ทำงานผ่านแอพลิเกชัน
•    มีความยืดหยุ่น: การออกแบบฐานข้อมูลให้มีความยืดหยุ่นจะช่วยบรรเทาผลกระทบหากมีการเปลี่ยนแปลงโครงสร้างฐานข้อมูล

 

4.3. หลักการออกแบบฐานข้อมูล

หลักการออกแบบฐานข้อมูลมีขั้นตอนต่างๆ ดังต่อไปนี้

•    วิเคราะห์ความต้องการ: เป็นขั้นตอนรวบรวมข้อมูลว่าฐานข้อมูลต้องมีคุณสมบัติอย่างไรบ้าง ผู้ใช้งานต้องการเก็บข้อมูลอะไร และคาดหวังว่าจะได้ผลลัพธ์อย่างไรบ้าง สิ่งที่ต้องทำคือจดบันทึกความต้องการต่างๆ ไว้ ขณะที่พูดคุยกับผู้ใช้ในระดับต่างๆ
•    การออกแบบทางแนวคิด: เป็นขั้นตอนออกแบบในกระดาษหรือใช้เครื่องมือที่เป็นซอฟต์แวร์ช่วยออกแบบเพื่อร่างแผนภูมิต่างๆ เช่นแผนภูมิ ERD เพื่อออกแบบโครงสร้างของตาราง คอลัมน์ และความเชื่อมโยงระหว่างตาราง การทำนอร์มัลไลซ์ก็ควรจะอยู่ในขั้นตอนนี้ด้วย

 

ภาพ 4-2 : ตัวอย่างแผนภูมิ ERD ของฐานข้อมูลร้านขายหนังสือในอินเตอร์เน็ตแห่งหนึ่ง

 

•    การออกแบบทางตรรกะ: เขียนคิวรี DDL (Data definition Language) เพื่อสร้างตารางต่างๆ ในฐานข้อมูล เครื่องมือสร้างแผนภูมิ ERD บางตัวอาจให้ DDL ได้โดยอัตโนมัติแต่เป็นเพียงคิวรีทั่วๆ ไป หากจะนำมาใช้ควรตรวจสอบให้ดีก่อน
•    การออกแบบทางกายภาพ: ปรับแก้คิวรีเพื่อสนับสนุนลักษณะทางกายภาพบางอย่าง เช่นพิจารณาว่าจำเป็นจะต้องต้องการเก็บออพเจ็กต์ที่เป็นไบนารีขนาดใหญ่ไว้เป็นไฟล์แยกต่างหากจากตารางมาตรฐานหรือไม่
•    การปรับแต่ง: ประกอบด้วยกระบวนการหลายอย่าง เช่นเพิ่มหรือลดระดับความเข้มข้นของการนอร์มัลไลซ์ การทำดรรชนี การจัดทำทริกเกอร์ การเพิ่มระบบรักษาความปลอดภัย หรืออะไรก็ตามที่ยังไม่ได้ทำในขึ้นตอนก่อนหน้านี้

ขั้นตอนเหล่านี้เป็นเพียงแนวทางโดยทั่วไป ท่านอาจสลับขั้นตอน ทำซ้ำ หรือนำขั้นตอนบางขั้นตอนหรือทั้งหมดมารวมกัน แล้วแบ่งแยกใหม่อย่างไรก็ได้ตามใจชอบ แต่สิ่งสำคัญที่ผู้เขียนขอแนะนำคือให้ออกแบบในกระดาษ (หรือใช้ซอฟต์แวร์) เขียนแผนภูมิ ERD ก่อนเขียนคิวรี DDL เสมอ เพื่อให้เห็นโครงสร้างในภาพรวมก่อนลงมือสร้างฐานข้อมูลจริงๆ

 

การประยุกต์ใช้งานฐานข้อมูล : ตอน 2

 

   Home Page  |   รายการบทความ   |   ลิงค์ที่เกี่ยวข้อง   |   laploy.com  |  เกี่ยวกับผู้เขียน

 

การประยุกต์ใช้งานฐานข้อมูล : ตอน 2

 

3.5. การประมวลผลแบบขนาน
ปัจจุบันนี้ถ้าเราไปพันทิพย์เพื่อซื้อคอมพิวเตอร์ธรรมดาๆ เราจะได้คอมพิวเตอร์ที่มีตัวประมวลผลแบบมีแกนในสองแกน (dual-core)  เครื่องเล่นเกมอย่างเพลย์สเตชันสาม (PlayStaton 3) มีตัวประมวลผลขนาด 64 บิตแบบแปดแกน ในไม่ช้าตัวประมวลผลที่มีแกนหลักจำนวน 16 หรือ 32 แกนก็จะกลายเป็นเรื่องธรรมดา การมีตัวประมวลผลหลายแกนทำให้เราสามารถใช้งานโปรแกรมประยุกต์ที่ทำงานแบบคู่ขนาน (concurrent) ได้

หลักการทำงานของฐานข้อมูลสัมพันธ์เอื้ออำนวยต่อการทำงานงานแบบคู่ขนาน เพราะแบบจำลองข้อมูลสัมพันธ์ตั้งอยู่บนพื้นฐานของเซต กฎของเซต (จำกัด) กล่าวว่า "ผลรวมของการทำยูเนียนกับส่วนต่างๆ ทั้งหมดย่อมเท่ากับเซตเดิม" แสดงเป็นสัญลักษณ์ได้ดังนี้

นิยามการแบ่งส่วนของเซต A

ยูเนียนส่วนต่างๆ ทั้งหมดของเซต A

นั่นหมายความว่าการกระทำต่างๆ กับแถวของตารางเราสามารถทำได้อย่างคู่ขนาน คือสามารถทำได้กับทุกแถวไปพร้อมๆ กันโดยไม่จำเป็นต้องไล่ตั้งแต่แถวแรกไปถึงแถวสุดท้าย แสดงเป็นสัญลักษณ์ได้ดังนี้

ไม่มีอะไรจะทำงานได้เร็วไปกว่าการทำงานแบบคู่ขนาน ในอนาคตอันใกล้นี้เมื่อระบบปฏิบัติการและโปรแกรม RDBMS ยุคใหม่สนับสนุนการทำงานแบบคู่ขนาน การคิวรีข้อมูลปริมาณมากๆ จะทำได้รวดเร็วขึ้นกว่าปัจจุบันนี้หลายเท่าตัว

ภาพ 3-4: เครื่องเล่นเกมเพลย์สเตชันสามเป็นคอมพิวเตอร์ที่ใช้ตัวประมวลผลแบบคู่ขนาน

 

3.6. แรมราคาถูกลง
หน่วยความจำหลักหรือแรม (Random Access Memory ย่อ RAM) นับวันยิ่งมีความจุมากขึ้นและมีราคาต่ำลง  คอมพิวเตอร์ที่ผู้เขียนเคยใช้ตอนเริ่มหัดเขียนโปรแกรมมีแรมเพียง 2KB (สองพันไบต์) เท่านั้น แต่ในปัจจุบันเป็นเรื่องปรกติที่เราจะมีคอมพิวเตอร์ที่มีแรมจำนวน 2 หรือ 4GB (GB = พันล้านไบต์)  นั่นแปลว่าคอมพิวเตอร์ที่ผู้เขียนใช้ในปัจจุบันนี้มีแรมมากกว่าคอมพิวเตอร์ที่ผู้เขียนเคยใช้ตอนเริ่มหัดเขียนโปรแกรมถึงหนึ่งล้านเท่า และมากกว่าเครื่องเมนเฟรมในอดีตหลายแสนเท่า

 

ภาพ 3-5: MPF-1 คอมพิวเตอร์ที่ผู้เขียนใช้ตอนเริ่มหัดเขียนโปรแกรมในปี ค.ศ. 1984 มีแรมเพียง 2KB (ผู้เขียนซื้อคอมพิวเตอร์นี้จากร้านค้าใกล้บ้านหม้อ MPF-1 ผลิตโดยบริษัท มัลติเทค ที่ปัจจุบันเปลี่ยนชื่อเป็นเอเซอร์ เป็นเครื่องมือสำหรับฝึกเขียนโปรแกรมภาษาเครื่อง (machine language) ของซีพียู Z80)

นอกจากแรมแล้ว จานบันทึกข้อมูลก็มีความจุสูงขึ้นแต่มีราคาต่ำลงเช่นกัน แผ่นบันทึกข้อมูล "ฟล็อปปิดิสก์" ขนาดห้านิ้วครึ่งความจุ 360KB ถูกแทนที่ด้วยฟล็อปปิดิสก์ขนาดสามนิ้วครึ่ง ความจุ 1.44MB ต่อมาเป็น DVD-ROM ความจุ 4.7GB และปัจจุบันเป็นแผ่นดิสก์แบบบลูเรย์ (Blue-ray) ซึ่งมีความจุสูงถึง 50GB

 

3.7. โซลิดสเตทดิสก์
โซลิดสเตทดิสก์ (Solid-State Disk) หรือฮาร์ดดิสก์ที่ทำจากสารกึ่งตัวนำ ไม่มีแผ่นจานแม่เหล็ก ไม่มีชิ้นส่วนที่เคลื่อนไหว จึงทำงานเงียบ กินกำลังไฟฟ้าน้อย และที่สำคัญคือทำงานเร็วกว่าฮาร์ดดิสก์ที่ทำจากแผ่นจานแม่เหล็กมาก มีทั้งแบบที่ทำจากแรม (ปิดไฟแล้วข้อมูลหาย) และแบบที่ทำจากแฟลช (ปิดไฟแล้วข้อมูลไม่หาย)  แต่มีข้อเสียคือเทียบราคาต่อความจุยังแพงกว่าฮาร์ดดิสก์ที่ทำจากแผ่นจานแม่เหล็กมาก แต่เชื่อว่าในอีกไม่ช้าจะมีราคาใกล้เคียงกันและจะมาแทนที่ฮาร์ดดิสก์ไปในที่สุด

ภาพ 3-6: โซลิดสเตทดิสก์มีความจุมากขึ้นแต่มีราคาต่ำลงเรื่อยๆ

3.8. ฮาร์ดดิสก์สมัยใหม่
ฮาร์ดดิสก์ (Hard disk drive ย่อ HDD) เป็นแผ่นจานแม่เหล็กที่ถูกประดิษฐ์คิดค้นโดยไอบีเอ็มตั้งแต่ปี ค.ศ. 1956 ปัจจุบันนี้ก็ยังไม่ตาย แต่มีราคาถูกลงและมีความจุมากขึ้น HDD ตามศูนย์ข้อมูล (Data center) หรือที่เครื่องแม่ข่ายให้บริการฐานข้อมูล (Database Server) เดิมจะใช้อินเตอร์เฟสแบบ SCSI (สแกซซี่)  ต่อพ่วง HDD ธรรมดาราคาไม่แพงเข้าด้วยกันหลายๆ ตัวเป็นแถว (Redundant Array of Inexpensive Disks ย่อ RAID) เพื่อเพิ่มความจุหรือเพิ่มความเชื่อถือได้ (หรือเล็งผลเลิศทั้งสองอย่าง)

ในสมัยก่อนหากต้องการสร้างคลังข้อมูลที่มีความจุระดับเทราไบต์ (Terabyte ย่อ TB) หรือล้านล้านไบต์ (1,000 ยกกำลัง 4 หรือ 10 ยกกำลัง 2) จำเป็นต้องใช้แถบแม่เหล็กหรืออุปกรณ์บันทึกข้อมูลด้วยแสงเป็นจำนวนมาก สลับสับเปลี่ยน (mount และ dismount) โดยอัตโนมัติด้วยน้ำมือของหุ่นยนต์ที่คล่องแคล่ว หรือจัดทำเป็นเซอฟเวอร์ฟาร์ม (Server Farm) ที่มีดิสก์ไซโล (Disks Silo) อยู่จำนวนมาก  แต่ตอนนี้หมดสมัยแล้ว เพราะในปัจจุบันแค่ HDD ธรรมดาราคาถูกก็มีความจุในระดับ TB ทำให้การจัดตั้งเครื่องแม่ข่ายให้บริการฐานข้อมูลทำได้งายขึ้น และมีราคาลดลง

ภาพ 3-7: โฆษณาขายฮาร์ดดิสก์ของบริษัท นอร์ทสตาร์ คอมพิวเตอร์ ในปี 1980 ความจุ 18MB รุ่นฮอร์ไรซอนราคาตัวละสามแสนบาท

 

3.9. เมื่อข้อมูลเปลี่ยนไป
ความก้าวหน้าทางเทคโนโลยีที่กล่าวถึงในหัวข้อต่างๆ ข้างบนทำให้ชวนคิดไปว่าการเก็บข้อมูลไม่ใช่ปัญหาอีกต่อไป นั่นคือเราไม่จำเป็นต้องออกแบบฐานข้อมูลโดยทำการลดทอนอย่างละเอียดรอบคอบเหมือนยุคก่อน เนื่องจากการเก็บข้อมูลซ้ำซ้อนหรือปล่อยให้คอลัมน์ส่วนใหญ่ว่างหรือเป็น NULL ไม่นับว่าเป็นเรื่องสำคัญ เพราะอุปกรณ์เก็บข้อมูลมีราคาถูกและมีความจุเหลือเฟือ และยังไม่จำเป็นต้องระวังเรื่องการใช้ทรัพยากรอื่นๆ เช่นกำลังการประมวลผลของซีพียู เพราะคอมพิวเตอร์สมัยใหม่มีตัวประมวลผลที่มีประสิทธิภาพสูงหลายตัว หรือมีซีพียูตัวเดียวแต่มีแกนในหลายแกน

ความคิดในย่อหน้าบนไม่เป็นความจริงเสมอไป เพราะขณะที่อุปกรณ์เก็บข้อมูลมีความจุเพิ่มขึ้น ขนาดของข้อมูลที่เราต้องการเก็บก็เพิ่มขึ้นเช่นกัน การใช้คอมพิวเตอร์ก่อนหน้านี้เน้นเก็บข้อความตัวอักษรและรูปภาพซึ่งกินเนื้อที่ไม่มาก แต่ปัจจุบันนี้เราเก็บข้อมูลเสียง (ไฟล์ MP3) หรือวิดีโอ (ไฟล์ .AVI, MP4, WMA และอื่นๆ)  และมีการประยุกต์ใช้งานใหม่ๆ ที่เพิ่มขนาดของข้อมูลอีกมาก เช่นโปรแกรมจดจำใบหน้าเพื่อการอ่านความรู้สึกและอารมณ์จากสีหน้า โปรแกรมจดจำลายนิ้วมือ โปรแกรมจดจำเส้นลายในดวงตาเพื่อแยกแยะความแตกต่างของบุคคล ข้อมูลแผนที่ๆ ทำงานร่วมกับดาวเทียม GPRS ข้อมูลเทียบ DNA ฯลฯ การประยุกต์ใช้งานใหม่เหล่านี้ล้วนต้องใช้พื้นที่เก็บข้อมูลขนาดใหญ่

 

ภาพ 3-8: ลักษณะของข้อมูลเปลี่ยนไป ข้อมูลสมัยใหม่มีขนาดใหญ่ขึ้นและซับซ้อนขึ้น ตัวอย่างเช่นในภาพนี้ เว็บไซต์ YouTube จัดเก็บคลิปวิดีโอที่สมาชิกส่งมาไว้เป็นฐานข้อมูลขนาดใหญ่

 

3.10. แต่ความคิดยังไม่เปลี่ยน
ยังมีสถาปนิก นักออกแบบฐานข้อมูลและนักเขียนโค้ดอยู่เป็นจำนวนมากที่แม้จะรู้ว่าอุปกรณ์บันทึกข้อมูลมีความจุสูงและมีราคาถูก แต่ยังติดนิสัยหรือยังมีความคิดในการบีบฐานข้อมูลให้เล็กที่สุดเหมือนสมัยที่อุปกรณ์บันทึกข้อมูลมีความจุน้อยและมีราคาแพง ในปัจจุบันการออกแบบฐานข้อมูลโดยเน้นประหยัดเนื้อที่ในอุปกรณ์บันทึกข้อมูล อาจไม่ใช่ทางเลือกที่ดีเสมอไป  เพราะการมุ่งเน้นประหยัดเนื้อที่อาจทำให้คิวรีซับซ้อน ใช้เวลาเขียนและบำรุงรักษามาก ซึ่งอาจไม่คุ้มกับเวลาและเงินที่ต้องใช้เพื่อเขียนและบำรุงรักษาคิวรีที่อาจสูงกว่าราคาของอุปกรณ์บันทึกข้อมูล

 

3.11. สรุปท้ายบท
ฐานข้อมูลมีหลายแบบที่ต้องเลือกใช้ให้เหมาะกับงาน เช่นฐานข้อมูลเพื่อใช้ในงาน OLTP ย่อมไม่เหมาะกับการนำมาใช้เพื่อการวิเคราะห์และทำรายงาน ความนิยมในการใช้งานเว็บแอพลิเกชันทำให้มีผู้ใช้ฐานข้อมูลทั่วโลกเพิ่มขึ้นเป็นจำนวนมากอยู่ตลอดเวลา การออกแบบฐานข้อมูลที่รองรับการใช้งานที่มีโหลดสูงได้จึงเป็นสิ่งจำเป็น

แม้อุปกรณ์ฮาร์ดแวร์จะมีราคาถูกลง มีประสิทธิภาพและความจุสูงขึ้น อาจทำให้การออกแบบฐานข้อมูลที่มุ่งเน้นการลดทอนอย่างถึงที่สุดเหมือนในอดีตไม่เหมาะกับปัจจุบัน แต่ธรรมชาติของข้อมูลก็เปลี่ยนไปด้วยเช่นกัน ข้อมูลสมัยใหม่มีขนาดใหญ่ขึ้นและซับซ้อนขึ้น ผู้ออกแบบฐานข้อมูลจึงยังจำเป็นต้องมีความรู้และความเข้าใจเรื่องการลดทอนข้อมูล ท่านจะได้เรียนเรื่องการลดทอนข้อมูลในบทที่ 5 และ 6 ในบทต่อไปท่านจะได้เรียนเรื่องพื้นฐานของการออกแบบฐานข้อมูลเพื่อการสร้างฐานข้อมูลที่มีประสิทธิภาพ

 

3.12. คำถามท้ายบท

1.    การใช้งานฐานข้อมูลแบบไคลแอนเซอฟเวอร์เป็นอย่างไร
2.    คลังข้อมูลคืออะไรมีหน้าที่อย่างไร
3.    ฐานข้อมูลแบบผสมผสานคืออะไร
4.    data bandwidth คืออะไร
5.    RAID คืออะไร
6.    การบีบฐานข้อมูลให้เล็กที่สุดมีข้อเสียอย่างไร
7.    ธรรมชาติของข้อมูลในปัจจุบันต่างจากในอดีตอย่างไร
8.    Solid-State Disk คืออะไร
9.    กฎของเซต (จำกัด) กล่าวว่าอย่างไร หมายความว่าอย่างไร

 

3.13. แบบฝึกหัดท้ายบท
จงเขียนคิวรีภาษา T-SQL เพื่อฉายแสดงข้อมูลในตาราง Employees ในฐานข้อมูล NorthWind โดยแสดงเฉพาะคอลัมน์ EmployeeID, LastName, FirstName, Title และ TitleOfCourtesy โดยให้แสดง 3 แบบดังนี้

1.    เซตของผู้ที่มี  TitleOfCourtesy = ‘Ms.’
2.    เซตของผู้ที่มี  TitleOfCourtesy = ‘Mr.’
3.    ผลจากการ UNION ALL ของทั้งสองเซต

 

การประยุกต์ใช้งานฐานข้อมูล : ตอน 1

 

   Home Page  |   รายการบทความ   |   ลิงค์ที่เกี่ยวข้อง   |   laploy.com  |  เกี่ยวกับผู้เขียน

 

การประยุกต์ใช้งานฐานข้อมูล : ตอน 1

 

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

หัวข้อที่ผ่านมาท่านได้เรียนลักษณะของแบบจำลองฐานข้อมูลชนิดต่างๆ ไปแล้ว ในบทนี้ท่านจะได้เรียนข้อควรคำนึงต่างๆ ในการประยุกต์ใช้งานฐานข้อมูล ซึ่งมีหัวข้อดังนี้

•    ฐานข้อมูลในงานธุรกรรม (OLTP)
•    ฐานข้อมูลในงานช่วยตัดสินใจ (OLAP)
•    ฐานข้อมูลแบบผสมผสาน
•    มุมมองใหม่ต่อฐานข้อมูล
•    การประมวลผลแบบขนาน
•    แรมราคาถูกลง
•    โซลิดสเตทดิสก์
•    ฮาร์ดดิสก์สมัยใหม่
•    เมื่อข้อมูลเปลี่ยนไป
•    แต่ความคิดยังไม่เปลี่ยน

 

3.1. ฐานข้อมูลในงานธุรกรรม (OLTP)
ฐานข้อมูลในงานธุรกรรมเป็นงานที่เข้าถึงข้อมูลหรือเปลี่ยนแปลงข้อมูลในปริมาณน้อย (คือครั้งละหนึ่งหรือสองแถว) งานส่วนมากคือการเรียกข้อมูลมาดู เพิ่มข้อมูล เปลี่ยนแปลงข้อมูล ลบข้อมูล โดยเป็นการทำครั้งละหนึ่งแถว เช่นข้อมูลของลูกค้าหนึ่งราย หรือสินค้าหนึ่งรายการ ยกตัวอย่างการใช้งานฐานข้อมูลในงานธุรกรรมมีดังนี้

•    ฐานข้อมูลแบบไคลแอนเซอฟเวอร์: การใช้งานในสภาพแวดล้อมแบบไคลแอนเซอฟเวอร์เป็นแบบที่นิยมกันมากก่อนยุคอินเตอร์เน็ตเฟื่องฟู มักเป็นการใช้งานภายในองค์กร จำนวนผู้ใช้ขึ้นอยู่กับขนาดขององค์กร อาจมีผู้ใช้เพียงคนเดียวถึงหลายพันคน การทำธุรกรรมจะเกี่ยวข้องกับข้อมูลครั้งและเพียงแถวเดียว หรือเรคคอร์ดเดียว หรือไม่ก็ดึงข้อมูลเป็นชุดเพื่อการทำรายงาน ฐานข้อมูลแบบไคลแอนเซอฟเวอร์ไม่จำเป็นต้องรองรับปริมาณการไหลของข้อมูลสูงมากนัก เพราะจำนวนผู้ใช้จะถูกจำกัดไว้ในปริมาณที่เหมาะสม ยกตัวอย่างเช่นหน่วยงานที่มีผู้ใช้หนึ่งพันคนโอกาสที่ผู้ใช้จะดึงข้อมูลจากฐานข้อมูลในขณะเดียวกันมีน้อยมาก

•    ฐานข้อมูลแบบ OLTP: เป็นฐานข้อมูลที่ใช้ร่วมกับอินเตอร์เน็ตแอพลิเกชัน ปริมาณผู้ใช้ที่เรียกใช้ฐานข้อมูลพร้อมๆ กันจะสูงกว่าฐานข้อมูลแบบไคลแอนเซอฟเวอร์มาก ฐานข้อมูลแบบ OLTP จึงจำเป็นต้องรองรับปริมาณการไหลของข้อมูลสูงกว่า งานลักษณะนี้จะมีผู้ใช้นับล้านคนใช้งานวันละยี่สิบสี่ชั่วโมงปีละสามร้อยหกสิบห้าวัน ทำให้อาจมีผู้ใช้นับพันดึงข้อมูลจากฐานข้อมูลพร้อมๆ กันได้ตลอดเวลา

 

ภาพ 3-1 : สถาปัตยกรรมแบบไคลแอนเซอฟเวอร์

 

3.2. ฐานข้อมูลเพื่อช่วยตัดสินใจ (OLAP)
ฐานข้อมูลในงานช่วยตัดสินใจมีหน้าที่เหมือนชื่อของมัน คือช่วยให้ผู้จัดการหรือเจ้าหน้าที่ในระดับบริหารมีข้อมูลสำหรับใช้ตัดสินใจดำเนินการในเรื่องต่างๆ ยกตัวอย่างการใช้งานฐานข้อมูลในงานช่วยตัดสินใจมีดังนี้

•    ฐานข้อมูลแบบโกดังข้อมูล: โกดังข้อมูล (data warehouse) มีแบบจำลองเหมือนกับฐานข้อมูลในงานธุรกรรม จะแปลกกันที่งานโกดังข้อมูลมักเก็บข้อมูลประวัติย้อนหลังไปหลายปีเพื่อใช้ในการทำนายแนวโน้ม ขณะที่งานธุรกรรมจะเก็บเฉพาะข้อมูลปัจจุบัน ดังนั้นฐานข้อมูลแบบโกดังข้อมูลจะมีขนาดใหญ่กว่าฐานข้อมูลในงานธุรกรรมหลายเท่า (บางครั้งใหญ่กว่าเป็นล้านเท่า) ข้อมูลที่อยู่ในโกดังข้อมูลมักเป็นข้อมูลที่รวบรวมมาจากฐานข้อมูลแบบ OLTP (คือย้ายข้อมูลมาจาก OLTP แล้วจึงลบข้อมูลใน OLTP ไปเสีย) โกดังข้อมูลต้องการแบบจำลองข้อมูลที่ถูกออกแบบมาเพื่อการนี้โดยเฉพาะ
•    ฐานข้อมูลแบบคลังข้อมูล: คลังข้อมูล (data mart) คล้ายโกดังข้อมูลแต่มีขนาดเล็กกว่ามาก มีหน้าที่ใช้พักข้อมูลชั่วคราวเพื่อการประมวลผลก่อนนำไปสร้างโกดังข้อมูล คลังข้อมูลจะมีแบบจำลองเหมือนกันกับโกดังข้อมูล
•    ฐานข้อมูลรายงาน: ฐานข้อมูลรายงานมีลักษณะเช่นเดียวกับโกดังข้อมูลแต่มีขนาดเล็กกว่า ฐานข้อมูลรายงานจะมีเฉพาะข้อมูลที่จำเป็นต้องใช้ในการทำรายงาน ขณะที่โกดังข้อมูลมีข้อมูลเก่าย้อนหลังไปนาน (archived data) สาเหตุที่ต้องมีฐานข้อมูลรายงานไม่ทำรายงานจากโกดังข้อมูลโดยตรงเพราะโกดังข้อมูลมีขนาดใหญ่เทอะทะไม่ยืดหยุ่น จึงใช้ทำรายงานได้ไม่สะดวก

ภาพ : 3-2 : ตัวอย่างระบบงานโกดังข้อมูลหรือดาต้าแวร์เฮาส์ใช้งานผ่านเว็บ

 

3.3. ฐานข้อมูลแบบผสมผสาน
ฐานข้อมูลแบบผสมผสาน (Hybrid Database ย่อ HD) คือการผสมความต้องการระหว่างฐานข้อมูลในงานธุรกรรมและฐานข้อมูลในงานช่วยตัดสินใจเอาไว้ด้วยกัน จุดมุ่งหมายของ HD คือต้องการลดค่าใช้จ่าย เพราะ HD จะมีเพียงฐานข้อมูลเดียว ใช้เซอฟเวอร์เพียงตัวเดียว จึงประหยัดค่าฮาร์ดแวร์ ซอฟต์แวร์ และรายจ่ายอื่นๆ ในการบำรุงรักษา  HD จึงเหมาะสำหรับงานที่มีปริมาณการไหลของข้อมูลต่ำและมีจำนวนผู้ใช้ไม่มากนัก

 

3.4. มุมมองใหม่ต่อฐานข้อมูล
ความก้าวหน้าทางฮาร์ดแวร์ที่เกิดขึ้นอยู่ตลอดเวลาทำให้คอมพิวเตอร์ที่เราใช้ทำฐานข้อมูลในปัจจุบันนี้แตกต่างจากสมัยที่ผู้เขียนสร้างฐานข้อมูลด้วยโปรแกรมดีเบสทู (dBase II) กฎของมัวร์บอกเราว่าตัวประมวลผลจะมีความเร็วเพิ่มเป็นสองเท่าในทุกๆ สิบแปดเดือน แต่ความก้าวหน้าทางฮาร์ดแวร์ไม่ได้จำกัดอยู่เฉพาะกับตัวประมวลผลเท่านั้น อุปกรณ์รอบข้างต่างๆ เช่นหน่วยบักทึกข้อมูลก็มีความจุมากกว่าเดิม และมีราคาถูกลงอย่างรวดเร็ว

เมื่อไม่กี่ปีมานี้เคยมีปัญหาใหญ่เรื่องแถบความกว้างในการไหลของข้อมูล (data bandwidth) ที่ใช้เพื่อรับ-ส่งข้อมูลระหว่างหน่วยความจำแรมกับฮาร์ดดิสก์มีขนาดเล็กและมีความเร็วต่ำ เปรียบเหมือนมีบ่อน้ำขนาดยักษ์แต่ท่อส่งน้ำมีขนาดเล็กจิ๋ว แต่ตอนนี้ปัญหาหมดไปแล้วเพราะฮาร์ดดิสก์รุ่นใหม่มีความเร็วสูงมาก

 

ภาพ 3-3 : โปรแกรมดีเบสทูเป็นโปรแกรมจัดการฐานข้อมูลเคยได้รับความนิยมอย่างสูง แต่มันไม่ใช่ RDBMS และไม่สนับสนุนภาษา SQL

 

แบบจำลองฐานข้อมูล: ตอน 4

 

 
Home Page  |   รายการบทความ   |   ลิงค์ที่เกี่ยวข้อง   |   laploy.com  |  เกี่ยวกับผู้เขียน

 

แบบจำลองฐานข้อมูล: ตอน 4

 

 2.7.6. แบบจำลองฐานข้อมูลแบบวัตถุสัมพันธ์
แบบจำลองฐานข้อมูลแบบวัตถุสัมพันธ์ (Object-Relational Database Model ย่อ ORDM) เป็นแบบจำลองใหม่สุดที่นำข้อดีของ RDM และ ODM มารวมกัน ปรากฏขึ้นครั้งแรกในปี 1990 และยังได้รับการพัฒนาอยู่อย่างต่อเนื่อง  ข้อดีของแบบจำลอง  ORDM คือสามารถเขียนคิวรีได้แบบเดียวกับ RDM ข้อเสียคือความซับซ้อนของมัน

อย่างที่เรียนไปแล้ว่า ODM มีข้อดีที่เป็นสามมิติทำให้เข้าถึงข้อมูลได้รวดเร็วมาก ไม่ว่าข้อมูลนั้นจะอยู่ที่ส่วนไหนของฐานข้อมูลก็ตาม แต่มีข้อเสียที่ข้อมูลต้องเป็นชิ้นเล็กๆ เช่นแถวเดียว ถ้ามากกว่านั้น ODM จะทำงานช้าอย่างยิ่งยวด  ส่วน RDM เป็นสองมิติทำให้การเข้าถึงข้อมูลทำได้เร็วไม่ว่าจะเป็นข้อมูลแค่ทูเพิลเดียวหรือเป็นพันๆ ทูเพิล  RDM จึงเหมาะสุดเมื่อนำมาใช้กับข้อมูลก้อนโต แบบจำลอง  ORDM  ถูกพัฒนาขึ้นเพื่อกำจัดจุดอ่อนและผนวกข้อดีของทั้ง ODM และ  RDM เข้าไว้ด้วยกัน

อันที่จริงโปรแกรม RDBMS รุ่นใหม่ๆ จะมีคุณสมบัติบางอย่างของ ODM อยู่ในระดับหนึ่ง เช่นสามารถเก็บออพเจ็กต์แบบไบนารีได้ สามารถใส่เมธอดให้แก่ออพเจ็กต์ได้ ปัญหาหลักของการเก็บออพเจ็กต์แบบไบนารีใน RDM คือต้องเก็บออพเจ็กต์ใหญ่ๆ ไว้เป็นโครงสร้างย่อหรือตารางที่มีฟิลด์เดียวแยกไว้ต่างหาก แต่ก็มีบาง RDBMS ที่เก็บออพเจ็กต์ใหญ่ๆ ไว้นอกตาราง คือเก็บเป็นแฟ้มภายนอกได้ด้วย

 

2.7.7. แบบจำลองฐานข้อมูลวัตถุวิธี
แบบจำลองฐานข้อมูลวัตถุวิธี (Object Oriented Database Model ย่อ OODM) เป็นการผนวกข้อมูลและส่วนโค้ดที่จัดการมันไว้เป็นก้อนเดียวกัน (เหมือนออพเจ็กต์ในวิชา OOP) โปรแกรม DBMS ที่สนับสนุน OODM จะเรียกย่อว่า ODBMS (object database management system)โปรแกรม ODBMS ช่วยให้นักเขียนโค้ดใช้ภาษา OOP อย่าง C# จัดการฐานข้อมูลได้เหมือนเป็นออพเจ็กต์หนึ่ง

OODM ถูกพัฒนาขึ้นในปี 1985 โดยนักวิชาการหลายกลุ่มเช่นนักวิจัยที่มหาวิทยาลัย บราวน์ และ เอ็มไอที ช่วงแรก OODM จะใช้งานร่วมกับภาษา OOP เดิมอย่าง Smalltalk และ LISP ภายหลังปี 1990 เริ่มมี OODM ที่ใช้งานกับภาษาจาวา และปัจจุบันกำลังนิยมใช้กับภาษา C#

 

ภาพ 2-13 : มหาวิทยาลัย บราวน์ ซึ่งเป็นหนึ่งในต้นกำเนิดแบบจำลองฐานข้อมูลแบบวัตถุวิธี

 

เดิมทีภาษาคิวรีสำหรับ OODM เรียกว่าภาษา OQL (Object Query Language) มีหลายแบบ จนกระทั่งในปี 2005 คุก ไร และโรเซนเบอร์เกอร์ได้กำหนดมาตรฐานให้แก่ภาษา OQL เรียกว่าเนทีฟคิวรี (Native Queries) ซึ่งเป็นคิวรีแบบไทป์เซฟผนวกไว้ในภาษาจาวาและ C# ต่อมาในปี 2007 บริษัทไมโครซอฟต์ออก .NET Framework เวอร์ชัน 3.5 ซึ่งผนวกภาษา LINQ (อ่านว่าลิงค์ ย่อจาก Language Integrated Query) เพื่อให้นักเขียนโค้ดสามารถเขียนคิวรีไว้ภายในภาษา C# ได้โดยตรง (ดูบทที่ 31)

OODM เหมะกับงานฐานข้อมูลที่ซับซ้อนมากๆ มีผู้ทำการทดลองเพื่อวัดประสิทธิภาพระหว่าง RDM และ OODM พบ OODM มีประสิทธิภาพเหนือกว่า RDM ในงานบางอย่าง แต่ข้อเสียของ OODM ก็มีหลายอย่าง เช่น ไม่สามารถนำมาใช้ร่วมกับเครื่องมือต่างๆ ที่เป็นมาตรฐานเช่นเครื่องมือ OLAP เครื่องมือสำหรับการทำสำรองข้อมูล และการกู้ข้อมูล นอกจากนั้น OODM (และ OQL) ยังขาดพื้นฐานของหลักการพีชคณิตและแคลคูลัสสัมพันธ์ที่มีใน RDM ด้วยสาเหตุนี้ทำให้หลายๆ ฝ่ายมองว่า OODM ไม่เหมาะกับการนำมาใช้งานจริงเพราะยังไม่สมบูรณ์และมีสิ่งที่ต้องพัฒนาอีกมาก

 

2.8. สรุปท้ายบท
คอมพิวเตอร์เตอร์ย่อมมีประโยชน์น้อยหากขาดข้อมูลเพื่อใช้ประมวลผล การคิดค้นสร้างแบบจำลองฐานข้อมูลจึงเกิดขึ้นพร้อมๆ กับวิทยาการคอมพิวเตอร์ แบบจำลองฐานข้อมูลถูกพัฒนามาแล้ว 7 ยุคสมัย คือ Flat File, HDM, NDM, RDM, ODM, ORDM และ OORDM แบบจำลองสามแบบแรกหมดความนิยมใช้งานไปแล้ว ส่วนแบบจำลองที่เหลือยังมีใช้งานกันอยู่ครบทั้งสี่แบบ

บทที่เหลือของหนังสือนี้ผู้เขียนจะเน้นเฉพาะ RMD เท่านั้นเพราะเป็นแบบจำลองที่ได้รับความนิยมมากที่สุด และแบบจำลองประเภทอื่นๆ อยู่นอกเหนือขอบเขตของหนังสือเล่มนี้ โดยในบทต่อไปท่านจะได้เรียนวิธีประยุกต์ใช้งานแบบจำลองนี้

 

2.9. คำถามท้ายบท
1.    แอพลิเกชันคืออะไร
2.    ในเรื่องฐานข้อมูลคำว่าโปร่งใสหมายถึงอะไร
3.    OLTP คืออะไร
4.    ดาต้าแวร์เฮาส์ คืออะไร
5.    วิววัตถุคืออะไร
6.    ชนิดข้อมูลพื้นฐานประกอบด้วยอะไรบ้าง
7.    พอยน์เตอร์คืออะไร
8.    RDBMS คืออะไร
9.    แฟ้มแบบ CSV คืออะไร
10.    จงบอกข้อดีและข้อเสียของแบบจำลองฐานข้อมูลแบบลำดับชั้น
11.    ข้อดีคือการเพิ่มลดระเบียน (record) ทำได้ง่ายมาก ข้อเสียคือการค้นหาข้อมูลทำได้ช้าเพราะต้องไล่ไปตามลำดับชั้น
12.    จงบอกข้อดีและข้อเสียของแบบจำลองฐานข้อมูลสัมพันธ์

 

2.10. แบบฝึกหัดท้ายบท
จงเขียนคิวรีภาษา T-SQL เพื่อฉายแสดงข้อมูลทุกแถวในตาราง Employees ในฐานข้อมูล NorthWind โดยแสดงเฉพาะคอลัมน์ EmployeeID, LastName, FirstName, Title และ TitleOfCourtesy

 

แบบจำลองฐานข้อมูล: ตอน 3

 

 
Home Page  |   รายการบทความ   |   ลิงค์ที่เกี่ยวข้อง   |   laploy.com  |  เกี่ยวกับผู้เขียน

 

แบบจำลองฐานข้อมูล: ตอน 3

 

2.7. วิวัฒน์ของแบบจำลองฐานข้อมูล
การพัฒนาแบบจำลองข้อมูลเริ่มขึ้นตั้งแต่เริ่มมีการสร้างคอมพิวเตอร์ในปี ค.ศ. 1940 ช่วงแรกเป็นแบบจำลองข้อมูลที่เก็บข้อมูลเป็นไฟล์แบบเครือข่าย (network database model) แบบจำลองข้อมูลที่เก็บข้อมูลเป็นไฟล์แบบลำดับชั้น (hierarchical database model) ซึ่งทั้งสองแบบเป็นแบบจำลองที่ไม่สู้มีประสิทธิภาพนัก ต่อมาในช่วงปี 1960 จึงมีการคิดแบบจำลองข้อมูลสัมพันธ์ (relational database model) ที่ใช้งานได้จริงจัง และถือว่าเป็นแบบที่มีประสิทธิภาพสูงสุด และนิยมใช้กันมาจนถึงทุกวันนี้

 

ภาพ 2-6 : วิวัฒนาการของแบบจำลองข้อมูล

 

2.7.1. แบบจำลองฐานข้อมูลแบบ File System
แบบจำลองฐานข้อมูลแบบ File Systems เป็นแบบจำลองฐานข้อมูลที่โบราญสุด ปรากฏตัวขึ้นตั้งแต่เริ่มมีคอมพิวเตอร์คือก่อนปี 1950 และถูกใช้เรื่อยมาจนเสื่อมความนิยมไปในปี 1970 ข้อดีของ File Systems คือไม่ซับซ้อนทำความเข้าใจได้ง่าย ข้อเสียของ File Systems คือการขาดความยืดหยุ่น

File Systems จะเก็บข้อมูลเรียงติดกันไปหมด โปรแกรมจะแยกแยะว่าส่วนไหนเป็นข้อมูลอะไรได้ด้วยการนับจำนวนไบต์ เพราะความกว้างของคอลัมน์จะมีขนาดตายตัว หากข้อมูลสั้นกว่าก็จะถมด้วยเลขศูนย์หรือเครื่องหมายวรรค เราเรียก File Systems ได้อีกอย่างหนึ่งว่า Flat File

Flat File ที่ยังเหลือให้เห็นอยู่ในปัจจุบันคือแฟ้มแบบ CSV ซึ่งเป็นแบบที่คั่นคอลัมน์ด้วยคอมมา (comma-delimited file) เป็นแฟ้มที่เก็บข้อมูลตัวอักษรธรรมดา (text file) ข้อมูลแต่ละคอลัมน์ถูกคั่นด้วยเครื่องหมายจุลภาค  (,) แต่ละบรรทัดถูกแยกจากกันด้วยรหัสขึ้นบรรทัดใหม่ (รหัส new line ในภาษาซีคือ \n) ถ้าพูดให้ถึงที่สุดแล้วแฟ้มแบบ CSV ไม่ใช่ Flat File เพราะการมีคอมมาคั่นอาจถือว่าเป็นโครงสร้างอย่างหนึ่งได้เหมือนกัน

 

ภาพ 2-7 : แฟ้มแบบ CSV หรือแบบคั่นด้วยคอมมา (comma-delimited file)

 

2.7.2. แบบจำลองฐานข้อมูลแบบลำดับชั้น
แบบจำลองฐานข้อมูลแบบลำดับชั้น (Hierarchical Database Model ย่อ HDM) เกิดขึ้นในปี 1950 เป็นแบบจำลองฐานข้อมูลที่ถูกพัฒนาให้มีประสิทธิภาพดีกว่า File System และถูกใช้เรื่อยมาจนเสื่อมความนิยมไปในปี 1980 ข้อดีของ HDM คือการเพิ่มลดระเบียน (record) ทำได้ง่ายมาก ข้อเสียคือการค้นหาข้อมูลทำได้ช้าเพราะต้องไล่ไปตามลำดับชั้น

HDM มีโครงสร้างเหมือนต้นไม้กลับหัว คือรากอยู่บนสุดแล้วลำต้นแตกกิ่งก้านลงไปข้างล่าง (ดูภาพ 2-8)  ตารางที่อยู่บนคือตารางแม่ (parent table) ตารางที่มีลำดับต่ำกว่าคือตารางลูก (child table)

HDM มีความสัมพันธ์เป็นแบบ "หนึ่งต่อหลาย" (one to many) เพราะตารางแม่หนึ่งตารางอาจมีตารางลูกได้หลายตาราง และในขณะเดียวกันตารางลูกใดๆ อาจมีตารางลูกลงไปอีกชั้นหนึ่ง ทำให้มันมีฐานะเป็นตารางแม่ด้วยเช่นกัน ในทำนองเดียวกัน ตารางแม่ใดๆ อาจมีตารางแม่อยู่เหนือตัวมันอีก ทำให้มันมีฐานะเป็นตารางลูกด้วยเช่นกัน

 

ภาพ 2-8 : ในแผนภูมิแสดงแบบจำลองฐานข้อมูลแบบลำดับชั้นนี้ตารางงาน (Task)  คือส่วนหนึ่งของตารางโครงการ (Project) ตารางโครงการและตารางพนักงาน (Employee) เป็นส่วนหนึ่งของตารางผู้จัดการ (Manager) ตารางผู้จัดการเป็นส่วนหนึ่งของตารางแผนก (Department) ตารางแผนกต่างๆ เป็นส่วนหนึ่งของตารางบริษัท (Company) ข้อเสียของแบบจำลองฐานข้อมูลแบบลำดับชั้นคือการค้นหาข้อมูลต้องไล่ไปตามโหนดต่างๆ ยกตัวอย่างในภาพนี้หากต้องการค้นข้อมูลในตารางพนักงาน การค้นต้องทำจากบนสุดแล้วท่องไปในโหนดต่างๆ คือตารางบริษัท ตารางแผน ตารางผู้จัดการ แล้วจึงมาถึงตารางพนักงาน

 

2.7.3. แบบจำลองฐานข้อมูลแบบเครือข่าย
แบบจำลองฐานข้อมูลแบบเครือข่าย (Network Database Model ย่อ NDM) ถูกพัฒนามาจาก HDM เริ่มปรากฏในปี 1960 และถูกใช้เรื่อยมาจนเสื่อมความนิยมไปในปี 1990 แบบจำลอง NDM คล้ายคลึงกันมากกับ HDM จึงมีข้อดีข้อเสียใกล้เคียงกัน

คำว่าเครือข่ายในที่นี้ไม่ได้หมายถึงเครือข่ายคอมพิวเตอร์ แต่หมายถึงตารางต่างๆ ถูกนำมาเชื่อมโยงกันเป็นเครือข่ายเพื่อให้ตารางลูกมีตารางแม่ได้มากกว่าหนึ่งตาราง (ต่างจาก HDM ที่ตารางลูกมีตารางแม่ได้ได้เพียงตารางเดียว)  NDM จึงมีความสัมพันธ์เป็นแบบ "หลายต่อหลาย" (many to many)

 

ภาพ 2-9 : แผนภูมิแสดงแบบจำลองฐานข้อมูลแบบเครือข่าย จะเห็นว่าตารางผู้จัดการเป็นทั้งส่วนหนึ่งของตารางแผนกและตารางบริษัท หรือพูดอีกอย่างหนึ่งคือไม่เฉพาะตารางแผนกเท่านั้นที่มีตารางผู้จัดการ แต่ตารางบริษัทเองก็มีผู้จัดการด้วยเช่นกัน และตารางพนักงานสามารถแยกออกเป็นประเภทต่างๆ ของพนักงานได้

 

2.7.4. แบบจำลองฐานข้อมูลสัมพันธ์
แบบจำลองฐานข้อมูลสัมพันธ์ (Relational Database Model ย่อ RDM) เป็นแบบจำลองข้อมูลที่ถูกพัฒนาด้วยแนวคิดใหม่ซึ่งแตกต่างจากแบบจำลองฐานข้อมูล  HDM และ NDM ไปมาก RDM เริ่มปรากฏในปี 1970 และถูกใช้เรื่อยมาจนถึงทุกวันนี้ ข้อดีของ RDM คือมีบูรณภาพของข้อมูลดีมาก ข้อเสียคือโปรแกรม DBMS ซับซ้อนกว่าแบบจำลองสามแบบแรก

เมื่อพูดว่าความสัมพันธ์ (relational) คนทั่วไปมักนึกถึงการเชื่อมโยงระหว่างตารางต่างๆ ด้วยคีย์ต่างๆ (เช่นไพรมารีคีย์และฟอร์เรนคีย์) แต่อันที่จริงแล้วคำว่า "ความสัมพันธ์" ในวิชา  RDM หมายถึงความเชื่อมโยงของแอตทริบิวต์และทูเพิลภายในตาราง ไม่ใช่การเชื่อมโยงระหว่างตาราง

RDM มีประสิทธิภาพสูงกว่า  HDM และ NDM เช่นหากต้องการค้นหาข้อมูลของพนักงานหนึ่งคน เราไม่ต้องไล่จากตารางบนสุด (ตารางบริษัท) แล้วท่องไปตามตารางต่างๆ จนกระทั่งถึงตารางพนักงาน แต่เราสามารถเข้าถึงตารางพนักงานได้โดยตรง ข้อดีอีกอย่างหนึ่งของ RDM คือเราสามารถเชื่อมโยงตารางต่างๆ เข้าด้วยกันได้โดยไม่จำเป็นต้องคำนึงถึงลำดับชั้น คือตารางหนึ่งๆ จะเชื่อมโยงกับตารางอื่นๆ อย่างไรก็ได้โดยอิสระ

 

ภาพ 2-10 : สมมุตว่าเรามีตารางอยู่สองตาราง ตารางแรก Project (กรอบบน) ทำหน้าที่เก็บข้อมูลโครงการต่างๆ อีกตารางหนึ่งคือ Task  (กรอบล่าง) ทำหน้าที่เก็บรายละเอียดงานต่างๆ ในหนึ่งโครงงาน สองตารางนี้เชื่อมกันได้ด้วยคอลัมน์ Project_ID ซึ่งเป็นรหัสงาน ตัวเลขนี้ทำหน้าที่เป็นไพรมารีคีย์ในตาราง Project ซึ่งจะไม่มีค่าซ้ำกัน แต่ในตาราง Task คอลัมน์ Project_ID ทำหน้าที่เป็นฟอร์เรนคีย์ (คือเป็นคีย์สำหรับอ้างถึงข้อมูลในตารางอื่น) อาจมีค่าซ้ำกันได้ ยกตัวอย่างเช่นในตาราง Project บรรทัดแรก Project_ID เท่ากับ 1 คือโครงการ Software sales data mart มีงานย่อยสามงาน คือบรรทัดที่หนึ่งถึงสามในตาราง Task จะเห็นว่าคอลัมน์ Project_ID ในตาราง Task มีเลข 1 ซ้ำกันอยู่สามแถว

 

ภาพ 2-11 : แผนภูมิแสดงแบบจำลองฐานข้อมูลสัมพันธ์ตามตัวอย่างตารางในภาพ 2-10


 

2.7.5. แบบจำลองฐานข้อมูลแบบวัตถุ
แบบจำลองฐานข้อมูลแบบวัตถุ  (Object Database Model ย่อ ODM) เป็นแนวคิดใหม่ที่ปรากฏขึ้นในปี 1980 และยังได้รับการพัฒนาต่อเนื่องมาจนถึงทุกวันนี้  แบบจำลอง ODM อาศัยแนวคิดว่าข้อมูลเป็นออพเจ็กต์เหมือนออพเจ็กต์ในวิชา OOP (การเขียนโปรแกรมวัตถุวิธี)  แบบจำลอง ODM มีข้อดีคือการทำงานได้มีประสิทธิภาพสูงกว่า RDM อย่างชัดเจนในบางสถานการณ์ แต่มีข้อเสียคือเรียนรู้ได้ยากและผนวกกับภาษา OOP มาตรฐานอย่าง C# ไม่ได้

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

 

ภาพ 2-12 : นี่คือฐานข้อมูลเดียวกันกับในหัวข้อแบบจำลองฐานข้อมูลสัมพันธ์ แต่ภาพนี้แสดงในแบบจำลองฐานข้อมูลแบบวัตถุ โปรดสังเกตว่าคลาสพนักงาน (Employee Class) อยู่ในคอลเลคชันเดียวกันกับคลาสผู้จัดการ  (Manager Class) โดยมีคลาสงาน (Task Class) และคลาสอื่นๆ สืบคุณสมบัติไปจากมัน (เช่นคลาสพนักงานเต็มเวลา Full Time Employee Class)

 

แบบจำลองฐานข้อมูล: ตอน 2

 

 
Home Page  |   รายการบทความ   |   ลิงค์ที่เกี่ยวข้อง   |   laploy.com  |  เกี่ยวกับผู้เขียน

 

แบบจำลองฐานข้อมูล: ตอน 2

 

2.4. นิยามชนิดข้อมูล
ชนิดข้อมูลคือลักษณะหรือแบบแผนของข้อมูล แบ่งออกเป็นกลุ่มใหญ่ๆ สามกลุ่มดังนี้
•    ชนิดข้อมูลพื้นฐาน: คือข้อมูลสำหรับข้อมูลเดี่ยวๆ (สเกลาร์) เช่นข้อมูลแบบตัวอักษร ข้อมูลแบบตัวเลข
•    ชนิดข้อมูลซับซ้อน: เป็นโครงสร้างย่อย เช่นอาร์เรย์และออพเจ็กต์แบบไบนารี
•    ชนิดข้อมูลพิเศษ: โครงสร้างข้อมูลที่ก้าวหน้าเช่น โครงสร้างในเอกสารแบบ XML และข้อมูลมัลติมีเดียเช่นวิดีโอ เสียงและแผนภูมิ

 

2.4.1. ชนิดข้อมูลพื้นฐาน
ชนิดข้อมูลพื้นฐานแบ่งออกเป็นประเภทต่างๆ หลายแบบ จำนวนประเภทแตกต่างกันไประหว่างโปรแกรม DBMS แต่ละยี่ห้อ โดยทั่วไปแล้วชนิดข้อมูลพื้นฐานจะมีแบบต่างๆ ดังนี้

  • ตัวอักษร: ตัวอักษร (string) เก็บข้อมูลตัวอักษรหนึ่งหรือหลายๆ ตัว แบ่งออกเป็นชนิดย่อยดังนี้
    o    แบบความยาวคงที่: ข้อมูลตัวอักษรที่มีความยาวของสายอักขระที่แน่นอน เช่น CHAR(3) กำหนดความยาวไว้สามตัวอักษร หากนำมาใส่ข้อมูลที่มีความยาวเพียงสองตัวอักษร DBMS จะแทรกรหัสอักษรเคาะวรรคไว้หนึ่งตัวเพื่อทำให้มีจำนวนอักษรครบสามตัว
    o    แบบความยาวไม่คงที่: มีความยาวของสายอักขระที่ไม่แน่นอน เช่น VCHAR(10) กำหนดความยาวไว้สิบตัวอักษร หากนำมาใส่ข้อมูลที่มีความยาวเพียงห้าตัวอักษร DBMS จะไม่แทรกรหัสใดๆ ต่อท้ายเพื่อให้มีจำนวนครบสิบตัว
  • ตัวเลข: ข้อมูลตัวที่ใช้เพื่อข้อมูลเก็บตัวเลขแบ่งออกเป็นสามชนิดย่อยคือ
    o    จำนวนเต็ม: ใช้เก็บตัวเลขที่ไม่มีจุดทศนิยม เช่น SINT (TINYINT), INT และ LONGINT
    o    ทศนิยมหลักคงที่: ใช้เก็บตัวเลขที่มีจำนวนหลักที่แน่นอน ยกตัวอย่างเช่น DECIMAL(5.2) คือการกำหนดให้เก็บตัวเลขได้ 5 หลัก และมีเลขหลังทศนิยมได้ 2 ตำแหน่ง จึงสามารถเก็บข้อมูล12345.67 และ 12.34 ได้ แต่เก็บ 12.345 หรือ 123456.12 ไม่ได้
    o    โฟลตติงพอยน์: floating point ใช้เก็บตัวเลขทศนิยมที่มีตำแหน่งทศนิยมไม่แน่นอน เช่น 1234, 123.45, 0.1234 เหล่านี้เป็นค่าที่เก็บด้วยชนิดข้อมูลโฟลตติงพอยน์ได้
  • วันที่: เก็บวันเดือนปีในลักษณะต่างๆ และอาจรวมข้อมูลเวลาไว้ด้วยก็ได้

 

ภาพ 2-3 : ตัวอย่างชนิดข้อมูลแบบเวลาใน SQL2008


2.4.2. ชนิดข้อมูลซับซ้อน
ชนิดข้อมูลซับซ้อนเป็นโครงสร้างข้อมูล หรือข้อมูลที่อยู่รวมกันเป็นกลุ่ม (data collection) ยกตัวอย่างเช่น
•    ไบนารี: ข้อมูลแบบไบนารี (binary) คือข้อมูลในรูปเลขฐานสองที่เป็นก้อนขนาดใหญ่ เช่นรูปภาพ วิดีโอ เสียง ไม่สามารถบรรจุไว้ในแถวของตารางโดยตรงได้ เพราะปรกติแถวของตารางจะเก็บข้อมูลได้รวมกันไม่เกิน 2KB
•    พอยน์เตอร์: เป็นข้อมูลไบนารีที่ใช้สำหรับชี้ตำแหน่งข้อมูลในหน่วยความจำหรือในจานบันทึกข้อมูล
•    อาร์เรย์: (array) คือโครงสร้างข้อมูลที่มีการเรียงตัวซ้ำๆ กัน แบ่งออกเป็นอาร์เรย์แบบความยาวคงที่ และอาร์เรย์แบบความยาวเปลี่ยนแปลงได้ (dynamic array)
•    ชนิดข้อมูลที่ผู้ใช้นิยามขึ้นเอง: (User Defined Type ย่อ UDT) เป็นชนิดข้อมูลที่ผู้ใช้สร้างขึ้นโดยนำชนิดข้อมูลพื้นฐานมาจัดรูปแบบเป็นโครงสร้างที่แน่นอน เช่น structure

 

ภาพ 2-4 : ตัวอย่างชนิดข้อมูลแบบพอยน์เตอร์


2.4.3. ชนิดข้อมูลพิเศษ
ชนิดข้อมูลพิเศษคือชนิดข้อมูลที่เป็นออพเจ็กต์ และสามารถสืบคุณสมบัติของออพเจ็กต์ได้ เช่นแฟ้มข้อมูล XML และออพเจ็กต์ที่เป็นมัลติมีเดีย

 

2.5. นิยาม RDBMS
RDBMS (ย่อจาก Relational Database Management System) คือคำที่ใช้เรียกชุดโปรแกรมทั้งมวลที่ประกอบเป็นเอนจินฐานข้อมูลและโปรแกรมจัดการฐานข้อมูล บางครั้งนับรวมชุดพัฒนาโปรแกรม (Software Development Kit หรือ SDK) และส่วนเครื่องมือสำรับใช้งานที่มีส่วนติดต่อกับผู้ใช้เป็นกราฟิกด้วย โปรแกรม SQL2008 ก็เข้าข่ายนิยามนี้ สรุปว่า RDBMS ก็คือเอนจินฐานข้อมูลบวกซอฟต์แวร์ที่เกี่ยวข้องทั้งหลายบรรจุไว้เป็นชุดเดียวกัน

 

2.6. ความเป็นมาของ  RDBMS
RDBMS  ถูกประดิษฐ์คิดค้นโดยนักวิจัยของบริษัทไอบีเอ็มชื่อ ดร. อี เอฟ คอดด์ (Dr. E. F. Codd) ภายหลังทีมงานฐานข้อมูลของไอบีเอ็มได้นำแนวคิดนี้ไปสร้างเป็นสินค้า งานวิจัยของคอดด์เน้นการลดทอนความซ้ำซ้อนของการเก็บข้อมูลโดยใช้กระบวนการ "นอร์มาไลเซชัน"  (normalization) กระบวนการนี้ประกอบด้วยขั้นตอนต่างๆ หลายขั้นตอน แต่ละขั้นตอนเรียกว่า "นอร์มัล ฟอร์ม" (normal form)

แนวคิดพื้นฐานที่คอดด์พรรณนาไว้ในเอกสารวิชาการจำนวนมากกลายมาเป็นภาษาสืบค้นข้อมูลต่อโครงสร้าง (Structured Query Language) หรือภาษา SQL ภาษานี้ถูกนำไปต่อยอดโดยคณะบุคคลในหลายๆ โครงการ เกิดเป็นผลิตภัณฑ์หลายสายตระกูลดังที่เห็นในภาพ 2-5  (อ่านรายละเอียดเรื่องคอดด์และประวัติของฐานข้อมูลสัมพันธ์เพิ่มเติมได้ในภาคผนวก)

 

ภาพ 2-5 : แนวคิดพื้นฐานที่คอดด์พรรณนาไว้ในเอกสารวิชาการหลายฉบับถูกคณะบุคคลหลายกลุ่มนำไปพัฒนาต่อยอด ช่วงปี  1970 ทีมนักวิจัยของไอบีเอ็มที่เมือง ซาน โฮเซ (เมือง San Jose ในแคลิฟอร์เนีย ปัจจุบันคือศูนย์วิจัย อัลมาเดน) ผู้พัฒนาโครงการ System R นำแนวคิดของคอดด์ไปพัฒนาเป็นภาษา SQL และผลิตภัณฑ์ DB2 ซึ่งเป็นผลิตภัณฑ์ RDBMS ที่วิ่งในหลายโอเอสเช่น UNIX, Windows และ Linux รวมถึง z/OS ซึ่งเป็นโอเอสแบบหกสิบสี่บิตทำงานในคอมพิวเตอร์แบบเมนเฟรมของไอบีเอ็ม

 

ในช่วงปี 1997 ถึง 1998 นักวิทยาศาสตร์สองคนที่มหาวิทยาลัยแคลิฟอร์เนีย วิทยาเขตเบอร์คลีย์ ทำโครงการ Ingres ซึ่งเป็น RDBMS ที่ทำงานในระบบปฏิบัติการ UNIX บนคอมพิวเตอร์ของบริษัท DEC เนื่องจากผู้สร้าง Ingres ขายซอร์สโค้ดในราคาถูกภายใต้สัญญาการใช้งานแบบ BSD (Berkeley Software Distribution) จึงมีบริษัทเอกชนหลายรายนำซอร์สโค้ดไปสร้างเป็นสินค้า เช่น ออราเคิล ไซเบสและไมโครซอฟต์ (ไมโครซอฟต์ซื้อสิทธิจากไซเบสอีกทอดหนึ่ง)

นักวิทยาศาสตร์ที่เบอร์คลีย์ตั้งบริษัทชื่อ Ingres ขาย  RDBMS ในลักษณะโอเพ่นซอร์สต่อมาแตกออกเป็นอีกสองบริษัทคือ Informix (ถูกไอบีเอ็มซื้อกิจการไปในปี 2001)  และ Postgres ซึ่งเป็น  RDBMS แบบออพเจ็กต์สัมพันธ์ที่ฟรี (สัญญาการใช้งานแบบ BSD) ในทศวรรษ 1990 บริษัทออราเคิล (และ Postgres) นำแนวคิดของคอดด์มาต่อยอดเป็นแบบจำลองฐานข้อมูลแบบวัตถุ และแบบจำลองฐานข้อมูลแบบออพเจ็กต์สัมพันธ์

 

แบบจำลองฐานข้อมูล: ตอน 1

 

 
Home Page  |   รายการบทความ   |   ลิงค์ที่เกี่ยวข้อง   |   laploy.com  |  เกี่ยวกับผู้เขียน

 

แบบจำลองฐานข้อมูล: ตอน 1

 

ท่านคงเคยเห็นแบบจำลองของเครื่องบิน รถถัง รถไฟ ในการก่อสร้างอาคาร สถาปนิกมักสร้างแบบจำลองของอาคารก่อนสร้างจริง เพื่อใช้เป็นเครื่องตรวจสอบการออกแบบ และเพื่อให้ผู้เกี่ยวข้องในโครงการได้เห็นภาพรวมของโครงการ แบบจำลองฐานข้อมูล (database model) ก็มีจุดประสงค์เดียวกัน คือเป็นเครื่องมือสำหรับใช้พรรณนาโครงสร้าง และคุณสมบัติต่างๆ ของฐานข้อมูล แบบจำลองฐานข้อมูลมีหลายแบบ ถูกปรับปรุงเปลี่ยนแปลงมาเป็นระยะเวลาไม่ต่ำกว่าห้าสิบปี

ในบทนี้ท่านจะได้เรียนเรื่องแบบจำลองฐานข้อมูลซึ่งประกอบด้วยหัวข้อต่างๆ ดังนี้

•    การประยุกต์ใช้งาน
•    สองสถาปัตยกรรม
•    วิวและออพเจ็กต์พิเศษอื่นๆ
•    นิยามชนิดข้อมูล
•    นิยาม RDBMS
•    ความเป็นมาของ  RDBMS
•    วิวัฒน์ของแบบจำลองฐานข้อมูล

 

2.1. การประยุกต์ใช้งาน
คำว่า "แอพลิเกชัน" (application) คือ "คำจาร์กอน" ในวงการคอมพิวเตอร์ หมายถึงซอฟต์แวร์ที่รันในคอมพิวเตอร์และทำงานบางอย่าง งานที่ว่าอาจเป็นการมีปฏิสัมพันธ์กับผู้ใช้แบบรูปภาพ หรือ GUI ที่ช่วยให้การสร้างรายงานง่ายเพียงแค่ลากเมาส์ไปมา แล้วกดปุ่มสองสามทีก็จะได้รายงานที่สมบูรณ์

แอพลิเกชันทำให้ฐานข้อมูล "โปร่งใส" คือผู้ใช้มองไม่เห็น หรือไม่อาจมีปฏิสัมพันธ์กับฐานข้อมูลโดยตรง คำว่าโปร่ง (transparency) ซึ่งเป็นคำจาร์กอนอีกคำในวงการคอมพิวเตอร์ หมายถึงผู้ใช้ได้รับข้อมูลจากฐานข้อมูลผ่านแอพลิเกชัน จึงไม่เห็นการทำงานหรือโครงสร้างของฐานข้อมูล นั่นคือผู้ใช้ถูกกันไว้ไม่ให้เข้าถึงฐานข้อมูลโดยตรง 

การออกแบบฐานข้อมูลจำเป็นต้องคำนึงถึงการประยุกต์ใช้งานเป็นที่ตั้ง การประยุกต์ใช้งานฐานข้อมูลมีหลายแบบ
การประยุกต์ใช้งานแต่ละแบบจะเป็นตัวกำหนดคุณสมบัติของแบบจำลองฐานข้อมูล  ยกตัวอย่างเช่น ในบทที่แล้วท่านได้เรียนไปแล้วว่าฐานข้อมูลแบ่งออกเป็นประเภทใหญ่ๆ สองประเภทคือ OLTP และดาต้าแวร์เฮาส์  แบบจำลองฐานข้อมูลของฐานข้อมูลสองประเภทนี้ย่อมแตกต่างกัน

 

2.2. สองสถาปัตยกรรม
การประมวลผลธุรกรรมออนไลน์ (OnLine Transaction Processing ย่อ OLTP) คือสถาปัตยกรรมที่มีผู้ใช้จำนวนมากเข้าถึงข้อมูลจำนวนน้อยๆ แต่ทำอย่างถี่ๆ แบบจำลองฐานข้อมูลที่เหมาะกับการประยุกต์ใช้งานลักษณะนี้คือ "แบบจำลองข้อมูลสำหรับธุรกรรม" (Transactional Database Model ย่อ TDM) ซึ่งเป็นแบบจำลองฐานข้อมูลที่ออกแบบมาสำหรับบริการผู้ใช้งานจำนวนมากที่เข้าถึงข้อมูลที่มีปริมาณน้อยแต่ใช้งานพร้อมกันและอย่างถี่ๆ

แบบจำลองฐานข้อมูลที่ตรงกันข้ามกับ OLTP คือ "โกดังข้อมูล" หรือดาต้าแวร์เฮาส์ (data warehouse) ผู้ใช้จะอัพเดตข้อมูลหรือดึงข้อมูลครั้งละมากๆ (เช่นการดึงข้อมูลเพื่อนำไปใช้ในการวิเคราะห์) มีจำนวนผู้ใช้พร้อมกันไม่มากนัก (เมื่อเทียบกับ OLTP เพราะผู้ใช้งานดาต้าแวร์เฮาส์คือนักวิเคราะห์ข้อมูลซึ่งมีจำนวนน้อยกว่าผู้ใช้แอพลิเกชัน)  เนื่องจากไม่ใช่การทำงานตามลำดับเหตุการณ์ที่เกิดขึ้นจริง (real time) ระบบจึงไม่จำเป็นต้องตอบสนองการทำงานเร็วมากนักก็ได้ ปรกติแบบจำลองข้อมูลลักษณะนี้จะถูกสร้างขึ้นโดยนำฐานข้อมูล OLTP มาแยกย่อยเป็นโครงสร้างที่ซ้ำกันหลายๆ ชุด

 

ภาพ 2-1: การใช้งาน Business Intelligence (BI) และดาต้าแวร์เฮาส์

 

2.3. วิวและออพเจ็กต์พิเศษอื่นๆ
ในฐานข้อมูลนอกจากจะมีตารางและดรรชนีแล้วยังมีออพเจ็กต์อื่นๆ อีกหลายอย่างที่นักออกแบบฐานข้อมูลจำเป็นต้องรู้จักดังต่อไปนี้

  • วิว: วิว (View) คือนิยามคิวรี ตัวมันเองไม่ใช่ตารางและไม่ได้เก็บข้อมูลใดๆ ไว้ภายใน วิวเป็นเพียงโครงสร้างทางตรรกะของตาราง เมื่อสั่งให้วิวทำงานเราจะได้ข้อมูลเป็นตารางเสมือน วิวมีประโยชน์เมื่อนำมาใช้ระหว่างขั้นตอนพัฒนา แต่ไม่ควรนำไปใช้ในขั้นตอนใช้งานจริง เพราะวิวอาจทำให้ประสิทธิภาพของฐานข้อมูลลดลง
  • วิววัตถุ: วิววัตถุ (Materialized views) ตางจากวิวธรรมดาตรงที่มันเป็นตารางข้อมูลชั่วคราวที่ถูกสร้างจากตารางจริงและมีข้อมูลเก็บไว้จริงๆ จุดประสงค์ในการสร้างวิววัตถุคือเพื่อลดภาระของตารางหลัก วิววัตถุมักถูกนำมาใช้เพื่อหาผลรวมของชุดข้อมูล (ดาต้าเซต dataset) ขนาดใหญ่ในงานคลังข้อมูล ในบาง RDBMS จะสนับสนุนการปรับข้อมูล (refresh) ระหว่างตารางจริงกับวิววัตถุโดยอัตโนมัติ ทำให้เราสามารถใช้งานวิววัตถุได้โดยไม่ต้องห่วงเรื่องความล้าสมัยของข้อมูล
  • คลัสเตอร์: คลัสเตอร์ (Cluster) เป็นออพเจ็กต์พิเศษที่ปัจจุบันไม่นิยมใช้แล้ว มันมีลักษณะและจุดประสงค์ในการใช้งานเหมือนวิววัตถุแต่ไม่มีการการปรับข้อมูลอัตโนมัติ
  • ตัวนับอัตโนมัติ: ตัวนับอัตโนมัติ (auto counter) คือคอลัมน์ที่เพิ่มค่าได้โดยอัตโนมัติ ทำให้เราสร้างคอลัมน์ซึ่งทำหน้าที่เป็นกุญแจแทนได้ง่ายขึ้น เพราะ RDBMS จะใส่ค่าในคอลัมน์นี้ให้โดยอัตโนมัติเป็นค่าที่เรียงลำดับ (เช่น 001, 002, 003 ฯลฯ)
  • ตัวประมวลผลแบบขนาน: โปรแกรม RDBMS บางตัวสนับสนุนการแยกตารางออกเป็นหลายส่วนเพื่อให้ตัวประมวลผลหลายตัวประมวลผลไปพร้อมๆ กันได้เพื่อเพิ่มประสิทธิภาพของฐานข้อมูล

ภาพ 2-2: ตัวประมวลผลแบบขนาน CELL/B.E. ที่ผลิตโดยบริษัทไอบีเอ็ม โซนีและโตชิบา