บทที่ 5 การสร้างแบบจ าลองขั้นสูง · 2015....

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

บทที่ 5 การสร้างแบบจ าลองขั้นสูง วัตถุประสงคข์องบทเรียน

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

ศึกษาเก่ียวกับแนวความคิดของการจัดล าดับชั้นของเอ็นทิตี้

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

ศึกษาเก่ียวกับคุณลักษณะของ primary key ที่ดี และวิธีการในการเลือก primary key

ศึกษาเก่ียวกับความยืดหยุ่นของการออกแบบแบบจ าลองข้อมูล

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

แบบจ าลองข้อมูลเชิงสัมพันธ์ที่มีการพัฒนาเพ่ิมเติม, Entity supertype และ entity subtype, specialization hierarchy, การสืบทอด, subtype discriminator, disjoint constraint และ overlapping constraint, completeness constraint, การจัดกลุ่มเอ็นทิตี้, วิธีการเลือก primary key, กรณีที่เหมาะสมกับการประยุกต์ใช้ composite primary key, กรณีที่เหมาะสมกับการประยุกต์ใช้ surrogate primary key, ความยืดหยุ่นในการออกแบบฐานข้อมูล

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

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

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

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

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

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

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

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

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

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


ในบทก่อนหน้า เราได้ท าการศึกษาเกี่ยวกับการสร้างแผนภาพเชิงสัมพันธ์ เ อ็นทิตี้ (Entity Relationship Diagram, ERD) เพ่ือแสดงถึงโครงสร้างการจัดเก็บข้อมูล แต่ในบทนี้เราจะท าการศึกษาเกี่ยวกับแบบจ าลองข้อมูลเชิงสัมพันธ์เอ็นทิตี้ที่มีการพัฒนาเพ่ิมเติม (Extended Entity Relationship model, EERM) ที่ซึ่งจะเป็นแบบจ าลองข้อมูลที่มีแนวความคิดเช่นเดียวกับแบบจ าลองข้อมูลเชิงสัมพันธ์เอ็นทิตี้ แต่จะมีการเพ่ิมเติมแนวความคิดเกี่ยวกับ “entity supertype”, “entity subtype” และ “entity clustering” ตามล าดับ นอกจากนั้น เราจะได้ศึกษาเกี่ยวกับคุณลักษณะของ primary key ที่ดีและวิธีการในการเลือก primary key ที่ดี และท้ายสุดเราจะได้ศึกษาเกี่ยวกับกรณีพิเศษของการด าเนินการต่างๆที่ซึ่งจะต้องการการออกแบบแบบจ าลองข้อมูลเป็นกรณีพิเศษ

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

ซับซ้อน ด้วยเหตุนี้จึงเป็นเหตุให้มีการพัฒนาแบบจ าลองข้อมูลเชิงสัมพันธ์ขึ้นใหม่ ที่ชื่อ “Extended Entity Relationship Model, EERM” เพ่ือใช้ในการก าหนดโครงสร้างการจัดเก็บข้อมูลที่มีความซับซ้อน แบบจ าลองข้อมูลนี้จะเป็นแบบจ าลองข้อมูลที่ถูกพัฒนาความสามารถจากแบบจ าลองข้อมูลเชิงสัมพันธ์เอ็นทิตี้ที่ซึ่งจะท าการเพิ่มเติมความหมาย (semantic) ของโครงสร้างข้อมูล

5.1.1 Entity supertype และ entity subtype ภายใต้กรอบแนวคิดของแบบจ าลองข้อมูล “entity supertype” จะเป็นเอ็นทิตี้ทั่วๆไปที่จะมีความ

เกี่ยวเนื่องกับเอ็นทิตี้ที่มีลักษณะเป็น “entity subtype” เอ็นทิตี้ supertype จะถูกประยุกต์ใช้ในการจัดเก็บข้อมูลทั่วๆไป (ไม่มีเฉพาะเจาะจง) แต่ส าหรับเอ็นทิตี้ที่เป็น subtype จะใช้ในการจัดเก็บข้อมูลคุณลักษณะพิเศษต่างๆที่เป็นข้อมูลเฉพาะที่มีการเพ่ิมเติมจากข้อมูลทั่วๆไปในเอ็นทิตี้ supertype ตัวอย่างเช่น ธุรกิจสายการบินที่มีพนักงานหลากหลายต าแหน่ง เช่น นักบิน ช่างซ่อมบ ารุง เลขา นักบัญชี ผู้ดูแลฐานข้อมูล และอ่ืนๆ โดยแต่ละต าแหน่งงานจะมีข้อมูลบางส่วนเหมือนกัน แต่จะมีข้อมูลพิเศษที่ต้องท าการจัดเก็บไม่เหมือนกัน ดังแสดงในรูป 5.1 จะแสดงถึงตัวอย่างของการจัดเก็บข้อมูลพนักงานในต าแหน่งนักบินที่ซึ่งจะมีข้อมูลบางส่วนเหมือนกับข้อมูลของพนักงานต าแหน่งอ่ืนๆ เช่น รหัสพนักงาน (EMP_NUM) ชื่อพนักงาน (EMP_FNAME) และ วันที่พนักงานเริ่มท างาน (EMP_HIRE_DATE) เป็นต้น แต่ในทางกลับกัน เราจะสังเกตุได้ว่า ต าแหน่งนักบินจะมีข้อมูลพิเศษหรือข้อมูลโดยเฉพาะต าแหน่ง เช่น ใบอนุญาตินักบิน (EMP_LICENSE) ระดับของนักบิน (EMP_RATING) และระดับความแข็งแรงของสุขภาพ (EMP_MED_TYPE) เป็นต้น จากข้อมูลต่างๆที่เกี่ยวข้องกับต าแหน่งนักบิน ถ้าเราท าการออกแบบโครงสร้างการจัดเก็บข้อมูลพนักงานที่มีหน้าที่แตกต่างกันให้ท าการจัดเก็บข้อมูลทั้งหมดไว้ในเอ็นทิตี้เดียวกันจะท าให้แถวข้อมูลของพนักงานที่ไม่ใช่นักบินจะมีค่าของข้อมูลเป็น NULL ในแอทริบิวต่างๆที่เป็นข้อมูลพิเศษเฉพาะนักบิน ด้วยเหตุนี้ เราควรที่จะท าการแยกการจัดเก็บข้อมูลของพนักงานในต าแหน่งต่างๆ ด้วยการแยกข้อมูลพิเศษที่เกี่ยวกับนักบินเก็บไว้ในเอ็นทิตี้นักบิน (PILOT) และแยกการจัดเก็บข้อมูลทั่วๆไปของพนักงานไว้ในเอ็นทิตี้พนักงาน (EMPLOYEE) ที่ซึ่งจะท าให้สามารถลดทอนการปรากฏขึ้นของค่า NULL ในแอทริบิวต่างๆได้ จากการด าเนินการดังกล่าว เราจะสังเกตุได้ว่า


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

รูปที่ 5.1 ตัวอย่างการจัดเก็บข้อมูลพนักงานของบริษัทสายการบิน

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

เราจะต้องท าการะบุให้ได้ว่าเอ็นทิตี้หนึ่งๆจะมีข้อมูลเฉพาะหรือข้อมูลที่มีความแตกต่างกัน

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

