บทที่ 3 แบบจ ำลองฐำนข้อมูลเชิง...

39 886301-ฐานข้อมูล โดย อ.ดร. โกเมศ อัมพวัน

บทที่ 3 แบบจ ำลองฐำนข้อมูลเชิงสัมพันธ์ วัตถุประสงคข์องบทเรียน ศึกษาเก่ียวกับส่วนประกอบพื้นฐานของแบบจ าลองข้อมูลเชิงสัมพันธ์

ศึกษาเก่ียวกับแนวความคิดของการประยุกต์ใช้แถวและคอลัมน์ในการจัดเก็บข้อมูล

ศึกษาการด าเนินการสร้างตารางต่างๆในระบบจัดการฐานข้อมูลเชิงสัมพันธ์

ศึกษาเก่ียวกับตัวด าเนินการต่างบนฐานข้อมูลเชิงสัมพันธ์

ศึกษาเก่ียวกับพจนานุกรมข้อมูลและบันทึกต่างๆของระบบ

ศึกษาเก่ียวกับวิธีการในการจัดการกับความซ้ าซ้อนของข้อมูล

ศึกษาเก่ียวกับความส าคัญของการสร้างดัชนี

เนื้อหำของบทเรียน

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

กิจกรรมกำรเรียน-กำรสอน อธิบายพร้อมยกตัวอย่างประกอบ

ศึกษาจากเอกสารค าสอน

ฝึกปฏิบัติการตามท่ีมอบหมาย

ท าแบบฝึกหัดท้ายบท

อุปกรณ์ที่ใช้ในกำรเรียน-กำรสอน เอกสารค าสอน

เครื่องคอมพิวเตอร์

เครื่องฉายภาพสไลด์

กำรวัดและประเมินผล การตอบค าถามระหว่างการเรียน-การสอน

การท าแบบทดสอบย่อยท้ายบท

การตรวจงานตามที่มอบหมาย


จากเนื้อหาในบทที่ 1 เราได้ท าการศึกษาเกี่ยวกับแนวความคิดพ้ืนฐานของฐานข้อมูลเพ่ือใช้ในการจัดเก็บและจัดการกับข้อมูลและเมตาดาต้า นอกจากนั้นเรายังท าการศึกษาเกี่ยวกับการจัดการและการควบคุมการเข้าถึงข้อมูลของระบบจัดการฐานข้อมูลที่ซึ่งจะสามารถลดทอนข้อจ ากัดของระบบแฟ้มข้อมูล และเนื้อหาในบทที่ 2 จะท าให้เราได้ศึกษาเกี่ยวกับแบบจ าลองข้อมูลชนิดต่างๆที่จะมีข้อดี-เสียที่แตกต่างกัน อาทิเช่น แบบจ าลองข้อมูลแบบล าดับชั้น แบบจ าลองข้อมูลแบบเครือข่าย แบบจ าลองข้อมูลเชิงสัมพันธ์ แบบจ าลองข้อมูลเชิงสัมพันธ์เอ็นทิตี้ และแบบจ าลองข้อมูลเชิงวัตถุ ตามล าดับ จากเนื้อหาทั้งสองบทข้างต้น ในบทนี้เราจะท าการศึกษาเกี่ยวกับแบบจ าลองข้อมูลเชิงสัมพันธ์ที่ซึ่งเป็นต้นแบบที่ส าคัญและได้รับความนิยมในการออกแบบฐานข้อมูลตั้งแต่อดีตจนถึงปัจจุบัน การประยุกต์ใช้แบบจ าลองข้อมูลเชิงสัมพันธ์จะยินยอมให้ผู้ออกแบบฐานข้อมูลมุ่งเน้นที่การออกแบบโครงสร้างในการจัดเก็บข้อมูลและความสัมพันธ์ของข้อมูลเหล่านั้น (logical representation) มากกว่าการออกแบบหรือการคิดค้นวิธีการต่างๆในการจัดเก็บข้อมูล (physical storage details)

3.1 มุมมองเชิงตรรกะของข้อมูล แบบจ าลองข้อมูลเชิงสัมพันธ์จะท าการประยุกต์ใช้ตารางข้อมูลในการจัดเก็บข้อมูลที่ซึ่ งสามารถ

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

3.1.1 ตำรำงและลักษณะของตำรำง มุมมองเชิงตรรกะของฐานข้อมูลเชิงสัมพันธ์จะเป็นมุมมองของการสร้างความสัมพันธ์ระหว่างข้อมูลภายใต้แนวความคิดของ “relation” แต่ด้วยนิยามพ้ืนฐานของ relation จะมาจากนิยามทางคณิตศาสตร์ ดังนั้น ถ้าเราพิจารณา relation ในรูปแบบของตารางข้อมูลจะช่วยให้เข้าใจได้ง่ายขึ้น ตารางข้อมูลหนึ่งๆจะเป็นโครงสร้างสองมิติประกอบด้วยแถวและคอลัมน์ อีกนัยหนึ่ง ตารางข้อมูลหนึ่งๆอาจถูกเรียกว่า “relation” relation หนึ่งๆ (ตารางหนึ่งๆ) อาจบรรจุข้อมูลอยู่เป็นจ านวนมากเพ่ือน าข้อมูลเหล่านั้นไปใช้งานในอนาคต ตัวอย่างเช่น ตารางข้อมูลนักเรียน (STUDENT) จะมีข้อมูลนักเรียนปรากฏ (entity occurrence) อยู่เป็นจ านวนมาก การปรากฏขึ้นของข้อมูลครั้งหนึ่งๆจะแทนข้อมูลนักเรียนคนหนึ่งๆ ดังนั้นจากนิยามและลักษณะของตารางข้อมูลข้างต้น เราสามารถสรุปลักษณะของตารางข้อมูลภายใต้ฐานข้อมูลเชิงสัมพันธ์ได้ดังนี้

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

แต่ละแถวข้อมูลในตารางข้อมูลจะถูกเรียกว่า “tuple” ที่ซึ่งจะแสดงถึงการปรากฏขึ้นของข้อมูลครั้งหนึ่งๆ

แต่ละคอลัมน์ในตารางข้อมูลจะแสดงถึงแอทริบิวหนึ่งๆที่ซึ่งจะมีชื่อคอลัมน์ (แอทริบิว) ไม่ซ้ ากัน

ค่าท้ังหมดที่ปรากฏในคอลัมน์หนึ่งๆจะต้องสอดคล้องกับรูปแบบที่ใช้ในการจัดเก็บข้อมูล


แต่ละคอลัมน์จะมีการก าหนดช่วงของค่าที่สามารถปรากฏได้ในคอลัมน์นั้นๆ ที่ซึ่งจะเรียกว่า ขอบเขตของแอทริบิว (attribute domain)

ล าดับของแถวและคอลัมน์จะไม่มีความส าคัญในระบบจัดการฐานข้อมูล

แต่ละตารางจะมีแอทริบิวหนึ่งๆหรือกลุ่มของแอทริบิวที่ซึ่งระบุถึงข้อมูลแถวหนึ่งๆ

จากลักษณะของตารางข้างต้น ลองพิจารณาตารางข้อมูลนักเรียน (STUDENT) ในรูป 3.1 ที่จะท าให้เราเข้าใจเก่ียวกับลักษณะของตารางข้อมูลมากข้ึนดังนี้

รูปที่ 3.1 ตัวอย่างตารางข้อมูลนักเรียน (STUDENT)

1. ตาราง STUDENT จะเป็นโครงสร้างสองมิติที่ประกอบไปด้วย 8 แถว (tuple) และ 12 คอลัมน์ (แอทริบิว)

2. แต่ละแถวในตาราง STUDENT จะแสดงถึงการปรากฏขึ้นครั้งหนึ่งๆของข้อมูลที่ซึ่งจะแสดงถึงข้อมูลนักเรียนคนหนึ่งๆ ตัวอย่างเช่น แถวที่ 4 ในตาราง STUDENT จะเป็นข้อมูลนักเรียนชื่อ Walter H. Oblonski ดังนั้นจากการที่ตาราง STUDENT มีข้อมูลทั้งสิ้น 8 แถว จะท าให้ตาราง STUDENT มีข้อมูลนักเรียนทั้งสิ้น 8 คน

3. แต่ละคอลัมน์ (แอทริบิว) ในตาราง STUDENT จะมีชื่อคอลัมน์ที่ไม่ซ้ ากัน 4. ทุกค่าที่ปรากฏในคอลัมน์หนึ่งๆจะสอดคล้องกับรูปแบบข้อมูลของแอทริบิวนั้นๆ ตัวอย่ างเช่น ข้อมูล

เกรดเฉลี่ยของนิสิต (STU_GPA) จะเป็นข้อมูลตัวเลขทศนิยมสองต าแหน่งที่บ่งบอกถึงเกรดเฉลี่ยของนิสิตแต่ละคน รูปแบบของข้อมูลในแอทริบิวหนึ่งๆจะขึ้นกับชนิดของข้อมูล ดังนี้

ข้อมูลเชิงตัวเลข เช่น STU_HRS และ STU_GPA

