การออกแบบฐานข้อมูล
ความต้องการตารางข้อมูลใหม่และคีย์เป็นเรื่องของศิลปะ ดังนั้น ควรอ่านเพิ่มเติมเกี่ยวกับไดอะแกรม entity relationship และ normalization โดยส่วนใหญ่สามารถทำตามหลักการออกแบบพื้นฐาน ให้พิจารณาสิ่งเหล่านี้ในบริษัทของ Widebase Book
ความคิดเกี่ยวกับโลกความจริงในแบบจำลอง
เมื่อสร้างฐานข้อมูล ตามปกติการสร้างแบบจำลองรายการโลกจริง ความสัมพันธ์ และการเก็บสารสนเทศเกี่ยวกับอ๊อบเจค และความสัมพันธ์เหล่านั้น
โดยทั่วไป แต่ละชั้นของอ๊อบเจคโลกจริงในแบบจำลองจะต้องตารางข้อมูลของตัวเอง เช่น เมื่อต้องการเก็บสารสนเทศเดียวกันเกี่ยวกับลูกค้าทั้งหมด ถ้ามีชุดของข้อมูลที่มี รูปร่าง เหมือนกัน สามารถทำให้สร้างตารางข้อมูลตรงตามกับข้อมูล
ในตัวอย่าง Widebase Book มีความต้องการเก็บสารสนเทศเกี่ยวกับลูกค้า หนังสือที่ขายและรายละเอียดใบสั่งซื้อ ลูกค้าทั้งหมดมีชื่อและ ที่อยู่ ใบสั่งซื้อมีวันที่ จำนวนรวม และชุดของหนังสือที่มีการสั่งซื้อ หนังสือมีเลข ISBN ชื่อผู้เขียน ชื่อหนังสือ และ ราคา
สารสนเทศนี้ต้องการอย่างน้อย 3 ตารางในฐานข้อมูลนี้ คือ Customer Orders และ Book สำหรับ schema ได้รับการแสดงในภาพ 7.3
หลีกเลี่ยงการเก็บข้อมูลซ้ำซ้อน
จากคำถามก่อนหน้านี้ ทำไมไม่เก็บที่อยู่ของ สมศรี ยืนยง ในตารางข้อมูล Orders ถ้า สมศรี สั่งซื้อ Widebase Book จากการซื้อครั้งหนึ่งเมื่อการสั่งซื้อเสร็จแล้วจะมีการเก็บสารสนเทศหลายครั้ง เมื่อจัดเก็บข้อมูลของตารางข้อมูล Order แล้วจะดูเหมือนกับภาพ 7.4
ในกรณีนี้ มี 2 ปัญหาพื้นฐาน
ปัญหาแรก สูญเสียพื้นที่ ทำไมต้องเก็บรายละเอียดของ สมศรี 3 ครั้ง ถ้าจำเป็นต้องเก็บเพียงครั้งเดียว
ภาพ 7.2 แต่ละใบสั่งซื้ออ้างถึงลูกค้าในตารางข้อมูล Customers
OrderID |
Amount |
Date |
CustomerID |
Name |
Address |
City |
20 |
2,150.00 |
21- Jan-2005 |
1 |
สมศรี ยืนยง |
15/14 ถนนพหลโยธิน พญาไท |
กรุงเทพฯ |
21 |
785.00 |
25-Jan-2005 |
1 |
สมศรี ยืนยง |
15/14 ถนนพหลโยธิน พญาไท |
กรุงเทพฯ |
22 |
1,150.00 |
26- Jan-2005 |
1 |
สมศรี ยืนยง |
15/14 ถนนพหลโยธิน พญาไท |
กรุงเทพฯ |
ภาพ 7.3 การออกแบบฐานข้อมูลที่เก็บข้อมูลซ้ำซ้อน
ปัญหาที่ 2 สามารถนำสู่การปรับปรุงผิดหลัก (update anomalies) สถานการณ์นี้จะเปลี่ยนฐานข้อมูลและปรับปรุงด้วยข้อมูลไม่แน่นอน ความมั่นคงของข้อมูลถูกละเมิดและไม่สามารถทราบได้ว่าข้อมูลใดถูกต้อง และชุดใดผิดโดยทั่วไปนำสู่การสูญเสียสารสนเทศ
การปรับปรุงผิดหลัก 3 ชนิด คือ การปรับปรุง การเพิ่ม และลบ
ถ้า สมศรี ย้ายบ้านขณะที่มีใบสั่งค้างอยู่ จะต้องมีการปรับปรุงที่อยู่ 3 แห่งแทนที่ 1 แห่ง โดยต้องทำงาน 3 ครั้ง ข้อเท็จจริงนี้เห็นได้ง่าย และเปลี่ยนข้อมูลเพียง 1 แห่ง จะนำไปสู่ข้อมูลไม่แน่ปัญหานี้ เรียกว่า การปรับปรุงผิดหลัก (modification anomalies) เพราะเกิดขึ้นเมื่อพยายามปรับปรุงฐานข้อมูล
ด้วยการออกแบบนี้ต้องมีการเพิ่มรายละเอียดของ สมศรี ทุกครั้งที่มีการสั่งซื้อ ดังนั้น แต่ละครั้งต้องมีการตรวจสอบและทำให้มั่นใจว่ารายละเอียดที่ตรงกันทุกแถวในฐานข้อมูล ถ้าไม่มีการตรวจสอบ อาจจะมีเพิ่มข้อมูล 2 แถว ด้วยสารสนเทศเกี่ยวกับ Julie ขัดแย้งกัน ตัวอย่างเช่น แถวหนึ่งบอกว่า สมศรี อยู่ใน Airport West และอีกแถวบอกว่าอยู่ใน Airport นี่เรียกว่า การเพิ่มผิดหลัก (insertion anomalies) เพราะเกิดขั้นเมื่อกำลังเพิ่มข้อมูล
การลบผิดหลัก (deletion anomalies) เพราะเกิดขึ้นเมื่อลบแถวจากฐานข้อมูล ตัวอย่างเช่น เมื่อมีการส่งหนังสือตามใบสั่งซื้อแล้วจะมีการลบจากฐานข้อมูล เมื่อใบสั่งซื้อของ สมศรี ได้รับการส่งไปแล้วจะมีการลบทั้งหมดจากตารางข้อมูล Orders หมายความว่า จะไม่มีที่อยู่ของ สมศรี อีกต่อไป ทำให้ไม่สามารถส่งข้อเสนอพิเศษให้ สมศรี และเมื่อมีการสั่งซื้อครั้งต่อไป จะต้องมีการเก็บรายละเอียดทั้งหมดอีก
การใช้ค่าคอลัมน์แบบอะตอม
สิ่งนี้หมายความว่า แต่ละคุณลักษณะหรือฟิลด์ในแต่ละแถว ใช้เก็บเพียงสิ่งเดียว เช่น ต้องการทราบถึงหนังสือในใบสั่งซื้อ โดยวิธีการทำมีหลายวิธี
ตารางข้อมูล Orders สามารถได้รับการเพิ่มคอลัมน์ เพื่อแสดงรายการหนังสือจากการสั่งซื้อ ตามภาพ 7.5
OrderID |
CustomerID |
Amount |
Date |
Book Orders |
1 |
3 |
3,225.00 |
21- Jan-2005 |
0-623-54125-7, 0-630-78510-6 |
2 |
2 |
215.00 |
25-Jan-2005 |
0-652-32157-5 |
3 |
1 |
84.00 |
26- Jan-2005 |
0-630-78510-6 |
4 |
4 |
2,127.00 |
30-Jan-2005 |
0-652-32157-5, 0-652-21504-3 |
นี่ไม่ใช่ความผิดที่ดีด้วยเหตุผลบางประการ เนื่องจากกำลังทำ nesting กับตารางทั้งตารางภายใน 1 คอลัมน์ ตารางข้อมูลที่สัมพันธ์กับใบสั่งซื้อกับหนังสือ เมื่อทำงานด้วยวิธีนี้ จะมีความลำบากมากขึ้นเพื่อตอบคำถาม จำนวนการสั่งซื้อ คู่มือการใช้ Microsoft Access 2000 ระบบไม่สามารถนับฟิลด์ได้ ดังนั้นควรกระจายค่าแต่ละคุณลักษณะเพื่อดูว่าถ้าเก็บค่าจับคู่ได้ภายใน
เนื่องจากว่ากำลังทำการสร้างตารางข้อมูลภายในตารางข้อมูล ดังนั้น ควรสร้างตารางข้อมูลใหม่ตารางนี้เรียกว่า Order_Item และ แสดงในภาพ 7.6
ตารางข้อมูลนี้เชื่อมระหว่างตารางข้อมูล Orders และ Book ตารางประเภทนี้ เป็นประเภทปกติเมื่อมีความสัมพันธ์แบบ many-to-many ระหว่าง 2 อ๊อบเจค ในกรณีนี้ 1 ใบสั่งซื้อ ประกอบด้วยหนังสือหลายเล่ม และ หนังสือแต่ละเล่ม สามารถสั่งโดยคนหลายคน
เลือกคีย์ให้เหมาะสม
ทำให้มั่นใจว่าคีย์เป็นแบบไม่ซ้ำ ในกรณีนี้ต้องสร้างคีย์เฉพาะสำหรับลูกค้า (customerid) และสำหรับใบสั่งซื้อ (orderid) เพราะอ๊อบเจคในโลกความจริงไม่มี identifier ที่สามารถประกันว่าเป็นค่าไม่ซ้ำ แต่ไม่จำเป็นสร้าง identifier สำหรับหนังสือ เนื่องจากมีอยู่แล้วในรูปของ ISBN จะเป็นค่าไม่ซ้ำ เมื่อมีหนังสือ 1 รายการในใบสั่งซื้อ ได้รับการปฏิบัติเป็น 1 แถว ด้วยเหตุผลนี้ตาราง Order_item มีคอลัมน์ quantity
Order_Item
OrderID |
ISBN |
Quantity |
1 |
0-623-54125-7 |
1 |
2 |
0-630-78510-6 |
2 |
3 |
0-652-32157-5 |
2 |
4 |
0-652-21504-3 |
1 |
5 |
0-672-58412-6 |
2 |
6 |
0-672-36527-4 |
1 |
ภาพ 7.6 การออกแบบให้ค้นหาจำนวนการสั่งหนังสือ
คิดถึงคำถามที่ต้องการถามฐานข้อมูล
ต่อจากการออกแบบคอลัมน์แล้ว ให้คิดถึงคำถามที่ต้องการคำตอบจากฐานข้อมูล จะเป็นการทำให้มั่นใจว่าฐานข้อมูลเก็บข้อมูลทั้งหมดตามความต้องการ และการเชื่อมที่เหมาะสมระหว่างตารางข้อมูลเพื่อตอบคำถาม
หลีกเลี่ยงการออกแบบที่มีฟิลด์ว่างจำนวนมาก
ถ้าต้องการเพิ่มคำวิจารณ์หนังสือกับฐานข้อมูล มีอย่างน้อย 2 วิธี ที่สามารถทำได้
วิธีแรก เพิ่มคอลัมน์ Review ลงในตาราง Books วิธีนี้ ฟิลด์ Review ได้รับการเพิ่มให้กับหนังสือแต่ละเล่ม ถ้ามีหนังสือจำนวนมากในฐานข้อมูล และผู้วิจารณ์ไม่มีแผนวิจารณ์ทั้งหมด หลายแถวจะไม่มีค่าในฟิลด์นี้ที่เรียกว่า มีค่าว่าง (null value)
การมีค่าว่างจำนวนมากในฐานข้อมูล เป็นความคิดไม่ดี ที่ทำให้สิ้นเปลืองพื้นที่ และเป็นสาเหตุของปัญหา เมื่อทำการหาผลรวม และการทำงานอื่นกับคอลัมน์ตัวเลข เมื่อผู้ใช้เห็นค่าว่างในตาราง พวกเขาจะไม่ทราบ เนื่องจากฟิลด์นี้ไม่มีความสัมพันธ์ มีความผิดพลาดในฐานข้อมูล หรือ ยังไม่ได้ป้อนข้อมูล
โดยทั่วไปปัญหาค่าว่างจำนวนมากหลีกเลี่ยงได้โดยการออกแบบอีกวิธี ในกรณีนี้ สามารถใช้การออกแบบที่ 2 ในภาพ 7.7 เฉพาะหนังสือที่มีการวิจารณ์จะได้รับการเพิ่มรายการในตารางข้อมูล book_reviews
Book
ISBN |
Author |
Title |
Price |
Reviews |
0-623-54125-7 |
ไชยวัฒน์ ตระการรัตน์สันติ |
คู่มือการใช้ Microsoft Access 2000 |
300.00 |
|
0-320-55200-5 |
Luke Welling |
PHP and MySQL Web Development |
1200.00 |
|
0-845-69207-1 |
Francesco Baleno |
VB.Net |
3200.00 |
|
Book_Reviews
ISBN |
Reviews |
0-623-54125-7 |
|
0-320-55200-5 |
|
0-845-69207-1 |
|
ภาพ 7.7 เพิ่มคอลัมน์ วิจารณ์หนังสือ สามารถเพิ่มคอลัมน์ Reviews ที่ตารางข้อมูล Book หรือ เพิ่มตารางข้อมูลสำหรับการวิจารณ์หนังสือ
หมายเหตุ การออกแบบนี้มีพื้นฐาน จากความคิดว่ามีนักวิจารณ์ภายในคนเดียว ถ้าต้องการให้มีบุคคลอื่นวิจารณ์ ก็สามารถเพิ่ม customerid ลงในตารางข้อมูล book_reviews
สรุปประเภทตารางข้อมูล
ตามปกติ เมื่อเสร็จสิ้น การออกแบบฐานข้อมูลแล้ว จะพบตารางข้อมูล 2 ชนิด
ตารางพื้นฐานใช้อธิบายอ๊อบเจคในโลกจริง ตารางเหล่านี้จะมีคีย์ที่เชื่อมต่อกับอ๊อบเจคพื้นฐานอื่น โดยความสัมพันธ์แบบ หนึ่งต่อหนึ่ง หรือ หนึ่งต่อหลาย ตัวอย่างเช่น ลูกค้า 1 คน อาจจะมีหลายใบสั่งซื้อ แต่ 1 ใบสั่งซื้อได้รับการวางโดยลูกค้า 1 คน ดังนั้น ต้องวางการอ้างอิงไปยังลูกค้าในใบสั่งซื้อ
ตารางเชื่อมโยงใช้อธิบาย ความสัมพันธ์แบบ หลายต่อหลาย ของอ๊อบเจคจริง 2 ชุด เช่น ความสัมพันธ์ระหว่าง orders กับ books ตารางเหล่านี้ มักจะสัมพันธ์กับทรานแซคชันบางชนิดในโลกจริง
|