จากปัจจัยทั้งสองข้างต้น เราสามารถประยุกต์ปัจจัยดังกล่าวกับตัวอย่างการจัดเก็บข้อมูลพนักงานบริษัทสายการบินได้ ที่ซึ่ง 1) ข้อมูลพนักงานต าแหน่งนักบินจะเป็นข้อมูลที่มีความแตกต่างจากพนักงานในต าแหน่งอ่ืนๆ (ในเอ็นทิตี้พนักงาน) และ 2) ข้อมูลพนักงานต าแหน่งนักบินจะมีข้อมูลพิเศษ 3 แอทริบิวที่บ่งบอกถึงข้อมูลเฉพาะของนักบินที่ซึ่งพนักงานต าแหน่งอ่ืนๆจะไม่มีข้อมูลในส่วนนี้ ด้วยเหตุนี้ เราจึงสมควรที่จะท าการสร้างเอ็นทิตี้พนักงานนักบิน (PILOT) และก าหนดให้เป็นเอ็นทิตี้ subtype ของเอ็นทิตี้พนักงาน (EMPLOYEE) แต่ถ้าเราเพ่ิมการพิจารณาข้อมูลพนักงานซ่อมบ ารุงและพนักงานบัญชีจะท าให้เราทราบว่าต าแหน่งของพนักงานเหล่านี้จะมีข้อมูลพิเศษเฉพาะต าแหน่งด้วยเช่นกัน ดังนั้น เราจึงสามารถท าการสร้างเอ็นทิตี้พนักงานซ่อมบ ารุง (MECHANIC) และเอ็นทิตี้พนักงานบัญชี (ACCOUNTANCE) และก าหนดให้ทั้งสองเอ็นทิตี้นี้เป็นเอ็นทิตี้ subtype ของเอ็นทิตี้ EMPLOYEE ด้วยเช่นกัน (ดังแสดงในรูป 5.2) แต่อย่างไรก็ตาม เมื่อเราท าการพิจาณาข้อมูลของพนักงานต าแหน่งเสมียณ เราจะสังเกตุได้ว่าต าแหน่งนี้จะไม่มีข้อมูลพิเศษเฉพาะต าแหน่ง ดังนั้น เราไม่จ าเป็นต้องท าการสร้างเอ็นทิตี้ใหม่ส าหรับจัดเก็บข้อมูลพนักงานเสมียณ


5.1.2 Specialization Hierarchy เอ็นทิตี้ที่มีลักษณะเป็น supertype และ subtype มักจะถูกจัดเรียงในล าดับชั้นของเอ็นทิตี้ที่เรียกว่า “specialization hierarchy” ที่ซึ่งจะแสดงให้เห็นถึงล าดับชั้นของความเกี่ยวเนื่องกันระหว่างเอ็นทิตี้ supertype (“parent entity”) และเอ็นทิตี้ subtype (“child entity”) ต่างๆ โดยรูป 5.2 จะแสดงถึงล าดับชั้นของเอ็นทิตี้ที่ประกอบไปด้วย 1 เอ็นทิตี้ supertype (EMPLOYEE) ที่เชื่อมโยงกับ 3 เอ็นทิตี้ subtype (PILOT, MECHANIC และ ACCOUNTANT) โดยความสัมพันธ์ระหว่างเอ็นทิตี้ supertype และ subtype ในล าดับชั้นของเอ็นทิตี้นี้จะมีรูปแบบเป็น 1:1 ที่ซึ่งเราจะสามารถพิจารณาได้ดังนี้

1) แถวข้อมูลหนึ่งๆในเอ็นทิตี้ PILOT จะมีความเกี่ยวเนื่องกับแถวข้อมูลหนึ่งๆในเอ็นทิตี้ EMPLOYEE 2) แถวข้อมูลหนึ่งๆในเอ็นทิตี้ MECHANIC จะมีความเกี่ยวเนื่องกับแถวข้อมูลหนึ่งๆในเอ็นทิตี้

EMPLOYEE 3) แถวข้อมูลหนึ่งๆในเอ็นทิตี้ ACCOUNTANT จะมีความเกี่ยวเนื่องกับแถวข้อมูลหนึ่งๆในเอ็นทิตี้

EMPLOYEE

รูปที่ 5.2 ตัวอย่าง specialization hierarchy

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

แอทริบิวที่สนับสนุนคุณสัมบัติการสืบถอด (inheritance)


การก าหนดแอทริบิวในเอ็นทิตี้ supertype ที่ซึ่งท าหน้าที่แยกความแตกต่างของข้อมูลที่ซึ่งจะสัมพันธ์กับเอ็นทิตี้ subtype

การก าหนดเงื่อนไขที่มีลักษณะเป็น disjoint/overlapping และเงื่อนไขที่มีลักษณะเป็น complete/partial

5.1.3 การสืบทอด คุณสมบัติของการสืบทอด (inheritance) จะท าให้เอ็นทิตี้ subtype สามารถสืบทอด/ประยุกต์ใช้

แอทริบิวต่างๆของเอ็นทิตี้ supertype และท าการสร้างความเชื่อมโยงความสัมพันธ์กับเอ็นทิตี้ supertype หนึ่งๆได้ โดยปกติของเอ็นทิตี้ supertype จะประกอบไปด้วยแอททริบิวที่ใช้จัดเก็บข้อมูลทั่วๆไปไม่เฉพาะเจาะจง แต่เอ็นทิตี้ที่เป็น subtype มักจะประกอบด้วยแอทริบิวของข้อมูลพิเศษหรือข้อมูลเฉพาะเจาะจง ตัวอย่างเช่น รูป 5.2 จะแสดงให้เห็นว่าเอ็นทิตี้ PILOT, MECHANIC และ ACCOUNTANCE จะสามารถสืบทอด (ประยุกต์ใช้) ข้อมูลแอริบิวรหัสพนักงาน (EMP_NUM) ชื่อ (EMP_FNAME) สกุล (EMP_LNAME) และ วันที่เริ่มท างาน (EMP_HIRE_DATE) จากเอ็นทิตี้ EMPLOYEE ได้ แต่เมื่อเราท าการสังเกตุที่เอ็นทิตี้ PILOT, MECHANIC, และ ACCOUNTANCE ที่เป็นเอ็นทิตี้ subtype เราจะเห็นว่าเอ็นทิตี้ดังกล่าวจะมีข้อมูลเฉพาะที่เป็นข้อมูลที่แตกต่างจากเอ็นทิตี้ EMPLOYEE และเอ็นทิตี้เหล่านี้ยังสืบทอด primary key (แอทริบิว EMP_NUM) มาจากเอ็นทิตี้ EMPLOYEE ที่เป็นเอ็นทิตี้ supertype ที่ซึ่งจะท าให้แอทริบิว EMP_NUM กลายเป็น primary key ของเอ็นทิตี้ PILOT, MECHANIC, และ ACCOUNTANCE ด้วยเช่นกัน

นอกเหนือจากการสืบทอดแอทริบิวต่างๆจากเอ็นทิตี้ supertype แล้ว เอ็นทิตี้ subtype หนึ่งๆจะสามารถสืบทอดความสัมพันธ์ที่เกิดขึ้นกับเอ็นทิตี้ supertype ได้เช่นกัน ตัวอย่างเช่น ในรูป 5.2 เอ็นทิตี้ EMPLOYEE ที่เป็นเอ็นทิตี้ supertype จะมีความสัมพันธ์กับเอ็นทิตี้ DEPENDENT ในรูปแบบ 1:M ดังนั้น เอ็นทิตี้ PILOT, MECHANIC และ ACCOUNT จะสามารถสืบทอดความสัมพันธ์ที่เกิดขึ้นกับเอ็นทิตี้ EMPLOYEE ที่ซึ่งจะท าให้เอ็นทิตี้ PILOT, MECHANIC และ ACCOUNT มีความสัมพันธ์กับเอ็นทิตี้ DEPENDENT ในรูปแบบ 1:M ด้วยเช่นกัน

5.1.4 subtype discriminator subtype discriminator จะเป็นแอทริบิวหนึ่งๆในเอ็นทิตี้ supertype ที่ท าหน้าที่บ่งบอกถึงการ