ข้อมูลตัวอักษร/ข้อความ เช่น STU_CLASS และ STU_PHONE

ข้อมูลวันที่ เช่น STU_DOB


ข้อมูลเชิงตรรกะ (ถูกหรือผิด) เช่น STU_TRANSFER 5. แต่ละแอทริบิวจะมีขอบเขตข้อมูลของแอทริบิว เช่น แอทริบิว STU_GPA จะมีขอบเขตข้อมูลอยู่

ระหว่าง 0.0 – 4.0 6. ล าดับของแถวและคอลัมน์จะไม่มีความส าคัญ 7. แต่ละตารางข้อมูลจะต้องมีคีย์ primary key (PK) ที่ซึ่งจะเป็นแอทริบิวหนึ่งๆที่มีค่าที่ปรากฏขึ้นแบบ

ไม่ซ้ ากัน เช่น แอทริบิว STU_NUM จะสามารถถูกก าหนดเป็น primary key ของตาราง STUDENT ได้ เนื่องจากจะเป็นข้อมูลรหัสนักเรียนที่มีค่าไม่ซ้ ากัน

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

คีย์หนึ่งๆจะเป็นแอทริบิวหนึ่งๆหรืออาจเป็นกลุ่มของแอทริบิวที่มีอิทธิพลต่อแอทริบิ วอ่ืนๆในตารางข้อมูล เช่น แอทริบิวหมายเลขใบแจ้งหนี้หนึ่งๆจะสามารถถูกใช้ในการระบุถึงรายละเอียดของข้อมูล (แอทริบิว) ต่างๆที่เกี่ยวข้องกับการสั่งซื้อสินค้าครั้งหนึ่งๆได้ทั้งหมด คีย์แรกที่มีความส าคัญเป็นอย่างมากคือ primary key (PK) จะเป็นแอทริบิวหนึ่งๆหรือกลุ่มของแอทริบิวที่มีการปรากฏขึ้นของข้อมูลไม่ซ้ ากัน ที่ซึ่งจะเป็นคีย์ที่ใช้ในการแยกความแตกต่างระหว่างแถวของข้อมูล (ตาราง STUDENT ในรูปที่ 3.1 จะก าหนดให้แอทริบิว STU_NUM เป็น primary key เนื่องจาก จะไม่มีนักเรียนคนใดๆที่มีรหัสนักเรียนซ้ ากันกับนักเรียนคนอ่ืนๆ)

บทบาทและหน้าที่ของคีย์ต่างๆจะตั้งอยู่บนพ้ืนฐานของ “determination” ดังนั้น ในการพิจารณาแอทริบิวต่างๆของตารางข้อมูลในฐานข้อมูลมักจะท าการพิจารณาเกี่ยวกับ “A determines B” ที่ซึ่งจะแสดงถึงกรณีที่เราทราบถึงค่าที่ปรากฏในแอทริบิว A แล้วจะช่วยให้เราสามารถอ้างอิงถึงข้อมูลในแอทริบิว B ได้ ตัวอย่างเช่น ถ้าเราทราบถึงค่าที่ปรากฏในแอทริบิว STU_NUM (รหัสนิสิต) ในตาราง STUDENT จะท าให้เราสามารถค้นหา ชื่อ-สุกุล เกรดเฉลี่ย เบอร์โทรศัพท์ และข้อมูลอ่ืนๆของนิสิตได้ การแสดงถึง “A determines

B” จะสามารถเขียนอยู่ในเชิงคณิตศาสตร์ได้เป็น “AB” และเมื่อไรก็ตามที่ “A determines B,C และ D”

เราจะสามารถแสดงสัญลักษณ์ได้เป็น “AB,C,D” ดังนั้น ถ้าเราต้องการที่จะพิจารณาเกี่ยวกับ “STU_NUM

determines STU_LNAME” เราจะสามารถแสดงสัญลักษณ์ได้เป็น “STU_NUMSTU_LNAME” แต่ในทางกลับกัน เราไม่สามารถประยุกต์ใช้แอทริบิว STU_LNAME ในการอ้างถึงแอทริบิว STU_NUM ได้


เนื่องจากอาจมีนักเรียนมากกว่าหนึ่งคนที่มีนามสกุลเหมือนกันที่ซึ่งจะท าให้เราไม่สมารถอ้างถึงรหัสของนักเรียนคนหนึ่งๆได้

หลักการเกี่ยวกับ “determination” ข้างต้นจะมีความส าคัญค่อนข้างมากในการนิยาม “functional dependence” ที่จะหมายถึง “แอทริบิว B จะมีการพ่ึงพาอาศัยแอทริบิว A ถ้าแต่ละค่าของข้อมูลที่ปรากฏในแอทริบิว A สามารถอ้างถึงค่าที่ปรากฏในแอทริบิว B ได้เพียงค่าเดียวเท่านั้น” ตัวอย่างเช่น จากข้อมูลในรูป 3.1 เราจะสังเกตุได้ว่าแอทริบิว STU_PHONE จะมีการพ่ึงพาอาศัยแอทริบิว STU_NUM ที่ซึ่งข้อมูลรหัสนักเรียนหนึ่งๆจะสามารถอ้างถึงเบอร์โทรศัพท์หนึ่งๆของนักเรียนได้—รหัสนักเรียน 321452 จะสามารถอ้างถึงเบอร์โทรศัพท์ 2134 ได้ แต่ในทางกลับกัน แอทริบิว STU_NUM จะไม่มีการพ่ึงพาอาศัยแอทริบิว STU_PHONE เนื่องจากเบอร์โทรศัพท์ 2267 จะมีความเกี่ยวเนื่องกับนักเรียนที่มีรหัส 324274 และ 324291 ที่ซึ่งจะไม่ตรงตามนิยามของ functional dependence ที่ซึ่งจะต้องอ้างถึงค่าที่ปรากฏในแอทริบิว STU_NUM เพียงค่าเดียวเท่านั้น

การประยุกต์ใช้แอทริบิวหนึ่งๆในการก าหนด functional dependence อาจท าให้เกิดปัญหาการอ้างถึงค่าที่ปรากฏหลายค่า ดังนั้นเราอาจท าการประยุกต์ ใช้แอทริบิวมากกว่าหนึ่งแอทริบิวในการนิยาม functional dependence ให้กับแอทริบิวต่างๆ ที่ซึ่งจะมีลักษณะโดยนัยเหมือนกับการสร้างคีย์จากกลุ่มของแอทริบิวที่ซึ่งจะเรียกว่า composite key โดยแอทริบิวหนึ่งๆที่เป็นส่วนประกอบของ composite key จะถูกเรียกว่า key attribute ตัวอย่างเช่น ถ้าเราต้องการก าหนดให้แอทริบิวนามสกุลเป็น primary key ให้กับตาราง STUDENT ในรูป 3.1 การประยุกต์ใช้เพียงแอทริบิวนามสกุลเพียงแอทริบิวเดียวอาจไม่เพียงพอ เนื่องจากอาจมีนักเรียนมากกว่าหนึ่งคนที่มีนามสกุลเหมือนกัน ดังนั้น ถ้าเราท าการสร้าง primary key จากการรวมแอทริบิวต่างๆเข้าด้วยกัน จะท าให้เราสามารถอ้างถึงข้อมูลส่วนต่างๆได้อย่างเป็นเอกลักษณ์ เช่น

“STU_LNAME, STU_FNAME, STU_INIT, STU_PHONESTU_HRS, STUCLASS, STU_GPA, STU_DOB”

จากแนวคิดของการก าหนด composite key เราจะสามารถปรับเปลี่ยนนิยามของ functional dependence ได้เป็น “full functional dependence” ที่ซึ่งจะนิยามได้เป็น “ถ้าแอทริบิว B หนึ่งๆมีการพ่ึงพาอาศัย composite key (A) ที่ซึ่ง B จะไม่สามารถพ่ึงพาอาศัยกลุ่มของแอทริบิวที่เป็นสับเซตของ A แล้ว เราจะสามารถสรุปได้ว่า แอทริบิว B จะมีการพ่ึงพาอาศัย composite key A” จากนิยามดังกล่าว เราสามารถก าหนดนิยามเกี่ยวกับ “superkey” ที่ซึ่งจะเป็นคีย์ที่สามารถแสดงความเป็นเอกลักษณ์ของข้อมูลแถวหนึ่งๆได้ ตัวอย่างเช่น <STU_NUM>, <STU_NUM, STU_LNAME> และ <STU_NUM, STU_LNAME, STU_INIT> เป็นต้น (ในความเป็นจริงแล้วแอทริบิว STU_NUM เพียงแอทริบิวเดียวก็สามารถเป็น superkey ได้ เนื่องจากสามารถแสดงความเป็นเอกลักษณ์ของแถวข้อมูลหนึ่งๆได้ การเพ่ิมแอริบิวอ่ืนๆเพ่ือสร้างเป็น superkey จะท าให้เกิดความซ ้าซ้อนเกิดข้ึน)


จากความซ้ าซ้อนที่อาจเกิดขึ้นกับการสร้าง superkey จึงท าให้เกิดแนวความคิดที่จะลดทอนความซ้ าซ้อนนั้นๆด้วยการก าหนดและประยุกต์ใช้นิยาม “candidate key” ที่ซึ่งจะเป็น superkey ที่จะไม่มีความซ้ าซ้อน ตัวอย่างเช่น composite key <STU_NUM, STU_LNAME> จะเป็น superkey ที่ซึ่งสามารถแสดงเอกลักษณ์ของแถวข้อมูลหนึ่งๆได้ แต่คีย์ร่วมนี้จะไม่มีคุณสมบัติเป็น candidate key เนื่องจากการประยุกต์ใช้แอทริบิว STU_NUM เพียงแอทริบิวเดียวก็สามารถแสดงความเป็นเอกลักษณ์ของแถวข้อมูลหนึ่งๆได้ แต่ถ้าเราท าการก าหนดให้แอทริบิว STU_NUM เป็น superkey แอทริบิว STU_NUM จะเป็น candidate key ด้วยเช่นกัน

จากนิยามเกี่ยวกับคีย์ต่างๆทั้งหมดข้างต้น เราสามารถสรุปได้ว่า primary key ที่ดีควรจะต้องมีคุณสมบัติเป็น candidate key ที่ซึ่งไม่มีความซ้ าซ้อนและสามารถแสดงเอกลักษณ์ของแถวข้อมูลหนึ่งๆได้ ดังนั้น เราสามารถกล่าวได้ว่า “primary key จะเป็น super key และเป็น candidate key ด้วยเช่นกัน” จากการก าหนด primary key ภายในตารางข้อมูลหนึ่งๆจะท าให้ข้อมูลแต่ละแถวจะมีความเป็นเอกลักษณ์ ซึ่งจากคุณสมบัติดังกล่าวของตารางข้อมูล เราสามารถกล่าวได้ว่าตารางนั้นๆจะมีคุณสมบัติ “entity integrity” ดังนั้น เพ่ือที่จะท าให้ตารางหนึ่งๆมีคุณสมบัติ entity integrity เราจะไม่สามารถยอมให้มี NULL (การไม่มีค่าของข้อมูล) ปรากฏในแอทริบิวที่เป็น primary key เลย

การมี NULL เกิดขึ้นในแอทริบิวที่ท าหน้าที่เป็น primary key จะท าให้เราไม่สามารถแสดงความเป็นเอกลักษณ์ของแถวข้อมูลหนึ่งๆได้ ดังนั้น เราควรที่จะหลีกการปรากฏขึ้นของค่า NULL ในแอทริบิวหนึ่งๆ การปรากฏขึ้นของค่า NULL อาจท าให้เกิดปัญหาขึ้นได้ เช่น การไม่ทราบค่าที่ปรากฏในแอทริบิว (ในแอทริบิวที่มีค่าเชิงตัวเลข ถ้ายอมให้มี NULL จะท าให้เกิดความคลาดเคลื่อนในการหาค่าผลรวม ค่าเฉลี่ย และอ่ืนๆ)

การควบคุมความซ้ าซ้อนทั้งกับข้อมูลและคีย์ต่างๆจะท าให้ฐานข้อมูลเชิงสัมพันธ์สามารถท างานได้อย่างมีประสิทธิภาพ ดังนั้นถ้าเราท าการสร้างตารางข้อมูลต่างๆที่มีแอทริบิวที่มีความแอทริบิวเหมือนกันบางส่วน แอทริบิวที่เหมือนกันจะสามารถถูกใช้เป็นตัวเชื่อมข้อมูลในตารางต่างๆเข้าด้วยกัน ตัวอย่างเช่น ตาราง PRODUCT และ ตาราง VENDOR ในรูป 3.2 ที่มีแอทริบิวเหมือนกันหนึ่งแอทริบิว คือ VEND_CODE ซึ่งจากการที่ตาราง PRODUCT มีแอทริบิว VEND_CODE บรรจุอยู่จะท าให้เราสามารถทราบถึงบริษัทที่ท าการผลิตสินค้าได้ เมื่อเราท าการสังเกตุข้อมูลในตาราง PRODUCT เราจะสังเกตุได้ว่ามี VEND_CODE ที่มีค่า 232 และ 235 ปรากฏมากกว่าหนึ่งครั้ง ซึ่งจากการปรากฏของ VEND_CODE จะท าให้เราทราบถึงความสัมพันธ์ระหว่าง VENDOR และ PRODUCT ที่ซึ่งจะมีลักษณะเป็น 1:M ที่ซึ่งจะหมายถึง VENDOR หนึ่งๆสามารถผลิตสินค้าได้มากกว่าหนึ่งชนิด แต่สินค้าชนิดหนึ่งๆจะถูกผลิตจาก VENDOR เดียวเท่านั้น และ เมื่อเราพิจารณาเกี่ยวกับปรากฏขึ้นของ VEND_CODE ที่มีค่าของข้อมูลเหมือนกันหลายครั้ง เราจะสามารถบอกกล่าวได้ว่าข้อมูลความซ้ าซ้อนเกิดข้ึนหรือไม่ ค าตอบคือไม่ซ้ าซ้อน เนื่องจากการปรากฏขึ้นของค่าในแอทริบิว VEND_CODE จะสามารถแสดงได้ถึงความสัมพันธ์ระหว่าง VENDOR และ PRODUCT แต่เมื่อไรก็ตามที่มีข้อมูลที่ไม่จ าเป็นซ้ าซ้อนกัน เราจะสามารถสรุปได้ว่าฐานข้อมูลมีความซ้ าซ้อนของข้อมูล


จากรูป 3.2 เราจะสังเกตุได้ว่า VEND_CODE ที่ถูกจัดเก็บในตาราง PRODUCT จะสามารถเชื่อมโยงความสัมพันธ์/บ่งบอกถึงข้อมูลในตาราง VENDOR ได้ ตัวอย่างเช่น ในข้อมูลแถวสุดท้ายของตาราง PRODCUT จะมีค่าของข้อมูลในแอทริบิว VEND_CODE เท่ากับ 235 จากการเชื่อมโยงความสัมพันธ์ เราจะทราบได้ว่า ถ้าเรามีปัญหา (หรือต้องการทราบรายละเอียดเพ่ิมเติม) เกี่ยวกับรายการสินค้ารหัส ZZX/32450 เราจะสามารถติดต่อได้ที่ VEND_CODE 235 ซึ่งก็คือ Henry Ortozo ที่อยู่ในเขตหรัส 615 หรืออาจโทรศัพท์ติดต่อได้เที่เบอร์ 899-3425

จากบทที่ 2 เราจะทราบได้ว่าการออกแบบฐานข้อมูลเชิงสัมพันธ์จะถูกแสดงได้ด้วย relational schema ที่ซึ่งจะแสดงข้อความรายละเอียดของโครงสร้างตารางข้อมูล โดยตารางข้อมูลในรูป 3.2 จะสามารถแสดงในรูปแบบของ relational schema ได้ดังนี ้

รูปที่ 3.2 ตัวอย่างฐานข้อมูลเชิงสัมพันธ์อย่างง่าย

VENDOR (VEND_CODE, VEND_CONTACT, VEND_AREACODE, VEND_PHONE)

PRODUCT (PROD_CODE, PROD_DESCRIPT, PROD_PRICE, PROD_ON_HAND, VEND_CODE)

จาก relational schema ข้างต้น เราจะเห็นว่าแอทริบิวที่เป็น primary key ของตารางหนึ่งๆจะถูกขีดเส้นใต้ แต่ส าหรับการเชื่อมโยงความสัมพันธ์ระหว่าตาราง PRODUCT และ VENDOR จะถูกแสดงใน relational diagram ดังรูปที่ 3.3 โดยจากรูปจะแสดงการเชื่อมโยงความสัมพันธ์ด้วยเส้นเชื่อมระหว่างตารางทั้งสอง ดังนั้นเมื่อเราท าการพิจารณา relational diagram ใดๆก็ตาม เราจะสามารถทราบถึงการเชื่อมโยงความสัมพันธ์ระหว่างสองตารางข้อมูลใดๆได้จากเส้นที่เชื่อมระหว่างสองตารางข้อมูลนั้นๆ


รูปที่ 3.3 ตัวอย่าง relational diagram ของตาราง VENDOR และ PRODUCT

การที่จะเชื่อมโยงความสัมพันธ์ระหว่างสองตารางข้อมูลใดๆจะสามารถด าเนินการได้ด้วยการจัดเก็บแอทริบิวที่เหมือนกันไว้ในทั้งสองตาราง โดยแอทริบิวที่ปรากฏในทั้งสองตารางจะท าหน้าที่แตกต่างกัน เ ช่น แอทริบิว VEND_CODE ในตาราง VENDOR ในรูป 3.3 จะท าหน้าที่เป็น primary key แต่ในส่วนของแอทริบิว VEND_CODE ในตาราง PRODUCT จะท าหน้าเป็น foreign key (FK) ที่ซึ่งจะเป็นแอทริบิวที่มีความสอดคล้อง (เหมือนกันกับ) primary key ในตาราง VENDOR

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