ปรากฏขึ้นครั้งหนึ่งๆของข้อมูล (แถวของข้อมูลหนึ่งๆ) ในเอ็นทิตี้ supertype จะมีความเกี่ยวเนื่องกับข้อมูลในเอ็นทิตี้ subtype หนึ่งๆ ตัวอย่างเช่น แอทริบิว EMP_TYPE ในเอ็นทิตี้ EMPLOYEE ที่เป็นเอ็นทิตี้ supertype ในรูป 5.2 จะท าหน้าที่เป็น subtype discriminator ที่ซึ่งจะสามารถบ่งบอกถึงประเภทพนักงานของข้อมูลแถวหนึ่งๆ ดังนั้น เราจะสามารถทราบถึงประเภทของพนักงานคนหนึ่งๆ (แถวข้อมูลหนึ่งๆ) ที่ถูกจัดเก็บข้อมูลในเอ็นทิตี้ EMPLOYEE ได้ก็ต่อเมื่อเราท าการพิจารณาถึงค่าข้อมูลที่ปรากฏในแอทริบิว EMP_TYPE ของแถวข้อมูลที่พิจารณา ถ้าค่าของข้อมูลในแอทริบิว EMP_TYPE มีค่าเป็น “P” เราจะสามารถ


สรุปได้ว่าต าแหน่งของพนักงานคือนักบิน แต่ถ้าค่าของข้อมูลในแอทริบิว EMP_TYPE มีค่าเป็น “M” เราจะสามารถสรุปได้ว่าต าแหน่งของพนักงานคือช่างซ่อมบ ารุง และท้ายสุดถ้าค่าของข้อมูลในแอทริบิว EMP_TYPE มีค่าเป็น “A” เราจะสามารถสรุปได้ว่าต าแหน่งของพนักงานคือบัญชี ตามล าดับ

นอกเหนือจากการก าหนดลักษณะของค่าของข้อมูลที่ปรากฏใน subtype discrimination เพ่ือบ่งบอกถึงการเชื่อมโยงความสัมพันธ์ระหว่างแถวข้อมูลหนึ่งๆในเอ็นทิตี้ supertype กับข้อมูลแถวหนึ่งๆในเอ็นทิตี้ subtype แล้ว เราสามารถประยุกต์ใช้วิธีการอ่ืนๆเพื่อท าการเชื่อมโยงความสัมพันธ์ได้ เช่น การใช้การเปรียบเทียบค่าของข้อมูลที่ปรากฏใน subtype discrimination กับค่าขีดแบ่ง (threshold) หนึ่งๆได้ ตัวอย่างเช่น ในธุรกิจการบินจะมีนักบิน 2 ประเภทหลัก คือ นักบินหลัก (Pilot-In-Command, PIC) และผู้ช่วยนักบิน (Co-Pilot, CP) ที่ซึ่งนักบินทั้งสองจะมีชั่วโมงการบินที่แตกต่างกัน กล่าวคือการที่จะท าหน้าที่นักบินหลักได้จะต้องมีชั่วโมงในการบินไม่ต่ ากว่า 1,500 ชั่วโมง ดังนั้น เราสามารถประยุกต์ใช้จ านวนชั่วโมงบินของนักบิน (แอทริบิวชั่วโมงบิน FLIGHT_HOURS) มาใช้ในการเชื่อมโยงความสัมพันธ์ระหว่างเอ็นทิตี้นักบิน (PILOT) ที่เป็นเอ็นทิตี้ supertype กับเอ็นทิตี้นักบินหลัก (PILOT_PIC) และเอ็นทิตี้ผู้ช่วยนักบิน (PILOT_CP) ที่เป็นเอ็นทิตี้ subtype ได้ โดยเมื่อท าการพิจารณาถึงแถวข้อมูลหนึ่งๆและพิจารณาที่ค่าของข้อมูลที่ปรากฏในแอทริบิว FLIGHT_HOURS ในแถวข้อมูลนั้นๆ ถ้าค่าของข้อมูลในแอทริบิว FLIGHT_HOURS มีค่ามากกว่า 1,500 เราจะสามารถสรุปได้ว่าแถวข้อมูลที่พิจารณาจะเป็นข้อมูลของพนักงานที่เป็นนักบินหลัก แต่ถ้าค่าของข้อมูลในแอทริบิว FLIGHT_HOURS มีค่าน้อยกว่าหรือเท่ากับ 1,500 เราจะสามารถสรุปได้ว่าแถวข้อมูลที่พิจารณาจะเป็นข้อมูลของพนักงานที่เป็นผู้ช่วยนักบินตามล าดับ

5.1.5 disjoint constaint และ overlapping constaint เอ็นทิตี้ supertype หนึ่งๆจะสามารถมีความเกี่ยวเนื่องกับเอ็นทิตี้ subtype ใน 2 รูปแบบ คือ แบบ

disjoint หรือแบบ overlapping ตัวอย่างเช่น ธุรกิจสายการบินท าการว่าจ้างพนักงานในต าแหน่งนักบิน ช่างซ่อมบ ารุง และนักบัญชี และมีกฎเกณฑ์ทางธุรกิจที่บ่งบอกว่า “พนักงานคนหนึ่งๆไม่สามารถท างานในหลายๆต าแหน่งได้” จากกฎเกณฑ์ทางธุรกิจดังกล่าวจะช่วยให้เราสามารถก าหนดลักษณะความสัมพันธ์ระหว่างเอ็นทิตี้ supertype และเอ็นทิตี้ subtype ได้เป็นแบบ “disjoint subtype” หรือ “nonoverlapping subtype” ที่ซึ่ง “แถวข้อมูลหนึ่งๆในเอ็นทิตี้ supertype จะสามารถมีความสัมพันธ์กับข้อมูลในเอ็นทิตี้ subtype หนึ่งๆเท่านั้น (ห้ามมีความสัมพันธ์กับหลายเอ็นทิตี้ subtype)” เช่น แถวข้อมูลหนึ่งๆในเอ็นทิตี้ EMPLOYEE จะมีความเกี่ยวเนื่องกับเอ็นทิตี้ PILOT หรือ MECHANIC หรือ ACCOUNTANCE อย่างใดอย่างหนึ่งเท่านั้น

ในทางกลับกัน ถ้ากฎเกณฑ์ทางธุรกิจบ่งบอกว่า “พนักงานคนหนึ่งๆสามารถท าได้หลายต าแหน่ง” ที่ซึ่งจะสามารถท าให้เกิดเหตุการณ์ท่ีว่า พนักงานคนหนึ่งๆสามารถท างานในต าแหน่งนักบินและช่างซ่อมบ ารุงได้ จากกฎเกณฑ์ทางธุรกิจข้างต้น เราจะสามารถออกแบบให้ข้อมูลแถวหนึ่งๆในเอ็นทิตี้ EMPLOYEEE ที่เป็น supertype มีความเกี่ยวเนื่องกับข้อมูลแถวหนึ่งๆในหลายเอ็นทิตี้ subtype ได้ จากความเกี่ยวเนื่องในลักษณะนี้ เราจะเรียกเอ็นทิตี้ subtype ที่มีส่วนเกี่ยวข้องว่ามีลักษณะเป็น “overlapping subtype”