นอกจากคีย์ทั้งหมดข้างต้นแล้ว ยังมีอีกคีย์หนึ่งที่มักถูกประยุกต์ใช้ในการออกแบบฐานข้อมูล นั่นคือ “secondary key” ที่ซึ่งจะเป็นคีย์ที่ใช้ในการควบคุม (เป็นเงื่อนไข) ในการค้นคืนข้อมูล สมมติว่าเราท าการจัดเก็บข้อมูลลูกค้าในตาราง CUSTOMER และท าการก าหนดให้แอทริบิวรหัสลูกค้าท าหน้าที่เป็น primary key แต่ในการท างานจริง ลูกค้าหรือพนักงานจะไม่สามารถจดจ ารหัสลูกค้าได้ ด้วยเหตุนี้เราอาจต้องท าการค้นหาข้อมูลลูกค้าจากนามสกุลและเบอร์โทรศัทพ์ของลูกค้า จากกรณีดังกล่าว เราสามารถก าหนดได้ว่ารหัสลูกค้าท าหน้าที่เป็น primary key และการรวมกันระหว่างนามสกุลและเบอร์โทรศัพท์ของลูกค้าจะท าหน้าที่เป็น secondary key (หมายเหตุ secondary key ไม่จ าเป็นต้องมีความสามารถในการแสดงเอกลักษณ์ของข้อมูลแถวหนึ่งๆ ตัวอย่างเช่น นามสกุลและเบอร์โทรศัพท์บ้านของลูกค้าอาจน ามาซึ่งข้อมูลเป็นจ านวนหลายแถวข้อมูล เนื่องจากบริษัทอาจมีลูกค้าที่อยู่ในครอบครัวเดียวกันหลายคน)

จากการก าหนดและการประยุกต์ใช้คีย์ต่างๆข้างต้น เราสามารถสรุปเกี่ยวกับนิยามของคีย์ต่างๆได้ดังรูปที่ 3.4


รูปที่ 3.4 คีย์ที่ถูกประยุกต์ใช้ในฐานข้อมูลเชิงสัมพันธ์

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

รูปที่ 3.5 กฎความสมบูรณ์ของข้อมูล

กฎความสมบูรณ์ของข้อมูลในรูป 3.5 จะแสดงได้ดังรูป 3.6 ที่ซึ่งจะแสดงถึง entity integrity โดยการพิจารณาจาก 1) primary key ของตาราง CUSTOMER ที่ซึ่งจะก าหนดจากแอทริบิว CUS_CODE และ 2) primary key ของตาราง AGENT ที่จะก าหนดจากแอทริบิว AGENT_CODE; จากการพิจารณา primary key ของทั้งสองตารางเราจะสังเกตุได้ว่าไม่มีค่า NULL ปรากฏในทั้งสองแอทริบิว

ในส่วนของ referential integrity จะสามารถพิจารณาได้จากการที่ตาราง CUSTOMER มี foreign key เป็นแอทริบิว AGENT_CODE ที่ซึ่งจะเป็นการเชื่อมโยงความสัมพันธ์ระหว่างตาราง CUSTOMER ไปยังตาราง AGENT


รูปที่ 3.6 ตัวอย่างตารางข้อมูลที่สอดคล้องกับกฎความสมบูรณ์

ในการที่จะหลีกเลี่ยงค่า NULL ผู้ออกแบบส่วนใหญ่มักจะท าการเลือกใช้โค้ดพิเศษ ซึ่งก็คือ flags เพ่ือแสดงถึงการขาดหายไปของค่า ดังนั้น ถ้าเราพิจารณาตารางข้อมูลในรูป 3.6 เราจะอาจท าการเลือกใช้โค้ด -99 ในการแทนการเกิด NULL ในแอทริบิว AGENT CODE ในตาราง CUSTOMER ดังแสดงตัวอย่างการใช้โค้ดเพ่ือแทน NULL ในตาราง AGENT ดังรูป 3.7

รูปที่ 3.7 กำรเพิ่มโค้ดพิเศษส ำหรับค่ำ NULL

นอกเหนือจากการประยุกต์ใช้ entity integrity และ referential integrity แล้ว เรายังสามารถเพ่ิมกฏความสมบูรณ์ของข้อูลในรูปแบบของ NOT NULL และ UNIQUE ได้ โดยเงื่อนไข NOT NULL สามารถก าหนดในแอทริบิวต่างๆเพ่ือท าให้ทุกแถวของข้อมูลในตารางข้อมูลจะไม่มี NULL (จะต้องมีค่าของข้อมูลปรากฏในทุกแถวข้อมูล แต่สามารถมีค่าซ้ ากันได้) แต่ในส่วนของเงื่อนไข UNIQUE จะเป็นการก าหนดให้คอลัมน์หนึ่งๆมีค่าของข้อมูลที่ไม่ซ้ ากัน

3.4 ตัวด ำเนินกำรเชิงสัมพันธ์ ในส่วนนี้จะเป็นการศึกษาเกี่ยวกับการจัดการขั้นพ้ืนฐานของแบบจ าลองข้อมูลเชิงสัมพันธ์ ที่ซึ่งจะอยู่

ภายใต้แนวคิดเกี่ยวกับ Relational algebra ทีซ่ึ่งจะเป็นนิยามเก่ียวกับวิธีในการจัดการกับข้อมูลโดยการประยกุต์ใช้ 8 ตัวด าเนินการเชิงสัมพันธ์ คือ SELECT, PROJECT, JOIN, INTERSECT, UNION, DIFFERENCE, PRODUCT และ DIVIDE โดยแต่ละตัวด าเนินการจะสามารถถูกประยุกต์ใช้ได้ดังนี้

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


สามารถท าได้สองกรณี คือ 1) การเรียกดูแถวข้อมูลทั้งหมด และ 2) การเรียกดูแถวของข้อมูลที่มีข้อมูลบางส่วนสอดคล้องกับเงื่อนไขที่ก าหนด

รูปที่ 3.8 ตัวอย่างการท างานของตัวด าเนินการ SELECT

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

รูปที่ 3.9 ตัวอย่างการท างานของตัวด าเนินการ PROJECT


3. UNION จะเป็นการด าเนินการที่มีแนวความคิดมาจากการยูเนียนบนเซตข้อมูล ดังนั้น ตัวด าเนินการนี้จะท าการรวมแถวของข้อมูลจากสองตารางที่มีโครงสร้างเหมือนกัน (มีแอทริบิวเหมือนกัน) เข้าด้วยกัน แต่ส าหรับแถวของข้อมูลที่มีข้อมูลซ้ ากันจะท าการแสดงผลเพียงแค่ครั้งเดียวเท่านั้น (ดังแสดงในรูปที่ 3.10)

รูปที่ 3.10 ตัวอย่างการท างานของตัวด าเนินการ UNION

4. INTERSECT จะเป็นการด าเนินการที่มาจากแนวความคิดของการอินเทอร์เซ็กชั่นบนเซตข้อมูล ดังนั้น การด าเนินการนี้จะท าการแสดงผลแถวของข้อมูลที่ปรากฏขึ้นทั้งสองตาราง โดยทั้งสองตารางนี้จะมีแอทริบิวที่เหมือนกันทั้งหมด (ดังแสดงในรูปที่ 3.11)

รูปที่ 3.11 ตัวอย่างการท างานของตัวด าเนินการ INTERSECT

5. DIFFERENCE จะเป็นการด าเนินการแสดงแถวของข้อมูลที่ปรากฏในตารางข้อมูลหนึ่งๆแต่ไม่ปรากฏในอีกตารางข้อมูลหนึ่งๆ การด าเนินการนี้จะเปรียบได้กับการแสดงผลลัพธ์ของการลบข้อมูลออกจากตารางข้อมูลหนึ่งๆด้วยข้อมูลตารางหนึ่งๆ (ดังแสดงในรูปที่ 3.12)

รูปที่ 3.12 ตัวอย่างการท างานของตัวด าเนินการ DIFFERENCE

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


เมื่อเราท าการรวมข้อมูลทุกแถวของตารางข้อมูล A เข้ากับตารางข้อมูล B จะท าให้เราได้ผลลัพธ์ทั้งสิ้น 18 แถวข้อมูล (ดังแสดงในรูปที่ 3.13)

รูปที่ 3.13 ตัวอย่างการท างานของตัวด าเนินการ PRODUCT

7. JOIN จะเป็นฟังก์ชันที่เป็นประโยชน์อย่างเห็นได้ชัดของการประยุกต์ใช้ฐานข้อมูลเชิงสัมพันธ์ การ JOIN จะเป็นการรวมข้อมูลจากสองตารางหรือมากกว่าสองตารางเข้าด้วยกัน ที่ซึ่งจะท าการเชื่อมโยงความสัมพันธ์ระหว่างตารางผ่านแอทริบิวที่เหมือนกัน ดังแสดงในรูป 3.14 ที่ซึ่งจะประกอบไปด้วยตารางข้อมูลลูกค้า (CUSTOMER) และตารางพนักงานขาย (AGENT) ที่ซึ่งจะมีแอทริบิว AGENT_CODE เหมือนกัน ดังนั้น เราจะใช้รูป 3.14 เป็นตัวอย่างในการด าเนินการ JOIN หลายประเภทที่ส าคัญ ดังนี้

รูปที่ 3.14 ตัวอย่างตารางที่จะใช้แสดงตัวอย่างของการ JOIN

a. Natural join จะท าการเชื่อมโยงความสัมพันธ์ระหว่างตารางโดยท าการเลือกเฉพาะแถวข้อมูลที่มีค่าในแอทริบิวเหมือนกันในแอทริบิวที่มีการเชื่อมโยงกัน (แอทริบิวที่เหมือนกัน) การด าเนินการ natural join จะประกอบไปด้วย 3 ขั้นตอนหลัก คือ

i. ท าการประยุกต์ใช้ตัวด าเนินการ PRODUCT กับตาราง CUSTOMER และ AGENT (จะได้ผลลัพธ์ดังแสดงในรูปที่ 3.15)

ii. ท าการประยุกต์ใช้ตัวด าเนินการ SELECT กับผลลัพธ์ที่ได้ในข้อที่ (i) โดยท าการเลือกเฉพาะแถวของข้อมูลที่มีค่าในแอทริบิว AGENT_CODE เหมือนกัน (ดังแสดง


ในรูป 3.16) แอทริบิว AGENT_CODE ที่ปรากฏทั้งสองตารางจะถูกเรียกว่า join columns

iii. ท าการประยุกต์ใช้ตัวด าเนินการ PROJECT กับผลลัพธ์ที่ได้จากข้อ (ii) ที่ซึ่งจะท าการแสดงผลข้อมูลเฉพาะแอทริบิวที่ผู้ใช้ต้องการเท่านั้น (ดังแสดงในรูป 3.17)

รูปที่ 3.15 ขั้นตอนที่ 1 ของ NATURAL JOIN: PRODUCT

รูปที่ 3. 16 ขั้นตอนที่ 2 ของ NATURAL JOIN: SELECT

รูปที่ 3. 17 ขั้นตอนที่ 3 ของ NATURAL JOIN: PROJECT


b. Inner join จะเป็นการเชื่อมโยงความสัมพันธ์ที่ซึ่งจะท าการคืนค่าผลลัพธ์เฉพาะเรคคอร์ดของข้อมูลที่มีการเชื่อมโยงกันระหว่างตารางเท่านั้น แต่ในขณะที่ outer join จะคืนค่าเรค คอร์ดที่มีการเชื่อมโยงกัน และยังรวมถึงเรคคอร์ดที่ไม่มีการเชื่อมโยงด้วยเช่นกัน จากข้างต้น เราสามารถสรุปได้ว่า outer join นั้นจะมีลักษณะเป็น “inner join plus” ที่ซึ่งจะเป็นการด าเนินการ inner join ผนวกกับการพิจารณาเรคคอร์ดของข้อมูลที่ไม่มีการเชื่อมโยงกัน ดังนั้น เมื่อเราท าการพิจารณาตารางข้อมูล CUSTOMER และ AGENT ในรูป 3.14 เราจะสามารถด าเนินการ outer join ได้สองวิธีคือ 1) left outer join ที่ซึ่งจะค้นหาข้อมูลทุกแถวข้อมูลในตาราง CUSTOMER ที่ซึ่งจะรวมถึงเรคคอร์ดของข้อมูลที่ไม่มีการเชื่อมโยงความสัมพันธ์กับตาราง AGENT ดังแสดงตัวอย่างในรูป 3.18 หรือ 2) right outer join ที่ซึ่งจะท าการค้นหาข้อมูลทุกแถวข้อมูลในตาราง AGENT ที่ซึ่งจะรวมถึงเรคคอร์ดของข้อมูลที่ไม่มีการเชื่อมโยงความสัมพันธ์กับตาราง CUSTOMER ดังแสดงตัวอย่างในรูป 3.19

รูปที่ 3.18 ตัวอย่างการท า left outer join

รูปที่ 3.19 ตัวอย่างการท า right outer join

8. DIVIDE จะท าการประยุกต์ใช้ตารางข้อมูลที่มีข้อมูลเพียงคอลัมน์เดียว (เช่น คอลัมน์ “a”) เพ่ือเป็นตัวหาร และท าการประยุกต์ใช้ตารางข้อมูลที่มีข้อมูลสองคอลัมน์ (เช่น คอลัมน์ “a” และ “b”) เป็นตัวตั้งส าหรับการหาร โดยที่ทั้งสองตารางจะมีคอลัมน์ที่เหมือนกัน (เช่น คอลัมน์ “a”) โดยผลลัพธ์ที่ได้จากการด าเนินการ DIVIDE จะเป็นคอลัมน์เดียวที่ค่าในคอลัมน์ในตารางตัวตั้งที่มีแอทริบิวไม่เหมือนกับตารางตัวหาร โดยเรคคอร์ดที่ถูกคืนค่าจะต้องเป็นเรคคอร์ดที่สอดคล้องกับทุกค่าในตารางที่เป็นตัวหาร ดังแสดงในรูปที่ 3.20


รูปที่ 3.20 ตัวอย่างการท า DIVIDE

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

บันทึกต่างๆของระบบ (system catalog) จะมีลักษณะคล้ายกับเมตาดาต้าที่ซึ่งจะเป็นค าอธิบายรายละเอียดของสิ่งต่างๆในฐานข้อมูล เช่น ข้อมูลเกี่ยวกับชื่อตาราง ข้อมูลผู้ที่ท าการสร้างตารางและวันที่ท าการสร้างตาราง ข้อมูลจ านวนคอลัมน์ในแต่ละตาราง ข้อมูลชนิดของข้อมูลที่สอดคล้องกับแต่ละคอลัมน์ในตารางข้อมูล ข้อมูลชื่อแฟ้มข้อมูลที่มีการสร้างดัชนี ข้อมูลผู้ที่ท าการสร้างดัชนี และสิทธิ์ในการใช้ข้อมูล จากข้อมูลข้างต้น เราจะเห็นว่าบันทึกต่างๆของระบบจะเป็นข้อมูลที่ค่อนข้างส าคัญและจ าเป็นต่อการสร้างฐานข้อมูล ด้วยเหตุนี้จึงเป็นเหตุให้ซอร์ฟแวร์ฐานข้อมูลเชิงสัมพันธ์ต่างๆมักจะมีการจัดเตรียมการบันทึกข้อมูลต่างๆของระบบที่ซึ่งจะสามารถช่วยอ านวยความสะดวกแก่ผู้ใช้ฐานข้อมูลและผู้ออกแบบและ /หรือผู้สร้างฐานข้อมูล


รูปที่ 3.21 ตัวอย่างพจนานุกรมข้อมูลอย่างง่าย


3.6 รูปแบบควำมสัมพันธ์ภำยในฐำนข้อมูลเชิงสัมพันธ์ จากบทที่แล้ว เราได้ทราบว่าความสัมพันธ์ที่เกิดกับทุกสิ่งบนโลกจะสามารถแบ่งเป็นหมวดหมู่ได้เป็น one-to-one (1:1), one-to-many (1:M) และ many-to-many (M:N หรือ M:M) ตามล าดับ ดังนั้น ในส่วนนี้จะเป็นการแสดงให้เห็นว่าความสัมพันธ์เหล่านี้จะสามารถมีส่วนจะช่วยให้เราเลือกใช้หรือเลือกที่จะแสดงความสัมพันธ์ของข้อมูลได้อย่างถูกต้อง โดยในการเลือกการแสดงความสัมพันธ์เราควรที่จะค าถึงนึงประเด็นต่างๆดังนี ้

ความสัมพันธ์แบบ one-to-many จะเป็นรูปแบบความสัมพันธ์ในอุดมคติ ที่ซึ่งความสัมพันธ์ลักษณะนี้จะเป็นมาตราฐานในการออกแบบฐานข้อมูลเชิงสัมพันธ์ใดๆ

ความสัมพันธ์แบบ one-to-one จะปรากฏขึ้นน้อยในทุกๆการออกแบบฐานข้อมูลเชิงสัมพันธ์

ความสัมพันธ์แบบ many-to-many จะไม่สามารถแสดงได้ด้วยแบบจ าลองข้อมูลเชิงสัมพันธ์ ดังนั้นเราควรที่จะท าการแปลงรูปแบบความสัมพันธ์จาก many-to-many ไปเป็น one-to-many จึงจะสามารถจัดเก็บข้อมูลได ้

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

ผลงานแต่ละชิ้นจะต้องถูกรังสรรค์จากจิตรกรเพียงคนเดียวเท่านั้น แต่จิตกรแต่ละคนจะสามารถสร้างสรรค์ผลงานได้หลายชิ้น จิตรกร Georgette P. Ross ที่มีรหัสเท่ากับ 123 ได้สร้างสรรค์ผลงานทั้งหมด 3 ชิ้นด้วยกัน