ตัวอย่างเช่น ในมหาวิทยาลัยหนึ่งๆบุคคลหนึ่งๆอาจเป็นพนักงานหรือนักศึกษาของมหาวิทยาลัย หรือป็นทั้งพนักงานและนักศึกษาพร้อมๆกัน หรือ พนักงานคนหนึ่งๆอาจเป็นอาจารย์และ/หรือเป็นผู้ดูแลระบบพร้อมๆกัน ด้วยเหตุนี้ เราจะสามารถก าหนดให้เอ็นทิตี้พนักงาน (EMPLOYEE) และเอ็นทิตี้นักศึกษา (STUDENT) เป็นเอ็นทิตี้ overlapping subtype ของเอ็นทิตี้บุคคล (PERSON) ที่เป็นเอ็นทิตี้ supertype ได้ และเราสามารถก าหนดให้เอ็นทิตี้อาจารย์ (PROFESSOR) และเอ็นทิตี้ผู้ดูแลระบบ (ADMINISTRATOR) เป็นเอ็นทิตี้ overlapping subtype ของเอ็นทิตี้พนักงาน (EMPLOYEE) ที่เป็นเอ็นทิตี้ supertype ได้ (ดังแสดงในรูป 5.3)

รูปที่ 5.3 ตัวอย่างล าดับชั้นของเอ็นทิตี้ที่แสดงถึง overlapping subtypes

จากรูป 5.3 เราจะสังเกตุได้ว่าการแสดงถึง overlapping subtype จะประยุกต์ใช้ตัวอักษร ‘o’ และจากที่เราได้ศึกษาจากเนื้อหาในส่วนก่อนหน้าจะท าให้เราทราบได้ว่า การด าเนินการสร้าง disjoint subtypes จะขึ้นกับค่าของข้อมูลที่ปรากฏในแอทริบิว discriminator ที่บ่งบอกถึงความเกี่ยวเนื่องกับเอ็นทิตี้ subtype ดังนั้น การด าเนินการสร้างความเก่ียวเนื่องระหว่างเอ็นทิตี้ supertype กับเอ็นทิตี้ overlapping subtype จะต้องการให้เราก าหนด/สร้างแอทริบิว discriminator หนึ่งๆส าหรับเอ็นทิตี้ subtype หนึ่งๆ ตัวอย่างเช่น ในรูป 5.3 อาจารย์คนหนึ่งๆสามารถท าหน้าที่เป็นผู้ดูแลระบบด้วยช่นกัน ดังนั้น เราจะต้องท าการก าหนด/สร้าง


2 แอทริบิวใหม่เพ่ือท าหน้าที่เป็น discriminator attribute ส าหรับ overlapping subtype อาจารย์ (PROFESSOR) และ ผู้ดูแลระบบ (ADMINISTRATOR) โดยค่าของข้อมูลที่เป็นไปได้ที่จะปรากฏในแอทริบิว discriminator ทั้งสองจะสามารถแสดงได้ดังรูป 5.4

รูปที่ 5.4 ค่าของข้อมูลที่เป็นไปได้ท่ีจะปรากฏในแอทริบิว discriminator

5.1.6 Completeness constraint Completeness constraint (เงื่อนไขความสมบูรณ์ระหว่างเอ็นทิตี้ supertype และ subtype) จะเป็นเครื่องมือที่ใช้ในการระบุว่า “แต่ละแถวข้อมูลหนึ่งๆในเอ็นทิตี้ supertype จะต้องหรือจ าเป็นต้องมีความเกี่ยวเนื่องกับแถวข้อมูลหนึ่งๆในเอ็นทิตี้ subtype หนึ่งๆหรือไม่?”—ถ้าข้อมูลแถวหนึ่งๆในเอ็นทิตี้ supertype ไม่จ าเป็นต้องมีความเกี่ยวเนื่องกับแถวข้อมูลหนึ่งๆในเอ็นทิตี้ subtype หนึ่งๆ (อาจมีบางแถวข้อมูลที่มีความเกี่ยวเนื่องและบางแถวข้อมูลที่ไม่เกี่ยวเนื่อง ) เราจะเรียกความเกี่ยวเนื่องนี้ว่า “partial completeness” และจะประยุกต์ใช้สัญลักษณ์วงกลมบนเส้นตรงหนึ่งเส้นเพ่ือแสดงถึงความเกี่ยวเนื่องดังกล่าว แต่ถ้าข้อมูลแถวหนึ่งๆในเอ็นทิตี้ supertype จ าเป็นที่จะต้องมีความเกี่ยวเนื่องกับแถวข้อมูลหนึ่งๆในเอ็นทิตี้ subtype หนึ่งๆ (ทุกแถวข้อมูลจะต้องมีความเกี่ยวเนื่อง) เราจะเรียกความเกี่ยวเนื่องนี้ว่า “total completeness” ที่ซึ่งจะประยุกต์ใช้สัญลักษณ์วงกลมและเส้นตรง 2 เส้นเพ่ือแสดงถึงความเกี่ยวเนื่องแบบ total completeness (ดังแสดงในรูป 5.3)

จากกรอบความคิดเกี่ยวกับ “disjoint/overlapping subtypes” และ “partial/total completeness constraints” เราสามารถท าการประยุกต์ใช้สัญลักษณ์ต่างๆเพ่ือแสดงถึงกรอบความคิดดังกล่าวที่ซึ่งจะแสดงได้ดังรูป 5.5

รูปที่ 5.5 สัญลักษณ์ที่ใช้แสดงถึง “disjoint/overlapping subtypes” และ “partial/total completeness constraints”


5.2 การจัดกลุ่มเอ็นทิตี้ ในหลายๆครั้งที่ ERD หนึ่งๆอาจมีเอ็นทิตี้และความสัมพันธ์ระหว่างเอ็นทิตี้เป็นจ านวนมากที่ซึ่งจะท าให้เราไม่สามารถอ่าน/ทราบถึงข้อมูลใน ERD ได้ นอกจากนั้นยังส่งผลให้ ERD ไม่สามารถเป็นเครื่องมือ/ตัวกลางในการสื่อสารระหว่างผู้ใช้และผู้ออกแบบฐานขอมูลได้ ด้วยเหตุนี้ เราอาจประยุกต์ใช้แนวความคิดที่จะท าการจัดกลุ่มของเอ็นทิตี้ (entity cluster) เพ่ือท าการลดจ านวนเอ็นทิตี้ที่จะแสดงใน ERD ที่ซึ่งจะท าให้เราสามารถอ่านและทราบถึงข้อมูลคร่าวๆใน ERD ได้ ตัวอย่างเช่น ในรูป 5.6 จะแสดงถึงการจัดกลุ่มเอ็นทิตี้ใน ERD ที่จะแสดงถึงข้อมูลของมหาวิทยาลัยในบทที่ 4 ที่ซึ่งจะประกอบไปด้วยเอ็นทิตี้ต่างๆและกลุ่มของเอ็นทิตี้ 2 กลุ่มด้วยกันคือ

กลุ่มของเอ็นทิตี้ OFFERING ที่ซึ่งจะเกิดจากการรวมกันระหว่างเอ็นทิตี้ COURSE และเอ็นทิตี้ CLASS รวมถึงความสัมพันธ์ระหว่างเอ็นทิตี้ดังกล่าว

กลุ่มของเอ็นทิตี้ LOCATION ที่ซึ่งจะเกิดจากการรวมกันระหว่างเอ็นทิตี้ ROOM และเอ็นทิตี้ BUILDING รวมถึงความสัมพันธ์ระหว่างเอ็นทิตี้ดังกล่าว

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