ข้อมูลเกี่ยวกับจิตกรจะมีเพียงแค่แถวเดียวในตาราง PAINTER ที่มีความเกี่ยวเนื่องกับข้อมูลแถวหนึ่งๆในตาราง PAINTING แต่ทางกลับกัน อาจมีข้อมูลเกี่ยวกับผลงานหลายชิ้นในตาราง PAINTING ที่มีความเกี่ยวเนื่องกับข้อมูลแถวหนึ่งๆในตาราง PAINTER

รูปที่ 3.22 ตัวอย่างความสัมพันธ์แบบ 1:M


รูปที่ 3.23 ตัวอย่างการจัดเก็บข้อมูลภายใต้ความสัมพันธ์แบบ 1:M

จากตัวอย่างข้างต้นจะสังเกตุได้ว่าความสัมพันธ์แบบ 1:M จะเป็นความสัมพันธ์ที่สามารถปรากฏขึ้นได้ง่าย โดยจากตัวอย่างข้างต้นเราจะสังเกตุได้ว่าในตาราง PAINTER จะใช้ข้อมูลแอทริบิว PAINTER_NUM เป็นprimary key และมีการประยุกต์ใช้แอทริบิว PAINTING_NUM เป็น primary key ในตาราง PAINTING ตามล าดับ เพ่ือที่จะท าความเข้าใจเกี่ยวกับความสัมพันธ์แบบ 1:M และการก าหนดคีย์หลักมากขึ้น ลองพิจารณาตัวอย่างการลงทะเบียนเรียนของนักศึกษาในมหาวิทยาลัย ที่ซึ่งรายวิชาหนึ่งๆจะสามารถมีได้หลายชั้นเรียน แต่ส าหรับชั้นเรียนหนึ่งๆจะอยู่ภายใต้รายวิชาหนึ่งๆเท่านั้น ตัวอย่างเช่น รายวิชา Accounting II จะประกอบไปด้วย 2 ชั้นเรียนที่จะต้องเรียนตามก าหนดการดังนี้ 1) วันจันทร์ พุธ และ ศุกร์ เวลา 10.00 – 10.50 น. และ 2) วันอังคาร เวลา 18.00 – 20.40 น. จากข้อมูลของรายวิชาดังกล่าว เราสามารถแสดงความสัมพันธ์ของรายวิชาและชั้นเรียนในรูปแบบ 1:M ได้ดังนี้ (ดังแบบจ าลองข้อมูลเชิงสัมพันธ์ในรูปที่ 3.24 และ การตัวอย่างการสร้างฐานข้อมูลในรูปที่ 3.25)

แต่ละรายวิชาสามารถมีได้หลายชั้นเรียน แต่ชั้นเรียนหนึ่งๆจะอยู่ภายใต้รายวิชาหนึ่งๆเท่านั้น

ข้อมูลเกี่ยวกับรายวิชาจะมีเพียงแค่แถวเดียวในตาราง COURSE ที่มีความเกี่ยวเนื่องกับข้อมูลแถวหนึ่งๆในตาราง CLASS แต่ทางกลับกัน อาจมีข้อมูลเกี่ยวกับชั้นเรียนหลายชั้นเรียนในตาราง CLASS ที่มีความเก่ียวเนื่องกับข้อมูลแถวหนึ่งๆในตาราง COURSE

รูปที่ 3.24 ตัวอย่างความสัมพันธ์แบบ 1:M


รูปที่ 3.25 ตัวอย่างการจัดเก็บข้อมูลภายใต้ความสัมพันธ์แบบ 1:M

3.6.2 ควำมสัมพันธ์แบบ 1:1 ความสัมพันธ์แบบ 1:1 จะเป็นความสัมพันธ์ที่ซึ่งข้อมูลหนึ่งๆในเอ็นทิตี้หนึ่งๆจะมีความสัมพันธ์กับข้อมูลหนึ่งๆในอีกเอ็นทิตี้หนึ่งเท่านั้น ตัวอย่างเช่น อาจารย์คนหนึ่งๆสามารถเป็นหัวหน้าภาควิชาได้เพียงหนึ่งภาควิชาเท่านั้น และ ภาควิชาหนึ่งๆจะสามารถมีหัวหน้าภาควิชาได้เพียงคนเดียว จากความสัมพันธ์ดังกล่าว เอ็นทิตี้ PROFESSOR (เอ็นทิตี้อาจารย์) และ เอ็นทิตี้ DEPARTMENT (เอ็นทิตี้ภาควิชา) จะมีความสัมพันธ์แบบ 1:1 (ดังแสดงในรูป 3.26 และ 3.27) ที่ซึ่งจะมีจะมีคุณลักษระท่ีส าคัญดังต่อไปนี้

อาจารย์แต่ละคนจะเป็นพนักงานของมหาวิทยาลัย ดังนั้นอาจารย์จะมีรหัสพนักงานที่ถูกจัดเก็บในแอทริบิว EMP_NUM (หมายเหตุ—พนักงานทั้งหมดในมหาวิทยาลัยไม่ได้เป็นอาจารย์ทั้งหมด)

จากรปูแบบความสัมพันธ์แบบ 1:1 ระหว่าง PROFESSOR และ DEPARTMENT ในรูป 3.26 จะท าให้เราสามารถจัดเก็บข้อมูลการที่อาจารย์เป็นหัวหน้าภาควิชาได้โดยการประยุกต์ใช้ข้อมูลในแอทริบิว EMP_NUM มาเป็น foreign key ในตาราง DEPARTMENT (หมายเหตุ—ความสัมพันธ์แบบ 1:1 จะถูกพิจารณาเป็นกรณีพิเศษของความสัมพันธ์แบบ 1:M ที่ซึ่งเอ็นทิตี้ที่อยู่ในฝั่ง “many” จะสามารถมีข้อมูลเกิดได้เพียง 1 เรคคอร์ดเท่านั้น ตัวอย่างเช่น ตาราง DEPARTMENT จะมีข้อมูล EMP_NUM เป็น foreign key ที่จะสามารถบ่งบอกได้ว่าภาควิชาหนึ่งๆมีหัวหน้าภาควิชา)


รูปที่ 3.26 ตัวอย่างความสัมพันธ์แบบ 1:1

รูปที่ 3.27 ตัวอย่างการจัดเก็บข้อมูลภายใต้ความสัมพันธ์แบบ 1:1


ในตาราง PROFESSOR จะมีแอทริบิว DEPT_CODE เป็น foreign key ที่ซึ่งจะเป็นรูปแบบความสัมพันธ์ระหว่าง PROFESSOR และ DEPARTMENT ในแบบ 1:M (ภาควิชาหนึ่งๆสามารถมีอาจารย์ได้หลายคน แต่อาจารย์คนหนึ่งจะสามารถสังกัดได้เพียงภาควิชาเดียวเท่านั้น ) ตัวอย่างนี้จะเป็นตัวอย่างที่แสดงความสัมพันธ์ระหว่างสองเอ็นทิตี้ที่ซึ่งสามารถมีความสัมพันธ์กันได้มากกว่าหนึ่งแง่มุม

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

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

แต่ละชั้นเรียนสามารถมีนิสิตลงทะเบียนเรียนได้หลายคน และนิสิตแต่ละคนสามารถลงทะเบียนเรียนได้หลายชั้นเรียน (หลายวิชา)

ข้อมูลเกี่ยวกับชั้นเรียนจะมีได้หลายแถวในตาราง CLASS ที่มีความเกี่ยวเนื่องกับข้อมูลแถวหนึ่งๆในตาราง STUDENT และในท านองเดยีวกัน อาจมีข้อมูลเกี่ยวกับนิสิตหลายคนในตาราง STUDENT ที่มีความเกี่ยวเนื่องกับข้อมูลแถวหนึ่งๆในตาราง CLASS

รูปที่ 3.28 ตัวอย่างความสัมพันธ์แบบ M:M


รูปที่ 3.29 ตัวอย่างการจัดเก็บข้อมูลภายใต้ความสัมพันธ์แบบ M:M

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

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

รูปแบบความสัมพันธ์แบบ M:M ระหว่างตาราง CLASS และ STUDENT จะท าให้การด าเนินการเพ่ิม ลบ หรืออัพเดทข้อมูลมีความซับซ้อนและยังอาจส่งผลให้ระบบฐานข้อมูลมีข้อผิดพลาดเกิดขึ้น

จากปัญหาทั้งสองข้างต้น เราสามารถหลีกเลี่ยงปัญหาของการเกิดขึ้นของความสัมพันธ์แบบ M:M ได้ด้วยการสร้าง composite entity (หรือที่เรียกว่า bridge entity หรือ associative entity) ที่ซึ่งจะเป็นตารางข้อมูลที่เชื่อมโยงความสัมพันธ์ระหว่าง 2 ตารางหลักเดิม โดย composite entity จะประกอบไปด้วย foreign key ต่างๆ ที่เป็น primary key ของสองตารางเดิม การก าหนด primary key ให้กับ composite entity ที่ซึ่งอาจถูกก าหนดได้จาก 1) การน า foreign key มารวมกันเพ่ือสร้างเป็น primary key หรือ 2) สร้าง primary key ขึ้นใหม ่