5.3 วิธีการเลือก primary key primary key ของเอ็นทติี้หนึ่งๆจะเป็นสิ่งส าคัญที่ใช้ส าหรับอ้างถึงข้อมูลแถวหนึ่งๆในเอ็นทิตี้หนึ่งๆได้ primary key สามารถการันตีได้ว่าเอ็นทิตี้นั้นๆจะมีความสมบูรณ์ (entity integrity) นอกจากนั้น primary key ยังสามารถท างานร่วมกับ foreign key เพ่ือแสดงถึงความสัมพันธ์ระหว่างเอ็นทิตี้ต่างๆได้อีกด้วย จากประโยชน์ทั้งหมดข้างต้น ถ้าเรามีวิธีการหนึ่งๆที่จะคัดเลือก (ก าหนด) primary key ที่ดีย่อมส่งผลให้การออกแบบฐานข้อมูลสามารถท าได้อย่างมีประสิทธิภาพ แต่ก่อนที่เราจะท าการเลือก primary key เราควรที่จะต้องมีความเข้าใจเกี่ยวกับคุณลักษณะต่างๆของ primary key ที่พึงประสงค์ ดังแสดงลักษณะส าคัญดังรูป 5.7


รูป 5.6 การจัดกลุ่มเอ็นทิตี้ต่างๆเข้าด้วยกัน


รูปที่ 5.7 คุณลักษณะที่พึงมีของ primary key

5.3.1 กรณีที่เหมาะสมกับการประยุกต์ใช้ composite primary key การเลือก primary key ที่มีลักษณะเป็น composite primary key (กลุ่มของแอทริบิว) จะมีประโยชน์ใน 2 กรณี คือ

Composite primary key ทีท่ าหน้าที่อ้างถึงข้อมูลในตารางอ่ืนๆที่ซึ่งจะสามารถลดความซ้ าซ้อนของข้อมูลได้ ตัวอย่างเช่น ถ้าเราก าหนดโครงสร้างของเอ็นทิตี้ STUDENT และเอ็นทิตี้ CLASS จากนั้นก าหนดให้สองเอ็นทิตี้นี้มีความสัมพันธ์กันในรูปแบบ M:N ผ่านการสร้างเอ็นทิตี้ ENROLL ขึ้นใหม่ ซึ่งจากความสัมพันธ์ดังกล่าวจะท าให้ primary key ของเอ็นทิตี้ ENROLL จะเป็น composite primary key ที่เกิดจากการรวมกันระหว่าง primary key ในเอ็นทิตี้ STUDENT และ CLASS จากการด าเนินการดังกล่าว จะท าให้เราไม่ต้องท าการจัดเก็บข้อมูลอ่ืนๆเกี่ยวกับ STUDENT ในเอ็นทิตี้ ENROLL ที่ซึ่งจะสามารถหลีกเลี่ยงความซ้ าซ้อนของปรากฏขึ้นของข้อมูล (ชื่อ ชื่อกลาง นามสกุล และ อ่ืนๆ) ได้ ดังแสดงในรูป 5.8 โดยเราจะสามารถแน่ใจได้ว่านักเรียนคนหนึ่งๆจะไม่สามารถลงทะเบียนเรียนในชั้นเรียนหนึ่งๆมากกว่าหนึ่งครั้ง

Composite primary key ที่ท าหน้าที่ในการอ้างถึง weak entity ที่ซึ่งจะท าให้ weak entity จะสามารถอ้างถึง parent entity ได ้โดยส่วนใหญ่ของ weak entity จะถูกใช้ใน 2 แง่มุมดังตอ่ไปนี้


o แสดงถึงเอ็นทิตี้หนึ่งๆที่ต้องขึ้นกับอีกเอ็นทิตี้หนึ่งๆ (existence-dependent) ที่ซึ่งถ้าไม่มีการปรากฏขึ้นของข้อมูลในเอ็นทิตี้หนึ่งๆจะท าให้อีกข้อมูลในอีกเอ็นทิตี้หนึ่งไม่สามารถปรากฏขึ้นได้

o แสดงถึงเอ็นทิตี้หนึ่งๆที่สามารถแบ่งออกเป็นสองเอ็นทิตี้ย่อยเพ่ือใช้ในการระบุถึง strong identifying relationship โดยข้อมูลในเอ็นทิตี้ย่อยหนึ่งๆไม่สามารถปรากฏขึ้นได้ ถ้าไม่มีข้อมูลในอีกเอ็นทิตี้ย่อยหนึ่งปรากฏ

จากข้างต้น เราสามารถสรุปได้ว่า composite primary key จะเป็นคีย์ที่เหมาะส าหรับเอ็นทิตี้ที่มีลักษณะเป็น composite entity และ weak entity ที่ซึ่งจะช่วยท าให้เอ็นทิตี้เหล่านั้นมีความสมบูรณ์และมีความสอดคล้องของข้อมูล

รูปที่ 5.8 การก าหนด primary key ภายใต้ความสัมพันธ์แบบ M:N

5.3.2 กรณีที่เหมาะสมกับการประยุกต์ใช้ surrogate primary key การประยุกต์ใช้ surrogate key เป็น primary key มักจะด าเนินการในกรณีที่เราไม่สามารถเลือก

แอทริบิวใดหรือกลุ่มของแอทริบิวใดมาท าหน้าที่เป็น primary key ได้ (แอทริบิวหรือกลุ่มของแอทริบิวไม่สามารถระบุถึงแถวข้อมูลหนึ่งๆ/ไม่สามารถแยกความแตกต่างระหว่างแถวข้อมูลได้) โดย surrogate key จะเป็น แอทริบิวหนึ่งๆที่ถูกสร้างขึ้นโดยผู้ออกแบบฐานข้อมูลที่ซึ่งจะสามารถอ้างถึงข้อมูลแถวหนึ่งๆในเอ็นทิตี้ได้ ข้อมูลในแอทริบิวที่เป็น surrogate key จะเป็นข้อมูลที่ไม่มีความหมายที่ซึ่งจะเป็นข้อมูลที่ใช้ส าหรับแยกความแตกต่างระหว่างแถวข้อมูลเท่านั้น

ในการที่จะมีความเข้าใจเกี่ยวกับ surrogate key มากขึ้น ลองพิจารณารูป 5.9 ที่จะแสดงถึงเอ็นทิตี้ของการจัดงานในลักษณะของงานแต่งงานหรือการจัดงานสังสรรค์ และงานอ่ืนๆในห้องจัดเลี้ยงต่างๆของ


โรงแรม โดยในเอ็นทิตี้ดังกล่าวจะประกอบไปด้วยข้อมูลวันที่ (DATE) เวลาที่เริ่มจัดงาน (TIME_START) เวลาที่สิ้นสุดการจัดงาน (TIME_END) ห้องที่ใช้จัดงาน (ROOM) ลักษณะของการจัดงาน (EVENT_NAME) และ จ านวนผู้ร่วมงาน (PARTY_OF)

รูปที่ 5.9 ตัวอย่างการจัดเก็บข้อมูลการจัดงานในลักษณะของงานแต่งงานหรือการจัดงานสังสรรค์

จากรูป 5.9 เราจะสามารถสร้างแบบจ าลองของเอ็นทิตี้การจัดงานเลี้ยง (EVENT) ได้เป็น

EVENT (DATE, TIME_START, TIME_END, ROOM, EVENT_NAME, PARTY_OF)

จากแบบจ าลองของเอ็นทิตี้ EVENT ข้างต้น เราจะสังเกตุได้ว่ายังไม่มีแอทริบิวใดถูกก าหนดเป็น primary ดังนั้น เมื่อเราพิจารณาแต่ละแอทริบิวเราจะสังเกตุได้ดังนี้

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

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

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

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

แอทริบิว EVENT_NAME ไม่สามารถถูกก าหนดเป็น primary key ได้ เนื่องจากไม่สามารถระบุได้ถึงแถวข้อมูลหนึ่งๆได้ (ไม่สามารถแยกความแตกต่างระหว่างแถวข้อมูลได้) ในเอ็นทิตี้อาจมีหลายแถวข้อมูล (งานเลี้ยงสังสรรค์) ที่มีประเภทงานเลี้ยงเหมือนกัน


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