ดังนั้น จากตาราง STUDENT และ CLASS ในรูปที่ 3.30 เราสามารถสร้างตารางที่เป็น composite ที่มีชื่อว่า ENROLL ได้ดังแสดงในรูป3.30 และ 3.31 ที่ซึ่งจะเป็นตารางข้อมูลที่ถูกประยุกต์ใช้การปรับเปลี่ยนรูปแบบความสัมพันธ์จาก M:M ไปเป็น 1:M ENROLL จะท าการเชื่อมโยงความสัมพันธ์ระหว่างตาราง CLASS และ STUDENT โดยจากรูปเราจะสังเกตุได้ว่า primary key ของตาราง ENROLL จะเกิดขึ้นจากการรวมกันของแอทริบิวที่เป็น foreign key (CLASS_CODE และ STU_NUM) แต่อย่างไรก็ตาม เราสามารถที่จะท าการสร้าง primary key ขึ้นใหม่โดยการเพ่ิมแอทริบิว ENROLL_LINE ที่ซึ่งจะท าให้แต่ละแถวของข้อมูลมีความเป็นเอกลักษณ์ นอกเหนือจากการจัดเก็บข้อมูล STU_NUM และ CLASS_CODE แล้ว ตาราง ENROLL ยังมีการเพ่ิมเติมแอทริบิว ENROLL_GRADE เพ่ือที่จะแสดงถึงเกรดของนิสิตคนหนึ่งๆจากการลงทะเบียนเรียนในชั้นเรียนหนึ่งๆได้อีกด้วย

รูปที่ 3.30 ตัวอย่างการปรับเปลี่ยนความสัมพันธ์ M:M ไปเป็น 1:M


รูปที่ 3.31 การเปลี่ยน M:M ไปเป็น 1:M

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

ถึงแม้ว่าการควบคุมความซ้ าซ้อนของข้อมูลจะเป็นสิ่งส าคัญ แต่ก็มีบางครั้งที่เราต้องยอมให้ข้อมูลมีความซ้ าซ้อนเกิดขึ้นเพ่ือที่จะท าให้ฐานข้อมูลสามารถบริหารจัดการข้อมูลได้หลากหลาย นอกจากนั้นยังมีบางครั้งที่ความซ้ าซ้อนของข้อมูลจะเกิดขึ้นเพ่ือที่จะท าให้ข้อมูลมีความถูกต้อง เพ่ือที่จะท าความเข้าใจกับเหตุการณ์ข้างต้น ลองพิจารณาตัวอย่าง การสร้างระบบส าหรับออกใบแจ้งราคาสินค้าอย่างง่ายที่ซึ่งลูกค้าจะท าการเลือกซื้อสินค้าเป็นล าดับแรก จากนั้นบริษัทจะท าการออกใจแจ้งราคาสินค้าให้แก่ลูกค้า (ดังแสดงในรูปที่ 3.32 และ 3.33) ด้วยเนื่องจากลูกค้าคนหนึ่งๆสามารถซื้อสินค้าได้มากกว่าหนึ่งรายการสินค้าส าหรับการซื้อสินค้าครั้งหนึ่งๆ ดังนั้นใบแจ้งราคารสินค้าอาจจะประกอบไปด้วยหลายรายการสินค้าที่ถูกซ้ือ ด้วยเหตุนี้ ตารางรายการสินค้า (PRODUCT) จึงควรที่จะมีราคาสินค้าเพ่ือที่จะสามารถค านวณราคาสินค้าในใบแจ้งราคาสินค้าได ้

จากรูป 3.32 เราจะเห็นว่าเราสามารถท าการติดตามความสัมพันธ์ของตารางข้อมูลทั้งสี่ตารางได้ ตัวอย่างเช่น เราสามารถทราบได้ว่าลูกค้าที่มีรหัสเท่ากับ 10014 (Myron Orlando) ท าการซื้อสินค้าสองรายการในวันที่ 08/03/2010 ที่ซึ่งรายการสินค้าดังกล่าวจะถูกแจ้งราคาในใบแจ้งราคาหมายเลข 1001 ที่จะประกอบไปด้วย Houselite chain saw with a 16-inch bar จ านวน 1 ชิ้น และ Rat-tail file จ านวน 3 ชิ้น จากความสัมพันธ์ดังกล่าวในรูป 3.32 เราสามารถที่จะคิดได้ว่าราคาสินค้าที่จะแจ้งในใบแจ้งราคาสินค้านั้นสามารถเรียกใช้ข้อมูลจากตารางรายการสินค้าได้ แต่เพราะเหตุใดที่เราต้องท าการเก็บข้อมูลราคาสินค้าไว้ใน


ตารางข้อมูล LINE ? การเก็บข้อมูลลักษณะนี้ก่อให้เกิดความซับซ้อนของข้อมูลหรือไม่?—ค าตอบคือ การจัดเก็บข้อมูลลักษณะนี้จะท าให้เกิดความซับซ้อนของข้อมูลเกิดข้ึน แต่มันจะมีส่วนช่วยให้ระบบมีความสมบูรณ์มากขึ้น การจัดเก็บราคารายการสินค้าไว้ในตารางข้อมูล LINE จะช่วยให้ข้อมูลในใบแจ้งราคาหนึ่งๆมีความถูกต้อง แต่ถ้าเราไม่ท าการจัดเก็บราคาสินค้าไว้ในตารางข้อมูล LINE โดยเลือกที่จะท าการค านวณราคาสินค้าในใบแจ้งราคาสินค้าจากข้อมูลในตาราง PRODUCT เพ่ือให้ได้ราคาขายที่แท้จริง การกระท าดังกล่าวก็สามารถด าเนินการได้แต่อาจก่อให้เกิดปัญหาเกี่ยวกับความถูกต้องได้ โดยเฉพาะกรณีที่ราคาของรายการสินค้ามีการเปลี่ยนแปลงหลังจากออกใบแจ้งราคาสินค้าให้แก่ลูกค้าแล้ว และเมื่อเราท าการค านวณใหม่อีกครั้ งเพ่ือตรวจสอบหรือเรียกดูข้อมูลจะท าให้ราคาสินค้าในใบแจ้งราคาสินค้ามีการเปลี่ยนแปลง ที่ซึ่งจะท าให้ เกิดความผิดพลาดในการแจ้งราคา การตรวจสอบราคาขาย และการท าบัญชีได้ ดังนั้น การจัดเก็บราคาขายสินค้าไว้ในตาราง LINE จะช่วยลดความผิดพลาดที่เกิดขึ้นได้ แต่เราจะต้องยอมให้เกิดความซ้ าซ้อนของข้อมูลเกิดขึ้น เพ่ือคงความถูกต้องของข้อมูลไว้

นอกเหนือจากค าถามข้างต้นแล้ว เราอาจจะมีค าถามที่ว่า “เพราะเหตุใดจึงต้องท าการจัดเก็บข้อมูลที่เกี่ยวกับหมายเลขบรรทัด (LINE_NUMBER) ในตาราง LINE (ดังแสดงในรูปที่ 3.32)?” “การรวมข้อมูลจากแอทริบิว INV_NUMBER และ PROD_CODE เพ่ือก าหนดให้เป็น primary key นั้นเหมาะสมหรือไม่ ?” และ “การจัดเก็บข้อมูลหมายเลขบรรทัดนั้นก่อให้เกิดความซ้ าซ้อนของข้อมูลหรือไม่ ?” ค าตอบคือ การจัดเก็บข้อมูล LINE_NUMBER จะก่อให้เกิดความซ้ าซ้อนของข้อมูลที่ซึ่งจะเป็นความซ้ าซ้อนที่เป็นปกติของการด าเนินการ ซึ่งในการออกแบบแจ้งรายการสินค้ามักจะท าการสร้างหมายเลขบรรทัดของข้อมูลโดยอัตโนมัติอยู่แล้ว การจัดเก็บข้อมูล LINE_NUMBER จะมีประโยชน์อีกอย่างหนึ่งคือ ล าดับของรายการสินค้าที่เรียกดูจะเป็นล าดับเดียวกับล าดับในการกรอกข้อมูลเข้าสู่ฐานข้อมูล แต่ถ้าเราใช้รหัสสินค้าเป็นส่วนหนึ่งของ primary key อาจจะไม่สามารถทราบถึงล าดับของสินค้าได้ ดังนั้นถ้าเกิดมีข้อผิดพลาดเกิดขึ้น เราไม่สามารถอ้างถึงล าดับของข้อมูลได้ ตัวอย่างเช่น เมื่อลูกค้าโทรมาและกล่าวว่า ราคาสินค้ารายการที่สองในใบแจ้งราคาสินค้ามีราคาไม่ถูกต้อง เราจะไม่สามารถรู้ได้ว่ารายการสินค้าที่สองคือรายการสินค้าใด ด้วยเหตุนี้การยอมให้มีความซ้ าซ้อนของข้อมูลที่จ าเป็นหลงเหลืออยู่ในฐานข้อมูลก็มีประโยชน์เช่นกัน เพียงแต่ว่าเราจะต้องท าการควบคุมให้มีปริมาณท่ีเหมาะสม