จากการพิจารณาข้างต้น เราจะสังเกตุได้ว่าเราไม่สามารถท าการเลือกแอทริบิวหนึ่งๆเป็น primary key ดังนั้น เราอาจท าการเลือกแอทริบิวจากกลุ่มของแอทริบิวที่ซึ่งจะสามารถเลือกจากกลุ่มของแอทริบิว(composite primary key) ดังต่อไปนี้

(DATE, TIME_START, ROOM) หรือ (DATE, TIME_END, ROOM)

ในการจัดงานครั้งหนึ่งๆจะมีการใช้ทรัพยากรต่างๆเช่น โต๊ะ เครื่องฉายภาพ เก้าอ้ี และ อ่ืนๆ ที่ซึ่งจะท าให้เอ็นทิตี้ทรัพยากร (RESOURSE) จะประกอบไปด้วยแอทริบิวดังนี้

RESOURSE (RSC_ID, RSC_DESCRIPTION, RSC_TYPE, RSC_QTY, RSE_PRICE)

ด้วยเหตุนี้เราจะต้องท าการเชื่อมโยงความสัมพันธ์ระหว่างเอ็นทิตี้ EVENT และ เอ็นทิตี้ RESOURCE ที่ซึ่งจะสามารถบ่งบอกได้ถึงการใช้ทรัพยากรของการจัดงานเลี้ยงครั้งหนึ่งๆที่ซึ่งจะมีความสัมพันธ์แบบ M:N ที่ซึ่งจะเราจะต้องท าการสร้างเอ็นทิตี้ใหม่ (EVENTRSC) เพ่ือแสดงถึงความสัมพันธ์ดังกล่าว ดังนั้น ถ้าเราเลือก (DATE, TIME_START, ROOM) ที่ซึ่งจะเป็น composite primary key ของเอ็นทิตี้ EVENT จะท าให้ข้อมูลในเอ็นทิตี้ EVENTRSC จะประกอบไปด้วยเอ็นทิตี้ต่างๆดังนี้

EVENTRSC (DATE, TIME_START, ROOM, RSC_ID, QTY_USED)

จากเอ็นทิตี้ EVENTSCR เราจะสังเกตุได้ว่า primary key ของเอ็นทิตี้นี้จะมีลักษณะเป็น composite primary key ที่จะประกอบไปด้วย 4 แอทริบิว แต่อย่างไรก็ตาม เราควรที่จะต้องค านึงถึงเหตุการณ์ที่ว่าถ้าเอ็นทิตี้ EVENTSRC ถูกสืบทอดโดยเอ็นทิตี้อ่ืนๆที่ซึ่งจะท าให้ primary key ของ EVENTSRC จะกลายเป็น primary key ของเอ็นทิตี้ subtype ที่ซึ่งจะท าให้สิ้นเปลืองเนื้อที่ในการจัดเก็บข้อมูลและเกิดความยุ่งยากในการเข้าถึงข้อมูล ด้วยเหตุนี้ ผู้ออกแบบฐานข้อมูลควรที่จะต้องท าการพิจารณาว่าการเลือก primary key ที่มีลักษณะเป็น composite primary key นั้นมีความเหมาะสมดังคุณสมบัติของ primary key ในรูป 5.7 หรือไม่? ค าตอบคือ ไม่ เนื่องจาก primary key ที่เลือกนั้นมีจ านวนแอทริบิวมากเกินไป ดังนั้นเราจึงควรที่จะเลือกใช้ primary key ที่มีลักษณะเป็น surrogate key ที่ซึ่งจะท าการสร้างแอทริบิวหนึ่งๆที่มีค่าของข้อมูลเชิงตัวเลขที่บ่งบอกถึงหมายเลขล าดับของการจัดเลี้ยงที่ซึ่งจะเป็นล าดับของตัวเลขจ านวนเต็มบวกที่ไม่ซ้ ากัน ดังนั้น เราสามารถท าการก าหนด primary key ให้กับเอ็นทิตี้ EVENT ได้ดังนี ้

EVENT (EVENT_ID, DATE, TIME_START, TIME_END, ROOM, EVENT_NAME, PARTY_OF)


จากข้างต้น เราจะสังเกตุได้ว่าเอ็นทิตี้ EVENT จะมีแอทริบิว EVENT_ID เพ่ิมขึ้นมาที่ซึ่งจะท าหน้าที่เป็น primary key ดังนั้น เมื่อเราท าการเชื่อมโยงความสัมพันธ์ระหว่างเอ็นทิตี้ EVENT และ RESOURCE จะท าให้เอ็นทิตี้ EVENTSRC มีข้อมูลแอทริบิวต่างๆดังนี้

EVENTSRC (EVENT_ID, RSC_ID, QTY_USED)

จากข้อมูลในเอ็นทิตี้ EVENTSRC เราจะเห็นได้อย่างชัดเจนว่า เราสามารถลดการจัดเก็บข้อมูลในเอ็นทิตี้ EVENTSRC ได้ 2 แอทริบิว ด้วยการเพ่ิมแอทริบิวใหม่ 1 แอทริบิวในเอ็นทิตี้ EVENT ที่ซึ่งจะท าให้เราสามารถประหยัดเนื้อท่ีและความยุ่งยากในการจัดเก็บข้อมูลได้

5.4 กรณีศึกษาของการออกแบบฐานข้อมูล ในการออกแบบฐานข้อมูลและแบบจ าลองข้อมูลที่ดี ผู้ออกแบบควรจะต้องมีประสบการณ์ในการออกแบบที่หลากหลายที่ซึ่งประสบการณ์จะได้มาจากการฝึกฝนและลองผิดลองถูกกับปัญหาต่างๆหลายๆครั้ง ดังนั้นเนื้อหาในส่วนนี้จะแสดงช่วยให้เรามีประสบการณ์มากยิ่งขึ้นด้วยการแสดงถึงตัวอย่างการออกแบบฐานข้อมูล 4 กรณีที่แตกต่างกันที่ซึ่งจะแสดงถึงความยืดหยุ่นในการออกแบบ การก าหนด primary key และ foreign key ที่เหมาะสม

5.4.1 กรณีศึกษาที่ 1: การออกแบบฐานข้อมูลที่มีความสัมพันธ์แบบ 1:1 อย่างที่เราทราบดีว่า การประยุกต์ใช้ foreign key และ primary key จะสามารถสื่อถึงความสัมพันธ์ระหว่างเอ็นทิตี้ในรูปแบบ 1:M ได้โดยง่าย โดยเราสามารถก าหนดให้ primary key ของตารางข้อมูลหนึ่งๆเป็นforeign key ของอีกตารางข้อมูลหนึ่ง แต่ส าหรับการประยุกต์ใช้ foreign key ในความสัมพันธ์แบบ 1:1 อาทิเช่น “พนักงานคนหนึ่งๆสามารถเป็นหัวหน้าแผนกหนึ่งๆได้ และแต่ละแผนกจะมีหัวหน้าแผนกที่เป็นพนักงานหนึ่งคน” กฎทางธุรกิจนี้จะท าให้เราสามารถก าหนด foreign key เพ่ือเชื่อมโยงความสัมพันธ์ได้ 2 วิธี ดังนี้

การก าหนด foreign key ในทั้งสองเอ็นทิตี้—คือ การก าหนดให้ primary key ในเอ็นทิตี้ A ใดๆเป็น foreign key ในเอ็นทิตี้ B และก าหนดให้ primary key ในเอ็นทิตี้ B เป็น primary key ในเอ็นทิตี้ A ตัวอย่างเช่น ก าหนดให้รหัสพนักงาน (EMP_NUM) ที่ซึ่งเป็น primary key ในเอ็นทิตี้พนักงาน (EMPLOYEE) ท าหน้าที่เป็น foreign key ในเอ็นทิตี้แผนก (DEPARTMENT) และการก าหนดให้รหัสแผนก (DEPT_ID) ที่ซึ่งเป็น primary key ในเอ็นทิตี้แผนก ท าหน้าที่เป็น foreign key ในเอ็นทิตี้ พนักงาน ตามล าดับ แต่อย่างไรก็ตาม วิธีการนี้จะไม่เป็นที่นิยมเนื่องจากก่อให้เกิดความซ้ าซ้อนในการจัดเก็บข้อมูล

การก าหนด foreign key ในเอ็นทิตี้เพียงเอ็นทิตี้เดียว—คือ การก าหนดให้ primary key ในเอ็นทิตี้ A ใดๆเป็น foreign key ในเอ็นทิตี้ B วิธีการนี้จะเป็นวิธีการที่ได้รับความนิยม แต่ยังคงไว้ซึ่งค าถามที่ว่า “เราควรใช้ primary key ของเอ็นทิตี้ A หรือ B ท าหน้าที่เป็น foreign key ภายใต้ความสัมพันธ์” แต่อย่างไรก็ตาม เราสามารถตอบค าถามได้ด้วยรายละเอียดในรูป 5.10


รูปที่ 5.10 การก าหนด foreign key ภายใต้ความสัมพันธ์ในรูปแบบ 1:1

จากวิธีการก าหนด foreign key ทั้งสองข้างต้น เราสามารถก าหนด foreign key ภายใต้กฎเกณฑ์ทางธุรกิจ “พนักงานคนหนึ่งๆจะท าหน้าที่เป็นหัวหน้าแผนกหนึ่งๆ” ได้ดังรูป 5.11 ที่ซึ่งจะเป็นการก าหนดให้แอทริบิวรหัสพนักงาน (EMP_NUM) เป็น primary key ในเอ็นทิตี้พนักงาน (EMPLOYEE) และท าหน้าที่เป็น foreign key ในเอ็นทิตี้แผนก (DEPARTMENT)

รูปที่ 5.11 ตัวอย่างการก าหนด foreign key ภายใต้ความสัมพันธ์รูปแบบ 1:1

5.4.2 กรณีศึกษาที่ 2: การจัดเก็บข้อมูลที่มีการเปลี่ยนแปลงค่าของข้อมูล โดยปกติของการด าเนินงานต่างๆ เมื่อมีความเปลี่ยนแปลงเกิดขึ้นกับข้อมูลแถวหนึ่งๆในตารางข้อมูลหนึ่งๆ เรามักจะท าการเขียนข้อมูลใหม่ทับข้อมูลเดิมโดยไม่สนใจข้อมูลเก่าที่ถูกเขียนทับ แต่อย่างไรก็ตามอาจมีบางสถานการณ์ที่ เราต้องเก็บค่าของข้อมูลเก่าไว้ด้วยเช่นกัน ตัวอย่างเช่น เกรดเฉลี่ยของนิสิตที่มีการเปลี่ยนแปลงเมื่อจบภาคการศึกษาหนึ่งๆ เป็นต้น โดยข้อมูลที่ต้องท าการจัดเก็บค่าของข้อมูลเก่าที่มีการเปลี่ยนแปลงจะถูกเรียกว่า “time-variant data” ที่ซึ่งค่าของข้อมูลจะมีการเปลี่ยนแปลงไปตามกาลเวลา

การจัดเก็บข้อมูลที่มีความเปลี่ยนแปลงทั้งหมดจะเปรียบได้กับการจัดเก็บข้อมูลที่มีลักษณะเป็น “multivalued attribute” ในเอ็นทิตี้หนึ่งๆ โดยในการจัดเก็บข้อมูลที่มีความเปลี่ยนแปลงทั้งหมดจะต้องท าการสร้างเอ็นทิตี้ใหม่ที่มีความสัมพันธ์ในรูปแบบ 1:M กับเอ็นทิตี้หลัก (เอ็นทิตี้ที่พิจารณา) โดยในเอ็นทิตี้ใหม่จะประกอบด้วยค่าที่ปรากฏของข้อมูล วันที่มีการเปลี่ยนแปลงหรือจัดเก็บข้อมูล และข้อมูลอ่ืนๆที่เกี่ยวข้อง ตัวอย่างเช่น ถ้าเราต้องการจัดเก็บข้อมูลผู้จัดการแผนกของทุกแผนกที่ซึ่งจะมีการเปลี่ยนแปลงโยกย้ายต าแหน่ง ดังแสดงในรูป 5.12


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

จากรูป 5.12 เราจะสังเกตุได้ว่าเอ็นทิตี้ MGR_HIST จะเป็นเอ็นทิตี้ที่สร้างขึ้นใหม่ที่มีความสัมพันธ์กับเอ็นทิตี้ EMPLOYEE ในรูปแบบ 1:M และมีความสัมพันธ์กับเอ็นทิตี้ DEPARTMENT ในรูปแบบ 1:M ที่ซึ่งจะแสดงถึงพนักงานคนหนึ่งๆจะสามารถเป็นหัวหน้าแผนกหนึ่งๆได้เพียงแผนกเดียวเท่านั้น แต่เมื่อกาลเวลาผ่านไปท าจะให้พนักงานคนนั้นๆสามารถเปลี่ยนไปเป็นหัวหน้าแผนกอ่ืนได้เนื่องจากเราท าการจัดเก็บข้อมูลที่มีการเปลี่ยนแปลงทั้งหมด และจากการสร้างเอ็นทิตี้ MGR_HIST จะท าให้เราต้องท าการจัดเก็บข้อมูลวันที่ที่มีการเปลี่ยนแปลงของข้อมูลไว้ใน DATE_ASSIGN ของเอ็นทิตี้ MGR_HIST ที่ซึ่งจะบ่งบอกถึงวันที่ที่พนักงานคนหนึ่งๆรับต าแหน่งหัวหน้าแผนก นอกจากนั้น การก าหนด primary key ส าหรับเอ็นทิตี้ MGR_HIST ที่มีลักษณะเป็น composite primary key จะท าให้พนักงานคนหนึ่งๆสามารถเป็นหัวหน้าแผนกเดิมได้หลายครั้ง แต่จะเป็นหัวหน้าแผนกในช่วงเวลาที่แตกต่างกัน

จากการจัดเก็บข้อมูลทั้งหมดที่มีการเปลี่ยนแปลงจะท าให้เราสามารถค้นหาได้ว่าใครคือหัวหน้าแผนกหนึ่งๆได้โดยการค้นหาแถวของข้อมูลที่มีค่าของข้อมูลในแอทริบิว DEPT_ID ตรงกับรหัสแผนกที่เราต้องการที่ซึ่งอาจมีหลายแถวข้อมูล จากนั้นเราจะท าการเลือกแถวของข้อมูลที่มีค่าของข้อมูลในแอทริบิว DATE_ASSIGN ที่เป็นวันที่ล่าสุด ที่ซึ่งจะท าให้เราได้แถวข้อมูลเพียงแถวเดียวที่สามารถบ่งบอกถึงหัวหน้าแผนกคนปัจจุบัน และเรายังสามารถค้นหาได้อีกว่าใครคือหัวหน้าแผนกคนก่อนหน้าได้อีกด้วย แต่ในทางกลับกัน ERD ในรูป 5.12 จะท าการแยกการจัดเก็บข้อมูลหัวหน้าแผนกคนปัจจุบันกับหัวหน้าแผนกคนก่อนหน้าที่ซึ่งข้อมูลหัวหน้าแผนกคนปัจจุบันจะถูกจัดเก็บในเอ็นทิตี้ DEPARTMENT (ด้วยการเพ่ิมแอทริบิว EMP_NUM ที่จะท าหน้าที่เป็น foreign key ในเอ็นทิตี้ DEPARTMENT และท าการเพ่ิมการจัดเก็บแอทริบิว DATE_ASSIGN เพ่ือที่จะได้ทราบถึงวันที่ที่หัวหน้าแผนกคนปัจจุบันเริ่มด ารงต าแหน่ง) แต่ในส่วนของข้อมูลหัวหน้าแผนกคนก่อนหน้าจะถูกจัดเก็บในเอ็นทิตี้ MGR_HIST ตามล าดับ แต่อย่างไรก็ตามเมื่อมีการเปลี่ยนแปลงหัวหน้าแผนกใหม่ เรา