รูปที่ 3.32 ระบการจัดเก็บข้อมูลใบแจ้งหนี้อย่างง่าย

รูปที่ 3.33 แผนผังความสัมพันธ์ส าหรับระบบจัดเก็บข้อมูลใบแจ้งหนี้

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


จากแค็ตตาล็อกหนังสือของห้องสมุดที่ถูกสร้างจากการสร้างดัชนีของชื่อหนังสือและ /หรือผู้แต่งหนังสือที่ซึ่งสามารถบ่งบอกถึงชั้นและแถวที่มีการจัดเก็บหนังสือที่เราต้องการได้ จะท าให้เราสามารถค้นหาหนังสืออย่างรวดเร็ว อีกตัวอย่างหนึ่งของการประยุกต์ใช้ดัชนีคือ ถ้าเราต้องการที่จะค้นหาข้อมูลต่างๆ เช่น แบบจ าลองข้อมูลเชิงสัมพันธ์เอ็นทีตี้ จากหนังสือที่เกี่ยวกับฐานข้อมูลเล่มหนึ่งๆด้วยการอ่านหรือค้นหาหัวข้อดังกล่าวในทุกๆหน้า วิธีการนี้ย่อมเป็นวิธีการค้นหาที่ไม่มีประสิทธิภาพ แต่ถ้าเราท าการค้นหาหัวข้อดังกล่าวด้วยการพิจารณาดัชนีที่อยู่ด้านหลังหนังสือ แล้วท าการค้นหาดัชนีที่บ่งบอกถึงแบบจ าลองข้อมูลเชิงสัมพันธ์เอ็นทิตี้จะท าให้เราทราบถึงหมายเลขหน้าของหนังสือที่มีหัวข้อดังกล่าวปรากฏอยู่ จากตัวอย่างทั้งสอง เราสามารถพิจารณาได้ว่า “ดัชนีจะประกอบไปด้วย 1) คีย์ดัชนี (index key)—เป็นจุดที่ใช้ในการอ้างอิงดัชนี และ 2) เซตของตัวบ่งชี้ (pointer)—จะบ่งบอกถึงสถานที่ข้อมูลจากดัชนีนั้นๆปรากฏอยู่” ตัวอย่างเช่น การค้นหาผลงานศิลปะของจิตกรคนหนึ่งๆ ดังแสดงในรูป 3.23 ถ้าเราท าการค้นหาผลงานศิลปะโดยไม่ท าการประยุกต์ใช้ดัชนีในการค้นหาผลลัพธ์ เราจะต้องท าการอ่านข้อมูลแต่ละบรรทัดในตาราง PAINTING จากนั้นท าการพิจารณาแต่ละแถวข้อมูลที่มีค่าในแอทริบิวรหัสจิตกร (PAINTER_NUM) ที่มีค่าตรงกับรหัสจิตรกรที่เราต้องการค้นหาผลงาน แต่ถ้าเราท าการประยุกต์ใช้ดัชนีโดยท าการสร้างดัชนีในตาราง PAINTER และท าการสร้างคีย์ดัชนีกับแอทริบิว PAINTER_NUM จะท าให้เราสามารถค้นหาข้อมูลจากการพิจารณารหัสจิตรกรที่ตรงกับข้อมูลที่เราต้องการแล้วท าการพิจารณาที่ตัวบ่งชี้ เพ่ือที่จะได้มาซึ่งผลงานศิลปะของจิตรกรที่เราต้องการค้นหาผลงาน (ดังแสดงในรูปที่ 3.34) จากรูป 3.34 เราจะเห็นว่าจิตกรคนแรกที่มีรหัสจิตรกรเท่ากับ 123 จะสร้างสรรค์ผลงานศิลปะที่ถูกจัดเก็บข้อมูลในเรคคอร์ดที่ 1, 2 และ 4 ในตาราง PAINTING ส่วนจิตรกรคนที่สองท่ีมีรหัสจิตรกรเท่ากับ 126 จะสร้างสรรค์ผลงานศิลปะที่ถูกจัดเก็บข้อมูลในเรคคอร์ดที่ 3 และ 5 ในตาราง PAINTING ตามล าดับ

รูปที่ 3.34 ส่วนประกอบของดัชนี

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


ตัวอย่างเช่น การสร้างดัชนีให้กับนามสกุลของลูกค้าจะสามารถท าได้โดยน าข้อมูลนามสกุลลูกค้ามาเรียงล าดับ จากนั้นก็จะท าการสร้างดัชนีที่ชื่อลูกค้าชื่อแรกที่ขึ้นต้นด้วยอักษร A, B, …, Z ตามล าดับ การสร้างดัชนีแบบนี้จะช่วยให้เราสามารถค้นคืนข้อมูลลูกค้าด้วยการตรวจสอบตัวอักษรขึ้นต้นของนามสกุลได้ เช่น ถ้าเราต้องการค้นหาข้อมูลลูกค้าที่มีนามสกุลเป็น Timber เราก็จะเลื่อนการพิจารณาไปดัชนีของกลุ่มข้อมูลลูกค้าที่มีการขึ้นต้นด้วยตัวอักษร T แล้วจากนั้นจะท าการค้นหาข้อมูลลูกค้าจากกลุ่มข้อมูลค้าดังกล่าว ซึ่งการค้นหาด้วยวิธีการนี้จะช่วยให้เราสามารถลดจ านวนในการเปรียบเทียบอันน ามาซึ่งการลดเวลาในการค้นคืนข้อมูลได ้

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

3.9 กฎเกี่ยวกับกำรสร้ำงฐำนข้อมูลเชิงสัมพันธ์ ในปี 1985 Dr. E.F. Codd ได้น าเสนอกฎ 12 ข้อในการสร้างฐานข้อมูลเชิงสัมพันธ์ เนื่องจากหลายๆผู้สร้างฐานข้อมูลได้ท าการสร้างซอร์ฟแวร์โดยไม่มีแนวทางในทางปฏิบัติที่ซึ่งแนวปฏิบัติที่ประยุกต์ใช้จะไม่สอดคล้องกับมาตราฐานของการสร้างฐานข้อมูลเชิงสัมพันธ์ โดยกฎทั้ง 12 ข้อจะมีรายละเอียดและค าอธิบายดังแสดงในรูปที่ 3.35


รูปที่ 3.35 กฎเกี่ยวกับการสร้างฐานข้อมูลเชิงสัมพันธ์

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

อย่างไร ? 3. จงอิธิบายเกี่ยวกับ entity integrity และ referential integrity 4. ตัวด าเนินการกับฐานข้อมูลเชิงสัมพันธ์มีอะไรบ้างและสามารถด าเนินการได้อย่างไร ? 5. จงพิจารณารูปดังต่อไปนี้ เพ่ือตอบค าถาม


a. จงแสดงถึงความแตกต่างระหว่างการด าเนินการ natural join และ outer join กับตารางข้อมูล STUDENT และ PROFESSOR ข้างต้น

b. จงสร้างแผนผังเชิงสัมพันธ์เอ็นทิตี้อย่างง่ายเพ่ือแสดงถึงความสัมพันธ์ระหว่างตาราง STUDENT และ PROFESSOR

6. จงพิจารณารูปดังต่อไปนี้ เพ่ือตอบค าถาม

a. จงสร้างตารางข้อมูลที่เกิดจากการประยุกต์ใช้ตัวด าเนินการ UNION กับตาราง BOOTH และ MACHINE

b. จงสร้างตารางข้อมูลที่เกิดจากการประยุกต์ใช้ตัวด าเนินการ INTERSECT กับตาราง BOOTH และ MACHINE

c. จงสร้างตารางข้อมูลที่เกิดจาก “MACHINE DIFFERENCE BOOTH” 7. ถ้าเรามีแผนผังเชิงสัมพันธ์เอ็นทิตี้ดังรูปข้างล่างนี้ เราจะสามารถปรับเปลี่ยนรูปแบบความสัมพันธ์ให้

กลายเป็นความสัมพันธ์แบบ 1:M ได้อย่างไร จงอธิบายพร้อมกับแสดงตัวอย่างของการปรับเปลี่ยน

8. จงอธิบายถึงลักษณะของแอทริบิวต่างๆในตารางดังต่อไปนี้ (โดยการพิจารณาว่าแอทริบิวใดควรจะเป็น primary และ/หรือ foreign key พร้อมทั้งอธิบายว่าเพราะเหตุใด)


9. ในการที่จะจัดเก็บข้อมูลใน 2 ตารางใดๆท่ีมีความสัมพันธ์กันแบบ 1:M เราจะสามารถด าเนินการได้อย่างไร?

10. จงพิจารณารูปดังต่อไปนี้ เพ่ือตอบค าถาม

a. จงระบุถึง primary key ของแต่ละตาราง b. จงระบุถึง foreign key ที่ปรากฏในแต่ละตาราง c. จงท าการสร้างแผนผังเชิงสัมพันธ์เอ็นทิตี้

บทที่ 3 แบบจ ำลองฐำนข้อมูลเชิง...

Documents

Transcript of บทที่ 3 แบบจ ำลองฐำนข้อมูลเชิง...