จะต้องด าเนินการ 2 ขั้นตอนคือ 1) ท าการค้นหาข้อมูลหัวหน้าแผนกคนปัจจุบันในเอ็นทิตี้ DEPARTMENT จากนั้นท าการจัดเก็บข้อมูลต่างๆ (DEPT_ID, EMP_NUM, DATE_ASSIGN) ของหัวหัวแผนกคนปัจจุบันไว้ใน MGR_HIST ที่ซึ่งจะเป็นกระบวนการที่บ่งบอกว่าหัวหน้าแผนกคนปัจจุบันได้กลายเป็นอดีตหัวหน้าแผนกไปแล้ว และ 2) ท าการอัพเดทข้อมูลหัวหน้าแผนกในเอ็นทิตี้ DEPARTMENT ตามข้อมูลหัวหน้าแผนกคนใหม่

5.4.3 กรณีศึกษาที่ 3: FAN TRAP ในการออกแบบแบบจ าลองข้อมูลเราควรที่จะสามารถระบุถึงความสัมพันธ์ระหว่างเอ็นทิตี้ได้อย่างเหมาะสม แต่อย่างไรก็ตาม อาจมีหลายๆครั้งที่เกิดข้อผิดพลาดในการสื่อสารระหว่างผู้ออกแบบฐานข้อมูลและผู้ใช้ (พนักงานผู้ให้ข้อมูล) จึงเป็นเหตุให้เกิดข้อผิดพลาดในการระบุถึงความสัมพันธ์ระหว่างเอ็นทิตี้ได้ จากความผิดพลาดดังกล่าว จะท าให้ ERD อาจมี “design trap” ที่ซึ่งจะเป็นข้อผิดพลาดที่เกิดจากการระบุถึงความสัมพันธ์ที่ไม่ถูกต้องเหมาะสม โดย design trap ที่มักพบบ่อยใน ERD จะมีลักษณะเป็น fan trap ที่จะเกิดจากความผิดพลาดในการแสดงถึงความสัมพันธ์ในรูปแบบ 1:M ตัวอย่างเช่น ถ้าเราพิจารณากฎเกณฑ์ทางธุรกิจที่บ่งบอกว่า “ในลีกบาสเกตบอล JCB จะมีหลายดิวิชั่น แต่ละดิวิชั่นจะมีหลายทีมและมีผู้เล่นหลายคน” จากกฎทางธุรกิจดังกล่าวจะเป็นกฎที่ไม่สมบูรณ์เนื่องจากมีความสัมพันธ์เพียงด้านเดียว แต่ถ้าเราท าการสร้าง ERD จากกฎที่ไม่สมบูรณ์ดังกล่าวจะท าให้เราได้ ERD ดังรูป 5.13 ที่ซึ่งเราจะสังเกตุได้ว่าเอ็นทิตี้ DIVISION จะมีความสัมพันธ์กับเอ็นทิตี้ TEAM ในรูปแบบ 1:M และจะมีความสัมพันธ์กับเอ็นทิตี้ PLAYER ในรูปแบบ 1:M ด้วยเช่นกัน แต่อย่างไรก็ตาม การก าหนดความสัมพันธ์ดังกล่าวนั้นยังไม่ถูกต้อง ตัวอย่างเช่น ยังไม่มีการก าหนดความสัมพันธ์ระหว่างเอ็นทิตี้ PLAYET และ TEAM เป็นต้น นอกจากนั้นรูป 5.13 ยังแสดงถึงตัวอย่างความสัมพันธ์ (fan out) ระหว่าง DIVISION กับ TEAM และ ความสัมพันธ์ระหว่าง DIVISION กับ PLAYER ด้วยเช่นกัน

รูปที่ 5.13 ตัวอย่าง ERD ที่มีปัญหา fan trap


จากปัญหาในรูป 5.13 เราสามารถท าการแก้ไขรูปแบบความสัมพันธ์ได้ดังแสดงในรูป 5.14 ที่ซึ่งจะสามารถก าจัดปัญหาเกี่ยวกับ fan trap ได้ โดยจากรูปเราสามารถทราบได้โดยง่ายว่าผู้เล่นคนหนึ่งๆนั้นเป็นผู้เล่นสังกัดทีมใด และยังสามารถทราบได้อีกว่าผู้เล่นคนหนึ่งๆเล่นอยู่ในดิวิชั่นใด

รูปที่ 5.14 ตัวอย่าง ERD ที่ท าการแก้ไขปัญหา fan trap แล้ว

5.4.4 กรณีศึกษาที่ 4: ความสัมพันธ์ที่มีความซ้ าซ้อน ความสัมพันธ์ที่ซ้ าซ้อน (redundant relationship) จะปรากฏขึ้นเมื่อมีหลายๆความสัมพันธ์เกิดขึ้นกับเอ็นทิตี้ที่ซึ่งจะมีปัญหากับความสอดคล้องของข้อมูล ตัวอย่างเช่น ERD ในรูป 5.15 ที่จะแสดงถึงความสัมพันธ์ระหว่างดิวิชั่นและผู้เล่นผ่านเอ็นทิตี้ TEAM ได้โดยไม่ต้องท าการจัดเก็บข้อมูลดิวิชั่น (DIV_ID) ไว้ในเอ็นทิตี้ PLAYER แต่อย่างใด จากความซ้ าซ้อนดังกล่าว เราสามารถลบแอทริบิว DIV_ID ออกจากเอ็นทิตี้ PLAYER ที่ซึ่งจะท าให้ความซ้ าซ้อนของความสัมพันธ์ระหว่างเอ็นทิตี้หายไป

รูป 5.15 ตัวอย่างความสัมพันธ์ที่มีความซ้ าซ้อน


ค าถามท้ายบท 1. entity subtype คืออะไร? เพราะเหตุใดเราจึงต้องท าการประยุกต์ใช้ entity subtype? 2. entity subtype จะใช้ในการจัดเก็บข้อมูลที่มีลักษณะใด? 3. specialization hierarchy คืออะไร? 4. subtype discriminator คืออะไร? จงยกตัวอย่างประกอบ 5. overlapping subtype คืออะไร? จงยกตัวอย่างประกอบ 6. ความแตกต่างระหว่าง partial completeness และ total completeness คืออะไร? 7. entity cluster คืออะไร? และประโยชน์ของการประยุกต์ใช้ entity cluster คืออะไร? 8. คุณลักษณะที่ดีของ primary key คืออะไร? 9. เราควรประยุกต์ใช้ composite primary key ในสถานการณ์ใด? จงยกตัวอย่างประกอบ 10. surrogate primary key คืออะไร? และเราจะสามารถประยุกต์ใช้ surrogate primary key ได้ใน

สถานการณ์ใด?

บทที่ 5 การสร้างแบบจ าลองขั้นสูง · 2015....

Documents