Download Document

DBMS
Database Management System
ส่ วนที่ 2 Database Design
บทที่
4 โมเดลจำลองควำมสัมพันธ์ระหว่ำงข้อมูล (ER-Diagram)
บทที่ 5 รู ปแบบที่เป็ นบรรทัดฐำน (Normalization)
4.2
วงจรชีวิตการพัฒนาฐานข้ อมูล
Database Life Cycle : DBLC
วิเครำะห์ควำมต้องกำร
Initial Study
บำรุ งรักษำ
ออกแบบฐำนข้อมูล
Maintenance
Database Design
ใช้งำนจริ ง
สร้ำงฐำนข้อมูล
Operation
Implement and Loading
ทดสอบระบบฐำนข้อมูล
Testing and Evaluation
Database Management System
4.3
Database Life Cycle :DBLC
Initial Study :วิเครำะห์ควำมต้องกำรของผูใ้ ช้
 Data Design :ออกแบบฐำนข้อมูล (Data Driven, Joint
Data and Function-driven)
 Implementation and Loading :สร้ำงเป็ นฐำนข้อมูล
 Testing and Evaluation :ทดสอบฐำนข้อมูลที่สร้ำง
 Operation :ใช้งำนฐำนข้อมูล
 Maintenance and Evaluation :บำรุ งรักษำฐำนข้อมูล
 Database
Database Management System
บทที่ 4
โมเดลจำลองควำมสั มพันธ์ ระหว่ ำงข้ อมูล
(ER-Diagram)
4.5
Outline
 ประโยชน์ของกำรออกแบบฐำนข้อมูล
 ขั้นตอนในกำรออกแบบฐำนข้อมูล
 ER-Diagram
 Map
ER to Relation
Database Management System
4.6
การออกแบบฐานข้ อมูลมีประโยชน์ อย่ างไร
 เป็ นกำรวำงแผนว่ำจะเก็บข้อมูลต่ำงๆ ที่จำเป็ นต้องใช้ในระบบงำน
ไว้ในตำรำงใดบ้ำง โดยยังคงมีควำมสัมพันธ์ระหว่ำงข้อมูลไว้ได้
และสำมำรถเรี ยกดูขอ้ มูลที่เก็บไว้เพื่อมำใช้งำนได้ตำมปกติ
 มองเห็นควำมสัมพันธ์ระหว่ำงข้อมูลทั้งหมดที่มีอยู่ โดยข้อมูลบำง
ตัวอำจจะเกี่ยวข้องกับข้อมูลอื่นๆหลำยตัว อำจทำให้เกิดกำรเก็บ
รำยละเอียดของข้อมูลนั้นซ้ ำซ้อนกันได้
Database Management System
4.7
ขัน้ ตอนในการออกแบบฐานข้ อมลู
1. Requirement Analysis
(ER-Diagram)
2. Conceptual Design
Database Designer
3. Logical Design
(Normalization)
4. Schema Refinement
5. Physical Design
6. Security Design
DBA
7. Maintenance
Database Management System
4.8
1. สารวจความต้ องการใช้ งาน
(Requirement Analysis)
 เป็ นขั้นตอนแรกที่สำคัญมำกต่อระบบฐำนข้อมูล
 จะรู ้ควำมต้องกำรของผูใ้ ช้งำนและระบบได้อย่ำงไร
Database Management System
4.9
จะร้ ูความต้ องการของผ้ ใู ช้ งานได้ อย่ างไร
 ศึกษำเอกสำรที่ใช้ในระบบงำนนั้นๆ
 กำรใช้แบบสอบถำม
 กำรพูดคุยกับผูใ้ ช้โดยตรง
 ข้อมูลที่เรำจำเป็ นต้องเก็บรวบรวมเพื่อนำไปใช้ในกำรออกแบบ
ระบบฐำนข้อมูล ประกอบด้วย
– ข้อมูลแต่ละตัวที่จำเป็ นต้องใช้ในระบบงำน(Entity)
– รำยละเอียดของข้อมูลนั้น(Attribute)
– ควำมสัมพันธ์ระหว่ำงข้อมูลทั้งหมด(Relationship)
Database Management System
4.10
ตั้งคาถาม ถามระบบ
 วิธีที่จะตรวจสอบว่ำควำมต้องกำรที่สำรวจได้เพียงพอที่จะใช้งำน
จริ งแล้วหรื อไม่ คือ ลองตั้งคำถำมที่ตอ้ งกำรดูวำ่ ข้อมูลที่จะเก็บใน
ฐำนข้อมูลสำมำรถนำมำใช้ตอบคำถำมนั้นๆได้ท้ งั หมดหรื อไม่
 ถ้ำตอบได้ ก็แสดงว่ำเรำไม่ได้ลืมเก็บข้อมูลที่จำเป็ นต้องใช้ตวั อื่นอีก
Database Management System
4.11
2. ออกแบบฐานข้ อมูลระดับแนวคิด
(Conceptual Design)
หลังจากได้ความต้องการแล้ว ก็จะทาการออกแบบเชิง
แนวคิด(conceptual design)
 โดยใช้ตว
ั แบบข้อมูลเชิงแนวคิด (conceptual data
model) เช่น ER-Model ในการออกแบบเค้าร่างเชิง
แนวคิด
 ผูอ
้ อกแบบฐานข้อมูลจะต้อง
กำหนดเอนติติ้และแอตทริ บิวต์
กำหนดคอนสเตรนต์
กำหนดควำมสัมพันธ์
 หลังจากได้เค้าร่างเชิงแนวคิดแล้ว ผูว
้ เิ คราะห์ระบบจะ
นาเค้าร่างเชิงแนวคิดไปยืนยันกับผูใ้ ช้ถงึ ความต้องการ
ทัง้ หมด เพือ
่ ให้แน่ ใจว่าไม่ได้หลงลืมความต้องการหรือ
ข้อมูลบางส่วนไป
Database Management System

4.12
3. ออกแบบฐานข้ อมูลระดับตรรกะ
(Logical Design)
 เมือ
่ ได้ออกแบบเค้าร่างเชิงแนวคิดทีไ่ ด้รบ
ั การ
ยืนยันจากผูใ้ ช้แล้ว ก็จะจัดทาการออกแบบเชิง
ตรรกะ (logical design) เพือ
่ ออกแบบเค้าร่าง
เชิงตรรกะ(logical schema) ให้เป็ นไปตามตัว
แบบข้อมูลของระบบการจัดการฐานข้อมูล
 เป็ นขั้นตอนกำรแปลง ER-Diagram ไปเป็ นตำรำงตำม
Relational data Model
Database Management System
4.13
4. ปรับโครงสร้ างข้ อมูล
(Schema Refinement)
 ตำรำงที่ได้จำกกำรออกแบบฐำนข้อมูลในระดับ
Logical ยัง
ไม่ใช่ตำรำงที่เหมำะสำหรับนำไปเก็บข้อมูลจริ ง เนื่องจำกอำจทำให้
เกิดควำมซ้ ำซ้อนของข้อมูล และปัญหำต่ำงๆ เช่น ปัญหำกำรเพิม่
ข้อมูล(Insert Anomaly)
 ขั้นตอนนี้ เป็ นกำรปรับโครงสร้ำงตำรำง โดยกำรทำ
Normalization ซึ่งจะทำให้ได้จำนวนตำรำงมำกขึ้นกว่ำเดิม
แต่ปัญหำต่ำงๆจะถูกกำจัดออกไป
Database Management System
4.14
5. ออกแบบฐานข้ อมลู ระดับกายภาพ
(Physical Design)
 เป็ นหน้ำที่
DBA เพื่อให้ระบบฐำนข้อมูลเกิดประสิ ทธิภำพมำก
ที่สุด
 กำรออกแบบในระดับนี้ เกี่ยวข้องกับกำรสร้ำงอินเด็กซ์
(Index)และกำรเลือกโครงสร้ำงข้อมูลระดับภำยใน
(Internal View) เพื่อให้สอดคล้องกับลักษณะกำรใช้งำน
ข้อมูลที่เกิดขึ้นบ่อยๆ เช่น สร้ำงอินเด็กซ์ที่คอลัมน์ซ่ ึงมักถูกใช้
กำหนดเป็ นเงื่อนไขในกำรดึงข้อมูล
Database Management System
4.15
6. ควบคมุ การนาไปใช้
(Security Design)
 เป็ นกำรกำหนดสิ ทธิ ในกำรใช้งำนข้อมูลที่
DBA จะ
กำหนดขึ้นตำมควำมเหมำะสมและควำมต้องกำรของ
ผูใ้ ช้งำน
Database Management System
7. การบารุงรักษาระบบ
(Maintenance Database System)
4.16
 เป็ นขั้นตอนที่มีควำมสำคัญกับระบบมำก
 เมื่อระบบทำงำนช้ำลง
ต้องตรวจสอบ
 เมื่อพบข้อผิดพลำดจำกข้อมูลที่เก็บ
 เมื่อควำมต้องกำรของระบบหรื อผูใ้ ช้เปลี่ยนไป
 เมื่อนโยบำยขององค์กรเปลี่ยนไป
 กำรสำรองข้อมูล เมื่อไร backup / กำรกูค้ ืนข้อมูล
 กำรป้องกันไวรัสทุกชนิ ด โจรกรรมข้อมูล
Database Management System
4.17
การออกแบบฐานข้ อมลู
 เป็ นเรื่ องที่สำคัญมำก เพรำะมีผลต่อประสิ ทธิ ภำพในกำรใช้งำน
 ควรออกแบบอย่ำงรอบคอบ
 โดยต้องทำควำมเข้ำใจในระบบงำนก่อน
 เพื่อให้กำรออกแบบถูกต้องและครอบคลุมงำนของระบบทั้งหมด
ป้องกันกำรแก้ไขภำยหลังหรื อป้องกันควำมซ้้ ้าซ้อนของงำน
ที่ออกแบบ
Database Management System
4.18
Entity Relationship Data Model
 โดย ดร.ปี เตอร์ เชนน์ รำวปี
ค.ศ. 1976
 ER data model จัดเป็ น conceptual data model ที่ใช้ออกแบบ
ฐำนข้อมูลได้อย่ำงอิสระ ไม่ตอ้ งคำนึงถึงว่ำจะใช้ DBMS ชนิด
ไหน ยีห่ อ้ อะไร ด้วยคุณสมบัติเด่นนี้ทำให้ ER-model เป็ นที่
นิยมใข้งำนกันมำกในกำรวิเครำะห์และออกแบบฐำนข้อมูล
 ผลกำรออกแบบด้วย ER-model สำมำรถแสดงด้วยรู ปภำพ หรื อ
ER-Diagram
 นักวิเครำะห์และออกแบบสำมำรถใช้ ER-Diagram เสมือนเป็ น
เครื่ องมือในกำรอธิบำยองค์ประกอบ(Basic Structure) และ
ข้อกำหนดเงื่อนไข(Integrity constraint) ของฐำนข้อมูล
Database Management System
4.19
Entity Relationship Data Model(ต่อ)
นำ ER-Diagram ไปใช้ทบทวนยืนยันควำมเข้ำใจที่
ถูกต้องกับ user ของระบบงำนได้ เพรำะ ER-Diagram
ประกอบด้วยสัญลักษณ์ที่สื่อควำมหมำยเข้ำใจได้ง่ำย
เมื่อได้ ER-Diagram ที่ถูกต้องเหมำะสมกับระบบงำนแล้ว
และทรำบแล้วว่ำจะใช้ DBMS ชนิดใด จึงจะทำกำรแปลง
(Mapping) ให้ได้เป็ น Logical schema ที่ตรงกับ DBMS
Database Management System
4.20
Basic Structure
องค์ประกอบของโครงสร้างข้อมูล โดย ERmodel ประกอบด้วยโครงสร้างดังนี้
Entity
Relationship
Attribute
Primary
Key
Database Management System
4.21
Entity
 เอนติต้ ี(Entity)
– สิ่ งที่มีอยูใ่ นขอบเขตของระบบที่เรำสนใจ อำจเป็ น สิ่ งของ
คน สถำนที กำรกระทำ เหตุการณ์ โดยแต่ละเอนติต้ ีจะเก็บ
เรื่ องเดียวกัน
– เช่น นักศึกษา , รถยนต์, หนังสือ, การทาผิด,
เพลง, การเช่า ,ประวัตก
ิ ารทางาน, การประมูล,
การสัมมนา, น้าตก , บ้านเช่า เป็ นต้น
Database Management System
4.22
Attribute
 ลักษณะหรื อคุณสมบัติที่นำมำใช้อธิ บำยสิ่ งต่ำงๆ(Entity) และควำมสัมพันธ์
ต่ำงๆ(Relationship) ในระบบงำน
 เช่น attribute ที่นำมำอธิ บำย Entity ของ ลูกค้ำ ในระบบงำนขำยสิ นค้ำ
– ชื่อ สกุล ที่อยู่ รำยได้ สถำนภำพ อำชีพ
 เช่น attribute ที่นำมำอธิ บำย Entity ของ กำรลดรำคำ ในระบบงำนแสดงสิ นค้ำ
– ครั้งที่ วันที่เริ่ มต้น วันสุ ดท้ำย ชื่อสถำนที่จดั งำน
 เช่น attribute ที่นำมำอธิ บำย Relationship ของซื้ อสิ นค้ำ ในระบบงำนขำย
สิ นค้ำ
– วันที่ซ้ื อ วันที่ตอ้ งกำรส่ งสิ นค้ำ จำนวนที่ซ้ื อสิ นค้ำ
Database Management System
4.23
Relationship
ควำมสัมพันธ์ระหว่ำง entity ต่ำงๆ ซึ่ งเปรี ยบเทียบ
ได้กบั กริ ยำโครงสร้ำงของ 1 ประโยค โดยทัว่ ไป
ประกอบด้วย ประธำน กริ ยำ กรรม
– ประธำน และ กรรม เป็ นคำนำม เปรี ยบเป็ น Entity
– กริ ยำแสดงควำมสัมพันธ์ระหว่ำงประธำนกับกรรม
เปรี ยบเป็ น Relationship
เช่น นักศึกษำ 1 คน เรี ยนได้หลำยๆวิชำใน 1เทอม
Database Management System
4.24
Degree of Relationship
 Degree
ของชนิดความสัมพันธ์ คือ จานวนของ
ชนิดของ entity ทีม
่ ส
ี ว่ นร่วมในความสัมพันธ์นน
้ั
– Unary (Recursive) Relationship
ความสัมพันธ์ภายใน
entity เดียวกัน
– Binary Relationship
ความสัมพันธ์ระหว่าง
2 entities
– Ternary Relationship
ความสัมพันธ์ระหว่าง
3 entities
Database Management System
4.25
ตัวอย่าง ของ Degree of Relationship
Unary
นักศึกษำ
m
พนักงำน
หัวหน้ำงำน
M
ลงทะเบียน
1
M
วิชำเรี ยน
อำจำรย์
Ternary
M
วิชำเรียน
M
สอน
M
หนังสื อ
Binary
Database Management System
4.26
Cardinality of Relationships

จำนวน entity ต่อ entity ในควำมสัมพันธ์
– One to One relationship (1 to 1)
– One to Many relationship (1 to M)
– Many to Many relationship (M to M)
Database Management System
4.27
Mapping Cardinalities
One to one
One to many
Database Management System
Mapping Cardinalities
Many to one
4.28
Many to many
Database Management System
4.29
One to One Relationship
ั
 ควำมสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติต้ ีแรก สำมำรถจับคู่กบ
ข้อมูลในเอนติต้ ีที่สองได้เพียงแถวเดียวเท่ำนั้น
 เช่น ระบบข้อมูลมหำวิทยำลัย
อำจำรย์
1
เป็ นคณบดี
1
คณะ
– อาจารย์ 1 คน เป็ นคณบดีได้เพียง 1 คณะ และ
– แต่ละคณะ มีอำจำรย์ที่เป็ นคณบดีได้คนเดียวเท่ำนั้น
Database Management System
4.30
One to Many
ั
 ควำมสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติต้ ีแรก สำมำรถจับคู่กบ
ข้อมูลในเอนติต้ ีที่สองได้มำกกว่ำหนึ่งแถว
 เช่น ระบบสัง่ ซื้ อสิ นค้ำของลูกค้ำ
1
ลูกค้ำ
สัง่ ซื้อ
– ลูกค้ำ 1 คนสัง่ ซื้อใบสัง่ ซื้ อได้หลำยใบ และ
– ใบสัง่ ซื้อแต่ละใบ ถูกสัง่ ซื้ อจากลูกค้าเพียงคนเดียว
M
ใบสัง่ ซื่อ
Database Management System
4.31
Many to Many
ควำมสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติต้ ีแรก สำมำรถจับคูก่ บั ข้อมูลในเอน
ติต้ ีที่สองได้มำกกว่ำหนึ่ งแถว
และในทำงกลับกันข้อมูลแต่ละแถวของฝั่งเอนติต้ ีที่สองก็สำมำรถจับคู่กบั ข้อมูลใน
เอนติต้ ีแรกได้มำกกว่ำหนึ่ งแถว
 เช่น ระบบสั่งซื้ อสิ นค้ำของลูกค้ำ

สิ นค้ำ
M
ถูกสัง่ ซื้อ
M
ใบสัง่ ซื้อ
– สิ นค้ำ 1 อย่าง ถูกสัง่ ซื้ อตำมใบสัง่ ซื้ อได้หลำยใบ และ
– ใบสัง่ ซื้อ 1 ใบสัง่ ซื้อสิ นค้ำได้หลำยอย่าง
Database Management System
4.32
Primary Key
 Attribute
หรือ กลุม
่ ของ attribute ทีแ
่ สดง
เอกลักษณ์ ของสิง่ ใดสิง่ หนึ่งได้ ดังนัน
้ สิง่
ต่างๆ จะมีคา่ primary key ไม่ซา้ กันเสมอ
Database Management System
เอนติตี้
แอตทริบิวต์ประกอบ
เอนติติ้แบบอ่อน
(Weak Entity)
ความสัมพันธ์
Partial Key เป็ น key ของ
weak entity ซึ่งค่า partial
key ซา้ กันได้
ความสัมพันธ์แบบอ่อน
(Weak Relationship)
derived attribute เก็บ
ผลของการคานวณ หรือ
แปลงค่ามาจากแอตทริบวิ
เดิม
แอตทริบิวต์
ั ันธ์ทข
ความสมพ
ี่ อ
้ มูลทุกๆ
แถวในเอนติต ิ้ E2 สามารถ
จ ับคูไ่ ด้ก ับข้อมูลแถวใด
แถวหนึง่ ของ E1 ได้
เรียกว่า ข้อมูลใน E2 เป็น
total participation ก ับ
E1
แอตทริบิวต์ที่เป็ น
primary key
แอตทริบิวต์ที่มีหลายค่า
ั ันธ์ทข
ความสมพ
ี่ อ
้ มูลทุกๆ
แถวในเอนติต ิ้ E1 สามารถ
จ ับคูไ่ ด้ก ับข้อมูลแถวใด
แถวหนึง่ ของ E2 ได้
เรียกว่า ข้อมูลใน E2 เป็น
partial participation
ก ับ E1
E1
R
E2
E1
R
E2
4.34
สัญลักษณ์ ของ ER Model
สัญลักษณ์
สี่ เหลี่ยมผืนผ้ำ
ควำมหมำย
เอนติต้ ี
เอนติติ้แบบอ่อน
(Weak Entity)
ควำมสัมพันธ์
ER-Model ตำมแบบของ Peter Pin Shan Chen
Database Management System
4.35
สัญลักษณ์ ของ ER model(ต่ อ)
สัญลักษณ์
ควำมหมำย
ควำมสัมพันธ์แบบอ่อน
(Weak Relationship)
แอตทริ บิวต์
แอตทริ บิวต์ที่เป็ น primary key
Database Management System
4.36
สัญลักษณ์ ของ ER Model(ต่ อ)
สัญลักษณ์
ควำมหมำย
แอตทริ บิวต์ที่มีหลำยค่ำ
แอตทริ บิวต์ประกอบ (แอตทริ บิวต์
ด้ำนบนเป็ นส่ วนประกอบของแอตทริ บิวต์
ด้ำนล่ำง)
Partial Key เป็ น key ของ
weak entity ซึง่ ค่า partial
key ซา้ กันได้
Database Management System
4.37
สัญลักษณ์ ของ ER model(ต่ อ)
สัญลักษณ์
ควำมหมำย
ดีไรฟ์ แอตทริ บิ่วต์(derived attribute)
เก็บผลของกำรคำนวณหรื อแปลงค่ำมำจำกแอตทริ
บิวเดิม
E1
R
E2
ควำมสัมพันธ์ที่ขอ้ มูลทุกๆแถวในเอนติติ้ E2
สำมำรถจับคู่ได้กบั ข้อมูลแถวใดแถวหนึ่งของ
E1 ได้ เรี ยกว่ำ ข้อมูลใน E2 เป็ น total
participation กับ E1
Database Management System
4.38
สัญลักษณ์ ของ ER model(ต่ อ)
สัญลักษณ์
E1
R
ควำมหมำย
E2
ควำมสัมพันธ์ที่ขอ้ มูลทุกๆแถวในเอนติติ้
E1 สำมำรถจับคู่ได้กบั ข้อมูลแถวใด
แถวหนึ่งของ E2 ได้เรี ยกว่ำ ข้อมูลใน
E2 เป็ น partial
participation กับ E1
Database Management System
4.39
Participation Constraint
 เงือ
่ นไขการมีสว่ นร่วม
คือ จานวนตา่ สุดของ
entity ทีอ
่ ก
ี entityหนึ่งมีความสัมพันธ์ดว้ ย มี 2
แบบคือ
– Total Participation
entity หนึ่งentity จะต้องมีความสัมพันธ์กบั entity
อืน
่ อย่างน้อยหนี่ง entity เช่น อาจารย์ทก
ุ คนต้องสังกัด
อย่างน้อยใน หนี่งคณะ เป็ นต้น การมีสว่ นร่วมทัง้ หมดจะ
แสดงด้วยเส้นคูท
่ างด้านชนิดของentityทีท
่ ก
ุ entity ใน
ชนิดนัน
้ ต้องเข้าร่วมในความสัมพันธ์
 การที่
อำจำรย์
M
สังกัด
1
คณะ
Database Management System
4.40
Participation Constraint(ต่อ)
– Partial Participation
หนึ่งentity มีความสัมพันธ์กบั entity อืน
่
อย่างน้อยศูนย์entity คือในชนิดของentity เดียวกันอาจมี
บางentity ทีม
่ ีสว่ นร่วมในความสัมพันธ์นน
้ ั ในขณะทีบ
่ าง
entity ทีไ่ ม่มีสว่ นร่วมในความสัมพันธ์นน
้ ั เลย เช่น แผนก
บางแผนกไม่มีพนักงานสังกัดเลย และบางแผนกอาจมี
พนักงานสังกัดหลายคน
 การมีสว
่ นร่วมบางส่วนจะแสดงโดยใช้เส้นเดียวด้านชนิด
ของentity ทีบ
่ างentityในชนิดนัน
้ มีสว่ นร่วมใน
ความสัมพันธ์ เช่น เส้นเดียวจากentity แผนก
 การทีe
่ ntity
อำจำรย์
M
สังกัด
1
แผนก
Database Management System
4.41
ประเภทของ attribute
Attribute คือ แอตทริ บิวที่เก็บค่ำได้เพียงค่ำเดียว
เท่ำนั้น เช่น รหัสลูกค้ำ ลูกค้ำ 1 คนมีรหัสลูกค้ำได้หมำยเลขเดียว
 Multi-valued attribute คือ แอตทริ บิวต์ที่เก็บค่ำได้ต้ งั แต่
1 ค่ำขึ้นไป เช่น เบอร์โทรศัพท์ ของลูกค้า มีทง้ ั เบอร์
บ้าน เบอร์มอ
ื ถือ เป็ นต้น
 Simple
ลูกค้ำ
เบอร์โทรศัพท์
Database Management System
4.42
ประเภทของแอตทริ บิวต์ (ต่ อ)
attribute คือแอตทริ บิวต์ที่ประกอบด้วยแอ
ตทริ บิวต์หลำยตัวมำรวมกันจึงให้ควำมหมำยที่ชดั เจน
 Composite
จังหวัด
ชื่อ
ถนน
สกุล
อำเภอ
ชื่อ-สกุล
ที่อยู่
ลูกค้ำ
Database Management System
4.43
ประเภทของแอตทริ บิวต์ (ต่ อ)
attribute คือ แอตทริ บิวต์ที่เก็บผลกำรคำนวณหรื อ
แปลงค่ำมำจำกแอตทริ บิวต์อื่นๆ เช่น จำนวนเงิน(รำคำ*จำนวน)
 Derived
จำนวนพนักงำน
แผนก
รหัสแผนก
Database Management System
4.44
Weak Entity
 Weak
entity ต้องมีคณ
ุ สมบัติ 2 ข้อ คือ
1. ไม่มี Primary Key มีเพียง partial key (ซึง่ เป็ นค่าที่
ซา้ กันได้) ดังนัน
้ นาเอา partial key ไปรวมกับ
Primary key ของ Strong Entity ก็จะเป็ นค่าทีไ่ ม่ซา้
ได้
2. Weak entity ต้องมีความสัมพันธ์กบั Strong Entity
อย่างน้อย 1 entity คือ ลักษณะของกำรขึ้นต่อกัน คือ กำรที่เอนติต้ ี
หนึ่งจะเกิดขึ้นได้น้ นั ขึ้นกับอีกเอนติต้ ีหนึ่งว่ำปรำกฏอยูห่ รื อไม่
Database Management System
4.45
Weak Entity (ต่อ)
เอนติต้ ีพนักงำนและเอนติต้ ีญำติ ถ้ำไม่มีเอนติต้ ีพนักงำน
เอนติต้ ีญำติกจ็ ะไม่เกิดขึ้น
 ตัวอย่าง
รหัสพนักงำน
– เอนติต้ ีญำติ เป็ น Weak Entity
– เอนติต้ ีพนักงำน เป็ น Entity
พนักงำน
1
มี
ลำดับที่
M
ญำติ
-ญำติ เป็ น weak entity ที่ไม่มี primary key โดยคุณสมบัติ ลำดับที่ มีค่ำ
ซ้ ำกันในรี เลชัน่ ญำติ เพรำะคุณสมบัติ ลำดับที่ มีค่ำซ้ ำๆ กันได้ในหลำยญำติ เช่น
ลำดับที่ 1 เป็ นญำติ นำยขำว และลำดับที่ 1 เป็ นญำติ นำยแดง
-ฝั่งชนิดของentity ญำติ เป็ นแบบ Total Participation
Database Management System
Weak Entities(ต่ อ)
วิชำ
1
เปิ ดสอน
M
วิชำที่เปิ ดสอน
รหัสวิชำ
ชื่อวิชำ
ปี -ภำค
รหัสกำรเปิ ดสอน
เวลำเรี ยน
ชื่อวิชำ(รหัสวิชำ, ชื่อวิชำ)
วิชำที่เปิ ดสอน(รหัสวิชำ*, ปี -ภำค, กลุ่ม, เวลำเรี ยน)
กลุ่ม
4.47
ตัวอย่าง Recursive Relationships
 ตัวอย่ำง
กำรลงทะเบียนบำงวิชำ จะต้องเรี ยนวิชำอื่นมำ 1 วิชำ
(one to one)
1
วิชำที่ลงทะเบียน
Precond.
Course
1
วิชำที่ตอ้ งผ่ำนก่อน
Course(CourseID, CourseName, Unit, PrecondCourseID*)
Database Management System
4.48
Recursive Relationships(ต่ อ)
CourseID
CourseName
Unit
PrecondCourseID*
4123601
Database Management
System
3
4122202
4122202
Introduction to Database
3
4121202
Programming and
algorithm
3
4122101
Programing Language 1
3
4121202
Database Management System
ตัวอย่าง Recursive Relationships

ตัวอย่ำง กำรลงทะเบียนบำงวิชำ จะต้องเรี ยนวิชำอื่นมำ 1 วิชำหรื อหลำยๆ
วิชำ (many to many)
วิชำที่ลงทะเบียน
m
Precond.
Course
m
วิชำที่ตอ้ งผ่ำนก่อน
Precondition(CourseID, PrecondCourseID)
Course(CourseID , CourseName, Unit)
Recursive Relationships(ต่ อ)
Course
CourseID
CourseName
Unit
4123601
Database Management System
3
4122202
Introduction to Database
3
4121202
Programming and algorithm
3
4122101
Programing Language 1
3
Precondition
CourseID
PrecondCourseID
4123601
4122202
4123601
4122101
4121202
4121101
4122101
4121202
ตัวอย่าง Recursive Relationships
 ตัวอย่ำง
พนักงำนที่เป็ นหัวหน้ำ 1 คน มีลูกน้องได้หลำยคน ทั้ง
หัวหน้ำและลูกน้องก็เป็ นพนักงำนทั้งคู่ (one to many)
1
หัวหน้ำ
Manage
Employees
m
ลูกน้อง
Employees( EmpID, EmpName, BirthDate, MangerID*)
ตัวอย่าง Ternary Relationships
 เป็ นควำมสัมพันธ์ที่มีเอนติต้ ีที่เกี่ยวข้อง
3 เอนติต้ ี
 เช่นควำมสัมพันธ์ดีกรี 3 ของควำมสัมพันธ์ระหว่ำง ผูข้ ำย โครงกำร
สิ นค้ำ
– เนื่องจำกผูข้ ำยสำมำรถขำยสิ นค้ำให้กบั โครงกำรใดก็ได้
ตัวอย่าง Ternary Relationships
รหัสโครงกำร
โครงกำร
รหัสผูข้ ำย
รหัสสิ นค้ำ
M
ผูข้ ำย
M
สำหรับ
M
สิ นค้ำ
จำนวน
ผูข้ ำย-โครงกำร-สิ นค้ำ(รหัสผูข้ ำย, รหัสโครงกำร, รหัสสิ นค้ำ, จำนวน)
ตัวอย่าง Ternary Relationships
ID1
E1
ID3
1
ID2
E2
M
R
R (ID3, ID2, ID1)
M
E3
ID1
E1
ID3
M
ID2
E2
M
R
M
E3
R (ID3, ID2, ID1)
4.55
Aggregation
 Treat
Physician
Treatment
aggregation as any other entity type
M
Treat
M
Patient
M
Us
e
M
Drug
Physician(…), Patient(…), Drug(…)
Treat (PhysicianID, PatientID)
Use(PhysicianID, PatientID, DrugID)
Database Management System
หลักการแปลง ER เป็ นรี เลชั่น
1.
ให้แปลงเอนติติ้ทุกตัวเป็ นรี เลชัน่ และแปลงแอตทริ บิวต์
ทุกตัวของเอนติต้ ีให้เป็ นแอตทริ บิวต์ของรี เลชัน่
Customer
CusID
CusName
CusAdd
CusSurName
Customer(CusID, CusName, CusSurName, CusAdd)
หลักการแปลง ER เป็ นรี เลชั่น(ต่ อ)
2. เพิ่มแอตทริ บิวต์ให้กบั รี เลชัน่
2.1 ถ้ำควำมสัมพันธ์เป็ นแบบ 1 to 1 ให้นำ pk ของรี เลชัน่ ฝั่งใดฝั่ง
หนึ่งไปอยูใ่ นรี เลชัน่ ของอีกฝั่งหนึ่ ง
**ต้องให้ค่ำในแอตทริ บิวใหม่เป็ น Null น้อยสุ ดหรื อไม่มี
Teacher
ThID
1
เป็ นคณบดี
ThName
ThSurName
Teacher(ThID, ThName, ThSurName)
Faculty(FacID,FacName,ThID*)
1
Faculty
FacID
FacName
4.58
Teacher(ThID, ThName, ThSurName)
Faculty(FacID,FacName,ThID*)
Teacher(ThID, ThName, ThSurName,FacID*)
Faculty(FacID,FacName)
Database Management System
ThID
001
034
253
333
111
002
003
ThName
ผศ.วำสนำ
อ.สมคิด
รศ.ฉลำด
ผศ.สมำธิ
อ. ดุษฎี
อ. ประสงค์
อ. ปรำนี
ThSurName
ใจดี
ใจดี
ใจดี
ใจดี
ใจดี
ใจดี
ใจดี
FacID
FacName
4.59
ThID*
1
วิทยำศำสตร์
001
2
มนุษย์
034
3
วิทยำกำรจัดกำร
253
4
ครุ ศำสตร์
333
5
เทคโนโลยีอุตฯ
111Management System
Database
ThID
001
034
253
333
111
002
003
ThName
ผศ.วำสนำ
อ.สมคิด
รศ.ฉลำด
ผศ.สมำธิ
อ. ดุษฎี
อ. ประสงค์
อ. ปรำนี
FacID
ThSurName
ใจดี
ใจดี
ใจดี
ใจดี
ใจดี
ใจดี
ใจดี
FacID
1
2
3
4
5
4.60
FacName
1
วิทยำศำสตร์
2
มนุษย์
3
วิทยำกำรจัดกำร
4
ครุ ศำสตร์
5
เทคโนโลยีอุตฯ
Database Management System
4.61
หมายเหตุ
กรณี ที่เป็ น Total Partial Relationship
นำ PK ของด้ำนที่เป็ น Partial Relationship
ไปเป็ น FK ของด้ำนที่เป็ น Total Relationship
Database Management System
หลักการแปลง ER เป็ นรี เลชั่น(ต่ อ)
2. เพิ่มแอตทริ บิวต์ให้กบั รี เลชัน่
2.2 ถ้ำควำมสัมพันธ์เป็ นแบบ 1 to Mให้นำ pk ของรี เลชัน่ ฝั่งที่เป็ น
1ไปอยูใ่ นรี เลชัน่ ของฝั่งที่เป็ น M
CusName
Customer
1
ReqDate
CusID
M
สัง่ ซื้ อ
Orders
OrderDate
CusSurName
Customer(CusID, CusName, CusSurName)
Orders(OID,OrderDate, ReqDate ,CusID*)
OID
หลักการแปลง ER เป็ นรี เลชั่น(ต่ อ)
2. เพิ่มแอตทริ บิวต์ให้กบั รี เลชัน่
2.3 แอตทริ บิวต์ที่อยูบ่ นควำมสัมพันธ์ จะนำไปใส่ ในรี เลชัน่ ใด ก็ข้ ึนอยู่
กับว่ำเมื่อใส่ ลงในรี เลชัน่ นั้นแล้ว จะมีบำงแถวหรื อไม่มีแถวข้อมูลใดเลยที่มี
ค่ำในแอตทริ บิวต์เป็ น Null
CusName
Customer
1
ReqDate
CusID
M
สัง่ ซื้ อ
Orders
OrderDate
CusSurName
Customer(CusID, CusName, CusSurName)
Orders(OID,OrderDate, ReqDate ,CusID*)
OID
หลักการแปลง ER เป็ นรี เลชั่น(ต่ อ)
3. สร้ำงรี เลชัน่ ใหม่สำหรับควำมสัมพันธ์แบบ M to M
โดยสร้ำง PK ได้จำก กำรนำเอำ PK ของแต่ละรี เลชัน่
้ึ มาใหม่
มำประกอบกัน หรือ สร้างแอตทริบวิ ส์ขน
Discount
PName
Products
M
รำยกำรสัง่ ซื่อ
Amount
PID
M
Orders
UnitPrice
Price
Product(PID, PName, Price)
Orders(OID,OrderDate, ReqDate ,CusID*)
OrderDetail(OID*, PID*, Discount, Amount, UnitPrice)
OID
4.65
ตัวอย่ าง สร้าง primary key ใหม่
รหัสนักศึกษำ ชื่อ-นำมสกุล
นักศึกษำ
M
เกรด
ลงทะเบียน
กลุ่ม
รหัสวิชำ
M
วิชำ
นักศึกษำ (รหัสนักศึกษำ,ชื่อ-นำมสกุล)
ชื่อวิชำ
วิชำ (รหัสวิชำ,กลุ่ม,ชื่อวิชำ)
ลงทะเบียน (รหัสกำรลงทะเบียน,รหั สนักศึกษา*,รหั สวิชา*,กลุ่ม*,เกรด)
Database Management System
หลักการแปลง ER เป็ นรี เลชั่น(ต่ อ)
4. สำหรับเอนติติ้ที่มีแอตทริ บิวต์แบบหลำยค่ำ
 ให้สร้ำงรี เลชัน
่ เพิม่
ที่มีแอตทริ บิวต์แบบหลำยค่ำนั้น
 PK ของรี เลชัน
่ ใหม่เกิดจำก PK ของรี เลชัน่ เดิมประกอบกับ แอตทริ บิวต์ที่
เกิดจำกแอตทริ บิวแบบหลำยค่ำ
CusName
Customer
CusID
CreditNum
CusSurName
Customer(CusID, CusName, CusSurName)
CusCredit(CusID*, CreditNum)
4.67
หำกพบ multivalued attribute ควรแยกออกมำ
เป็ น composite attribute
ชื่อ
รหัส
นำมสกุล
เบอร์โทรศัพท์
พนักงำน
พนักงำน(รหัส,ชื่อ,นำมสกุล,เบอร์โทรศัพท์1,เบอร์โทรศัพท์2)
Database Management System
หลักการแปลง ER เป็ นรี เลชั่น(ต่ อ)
5. สำหรับเอนติต้ ีแบบอ่อน ให้สร้ำงเป็ นรี เลชัน่ และมี PK ที่มำจำก PK ของรี
เลชัน่ หนึ่งรวมกับ PK ของเอนติต้ ีแบบอ่อน
Invoice
Inv no
1
M
has
Date
Invoice(Inv no, Date)
InvoiceDetail( Inv no* ,Line)
Invoice
Detail
Line
4.69
Mulitvalued Attributes
และการแปลงเป็ นรีเลชั่น
Phone
Faculty Member
Degrees
Name
FACULTY_MEMBER (Name, Phone)
FACULTY_DEGREES (Name*, Degree)
Faculty Member
has
Degree
Degree
Database Management System
4.70
EER model
(Enhanced Entity Relationship Model)

เป็ น Model ที่นำแนวคิดของ ER Model มำเพิ่มเติมในเรื่ อง
1. ควำมสัมพันธ์แบบ Superclass/Subclassหรื อ
Supertype/Subtype
2. แนวคิดของ Generalization/Specialization ซึ่ งเป็ นแนวคิดที่ใช้
ในกำรสร้ำงควำมสัมพันธ์ของ Entity ที่เป็ น
Superclass/Subclass รวมทั้งกำรถ่ำยทอดคุณสมบัติ (Attribute
Inheritance)

เหมำะที่จะนำมำใช้กบั ระบบงำนทำงธุรกิจที่มีควำมสลับซับซ้อน ซึ่ งจะช่วยลด
ควำมซับซ้อนของข้อมูล กำรเขียน Model ทำได้ง่ำย
Database Management System
4.71
EER model

Superclass คือ รู ปแบบของ Entity ที่เป็ นต้นแบบของ Entity อื่นๆ โดย
Superclass จะประกอบไปด้วย Subclass ต่ำงๆ

Subclass คือ Entity ที่มีคุณสมบัติบำงอย่ำงที่แตกต่ำงจำกสมำชิกของSubclass
ด้วยกัน แต่จะมีคุณสมบัติพ้นื ฐำนตำม Superclass

ตัวอย่ ำง : Entity พนักงำน เป็ น Superclass ประกอบด้วยข้อมูล รหัสพนักงำน,ชื่อ ,
วันที่เริ่ มทำงำน
Entity นี้ประกอบด้วย Subclass คือ
- ผูบ้ ริ หำร จะมีขอ้ มูลเฉพำะ คือ รถและเงินเดือนประจำตำแหน่ง - ผูเ้ ชี่ยวชำญ จะมี
ข้อมูลเฉพำะเกี่ยวกับควำมชำนำญและค่ำตอบแทน
- พนักงำนแรงงำน จะมีขอ้ มูลเฉพำะ คืออัตรำค่ำจ้ำงรำยวัน
ข้อมูลของ Entity ที่เป็ น Subclass จะต้องมีขอ้ มูลทั้งหมดจำกSuperclass
Database Management System
Superclass/Subclass
4.72
รหัสพนักงำน
ชื่อพนักงำน
Manager
Employee
Specialist
-รถประจำตำแหน่ง
-ควำมชำนำญ
-เงินเดือนประจำตำแหน่ง
- ค่ำตอบแทนผูเ้ ชี่ยวชำญ
วันที่เริ่ มงำน
Labor
-ค่ำจ้ำงรำยวัน
Database Management System
4.73
การถ่ายทอดคุณสมบัติ
(Attribute Inheritance)
- Subclass จะรับถ่ำยทอดคุณสมบัติทุกๆอย่ำงจำก
Superclass
- ทำให้ไม่ตอ้ งกำหนด Attribute ซ้ ำซ้อนใน Subclass
- ตัวอย่ำง : Subclass ผูบ้ ริ หำร,ผูเ้ ชี่ยวชำญและพนักงำน
แรงงำน จะได้รับถ่ำยทอดคุณสมบัติทุกๆอย่ำงจำก
Superclass Employee
Database Management System
4.74
Generalization
• เป็ นกระบวนกำรจัดกำรกับ Entity ที่เป็ นแม่แบบ เพื่อใช้กำหนดลักษณะที่
เหมือนกันหรื อร่ วมกัน วิธีการนี ้เป็ นวิธีแบบล่างขึ ้นบน (Bottom-Up
Approach) ด้ วยกำรมองหำสิ่ งที่เหมือนกันใน Subclass เช่น กำร
พิจำรณำ Entity ที่เป็ น Subclass คือ ผูบ้ ริ หำร, ผูเ้ ชี่ยวชำญและ
พนักงำนแรงงำน ว่ำมีลกั ษณะอะไรที่เหมือนกัน เพื่อออกแบบ Entity ที่เป็ น
Superclass คือ Employee ซึ่ งมีขอ้ มูลร่ วมกัน คือ รหัสพนักงำน
ชื่อและวันที่เริ่ มทำงำน
• จะกำหนดซับคลำสก่อน แล้วค่อยหำว่ำซับคลำสทั้งหมดนั้นมีแอตทริ บิวต์อะไร
ที่เหมือนกันบ้ำง
Database Management System
4.75
Specialization
• เป็ นกระบวนการจัดการกับ Entity ทีม
่ ีความแตกต่างกันในกลุม
่ ของ
้ กับ Superclass วิธน
สมาชิกซึง่ ขึน
ี ี้เป็ นวิธแ
ี บบบนลงล่าง (TopDown Approach) ด้วยการมองจุดทีแ
่ ตกต่างกันระหว่าง
Subclass เช่น Superclass Employee ประกอบด้วยพนักงานที่
เป็ นผูบ
้ ริหาร ผูเ้ ชีย่ วชาญและพนักงานแรงงาน ซึง่ มีรายละเอียด
เฉพาะตามประเภทพนักงาน
• เครือ
่ งหมายทีใ่ ช้แสดงความสัมพันธ์ของ Superclass/Subclass
• เครือ
่ งหมาย U แสดงว่า Subclass เป็ น Subset ของ Superclass
• จุดเชือ
่ มต่อ คือ วงกลม
• เส้นทีล่ ากจาก Superclass มายัง Subclass คือ เส้นทีถ
่ า่ ยทอดคุณสมบัติ
Database Management System
4.76
ตัวอย่าง ธุรกิจมีการว่าจ้างพนักงาน
โดยมีพนักงานทีแ
่ ตกต่างกัน 3 ประเภท คือ
 1. Hourly Employees – พนักงานรายชั่วโมง

2. Salary Employees – พนักงานประจา ได้รบั เงินเดือน

3. Consultants – ทีป
่ รึกษา ได้รบั เงินพิเศษ
โดย Attribute ทีส่ าคัญของพนักงานแต่ละประเภท ประกอบด้วย
 Hourly Employee (Emp_no, Emp_name, Address,
Date_hired, Hourly_Rate)
 Salary Employee (Emp_no, Emp_name, Address,
Date_hired, Annual_Salary)
 Consultant ( Emp_no, Emp_name, Address,
Date_hired, Contract_No, Billing_Rate)
Database Management System
Emp_name
Emp_no
4.77
Address
Date_hired
Employee
d
U
U
Hourly
Employee
Salary
Employee
Hourly_rate
Annual_Salary
U
Consultant
Contact_no
Billing_Rate
Database Management System
4.78
สร้ าง EER model
ตามหลักการ specialization
ตำแหน่ง
รหัสพนักงำน
พนักงำน
ชนิดค่ำตอบแทน
ชื่อพนักงำน
เงินเดือน
เงินเดือน
พนักงำนที่ได้รับ เงินเดือน
d
รำยชัว่ โมง
อัตรำค่ำแรงต่อชม.
พนักงำนที่ได้รับค่ำตอบแทนเป็ น
ชัว่ โมง
พนักงำนได้รับค่ำจ้ำงเป็ นแบบใดแบบหนึ่ง
Database Management System
4.79
แปลง EER เป็ น relation
 แบ่ง
4 กรณี
– แปลงได้ 1 ตาราง โดยนาแอตทริบวิ ต์ของ
subclass ทุกตัว จับมาไว้ในตารางของ
superclass
– แปลงได้ตารางเท่ากับจานวนของ subclass
โดยนาแอตทริบวิ ต์ของ superclass ทุกตัว
ไปรวมกับแอตทริบวิ ต์ของแต่ละ subclass
Database Management System
4.80
แปลง EER เป็ น relation
 แบ่ง
4 กรณี
– 3.แปลงได้ตารางเท่ากับจานวน superclass
และsubclass โดยตารางทีเ่ ป็ น superclass
จะมีแอตทริบวิ ต์ของตัวมันเอง แต่สาหรับ
subclass ให้นา pk ของsuperclass ไป
รวมไว้ยงั แต่ละ subclass ด้วย
Database Management System
4.81
แปลง EER เป็ น relation
 แบ่ง
4 กรณี
– 4.ใช้ได้กบั ความสัมพันธ์ superclasssubclass แบบ overlapped
แปลงตารางได้เพียงตารางเดียวเท่านัน
้
คือ ตาราง
ทีเ่ กิดจาก superclass โดยนา attribute ทุกตัว
มาจาก subclass
และเพิม
่ attribute ใหม่ ให้มจี านวนเท่ากับ
subclass เพือ
่ เก็บ flagของsubclass
Database Management System
4.82
การแปลงเป็ นรี เลชั่น

ทำได้ 2 วิธีคือ
– วิธี 1 แปลงเป็ น 3 รี เลชัน่ คือ
พนักงำน(รหัสพนักงำน, ชื่อพนักงำน, ตำแหน่ง, ชนิดค่ำตอบแทน)
 เงินเดือน(รหัสพนักงำน, เงินเดือน)
 ค่ำตอบแทนเป็ นชม(รหัสพนักงำน, อัตรำค่ำแรง)

– เหมำะกับกำรใช้ขอ้ มูลพนักงำนบ่อยๆโดยไม่สนเรื่ องค่ำจ้ำง
– วิธี 2 แปลงเป็ น 2 รี เลชัน่ คือ
พนักงำนที่ได้รับเงินเดือน(รหัสพนักงำน, ชื่อพนักงำน, ตำแหน่ง, เงินเดือน)
 พนักงำนที่ได้รับค่ำตอบแทนเป็ นชม(รหัสพนักงำน, ชื่ อพนักงำน, ตำแหน่ ง, อัตรำค่ำแรงเป็ นชม)

– เหมำะกับควำมต้องกำรใช้ขอ้ มูลพนักงำนแยกกัน
Database Management System
4.83
สร้ าง EER model
ตามหลักการ specialization(ต่ อ)
ตำแหน่ง
รหัสพนักงำน
พนักงำน
ชนิดค่ำตอบแทน
ชื่อพนักงำน
เงินเดือน
เงินเดือน
พนักงำนที่ได้รับ เงินเดือน
O
รำยชัว่ โมง
อัตรำค่ำแรงต่อชม.
พนักงำนที่ได้รับค่ำตอบแทนเป็ น
ชัว่ โมง
พนักงำนแต่ละคนมีสิทธิ์ได้รับทั้งเงินเดือนและค่ำตอบแทนเป็ นชัว่ โมงด้วย
Database Management System
4.84
การแปลงเป็ นรี เลชั่น
 แปลงได้รีเลชัน
่ เดียวและเก็บข้อมูลทุกอย่ำงลงไป
 เพิ่มแอตทริ บิวต์ที่ทำหน้ำที่เป็ นแฟล็ก สำหรับเก็บค่ำ
T หรื อ F
 พนักงำน(รหัสพนักงำน,
ชื่อพนักงำน, ตำแหน่ง, แฟล็ก
เงินเดือน, เงินเดือน, แฟล็กค่ำตอบแทนเป็ นชม, อัตรำค่ำแรงต่อ
ชม)
– ถ้ำแฟล็กเงินเดือน มีค่ำเป็ นจริ ง, ควรต้องมีค่ำในช่องเงินเดือนด้วย
Database Management System
4.85
สร้ าง EER model
ตามหลักการ generalization
พนักงำนที่ได้รับ เงินเดือน
พนักงำนที่ได้รับค่ำตอบแทนเป็ น
ชัว่ โมง
เงินเดือน
รำยชัว่ โมง
O
ชนิดค่ำตอบแทน
พนักงำน
Database Management System
Constraint สาหรับ Specialization และ
Generalization
4.86
1.Condition เงื่อนไขในกำรจำแนกข้อมูล
 2.Disjoint/Overlap Constraint
– d ข้อมูลระดับ superclass สำมำรถสัมพันธ์กบั subclass
ได้เพียงหนึ่งตัวเท่ำนั้น
– เช่น พนักงำนทุกคนสำมำรถรับ เงินเดือนหรื อค่ำตอบแทนเป็ นชม. เพียง
อย่ำงใดอย่ำงหนึ่ งเท่ำนั้น
– o ข้อมูลระดับ superclass สำมำรถสัมพันธ์กบั subclass
ได้มำกกว่ำหนึ่ งตัว
– พนักงำนทุกคนสำมำรถรับเงินเดือนหรื อค่ำตอบแทนเป็ นชม. อย่ำงใด
อย่ำงหนึ่งหรื อได้รับทั้งสองอย่ำงก็ได้

Database Management System
Constraint สาหรับ Specialization และ
Generalization(ต่ อ)
4.87
 3.Completeness/Incompleteness
– หำกระบุ subclass ทั้งหมดได้อย่ำงครบถ้วน เรี ยกว่ำ
Completeness
Database Management System
ข้ อมูลพนักงาน แบ่ งประเภทของงานทีร่ ั บผิดชอบ
เป็ น 3 กล่ มุ เท่ านั้น Completeness
รหัสพนักงำน
พนักงำน
ประเภทงำน
ชื่อพนักงำน
ผูจ้ ดั กำร
ผูจ้ ดั กำร
4.88
d
วิศวกร
วิศวกร
เลขำนุกำร
เลขำนุกำร
Database Management System
ข้ อมูลยานพาหนะ แบ่ งซับคลาสได้ 2 กล่ มุ
ครอบคลุมรถยนต์ ประเภทอื่นๆ
ไม่
4.89
Incompleteness
รถ
ประเภทงำน
รถยนต์
รถยนต์
d
รถบรรทุก
รถบรรทุก
Database Management System
4.90
ลักษณะของการจับค่ ขู ้ อมูล(Participation)
Disjoint
and Total Participation
– พนักงำนทุกคนสำมำรถรับ เงินเดือนหรื อค่ำตอบแทน
เป็ นชม. เพียงอย่ำงใดอย่ำงหนึ่งเท่ำนั้น
Disjoint
and Partial Participation
– พนักงำนที่ได้รับเงิน ต้องได้รับเงินเดือนหรื อ
ค่ำตอบแทนเป็ นชม. เพียงอย่ำงใดอย่ำงหนึ่งเท่ำนั้น แต่
อำจมีพนักงำนบำงคนที่ไม่ได้รับเงินแบบใดๆเลย
Database Management System
4.91
ลักษณะของการจับค่ ขู ้ อมูล(Participation)
 Overlap
and Total Participation
– พนักงำนทุกคนสำมำรถรับเงินเดือนหรื อค่ำตอบแทนเป็ นชม.
อย่ำงใดอย่ำงหนึ่งหรื อได้รับทั้งสองอย่ำงก็ได้
 Overlap
and Partial Participation
– พนักงำนที่ได้รับเงิน ต้องได้รับเงินเดือนหรื อ
ค่ำตอบแทนเป็ นชม. อย่ำงใดอย่ำงหนึ่งหรื อได้รับทั้งสอง
อย่ำงก็ได้ แต่อำจมีพนักงำนบำงคนไม่ได้รับค่ำเงินแบบใดๆ
Database Management System
4.92
ปัญหาในการเขียน ER-Diagram
Fan
Trap
– เป็ นปั ญหำที่เกิดจำกลักษณะกำรจัดควำมสัมพันธ์ระหว่ำง
Entity
Chasm
Trap
– เป็ นปั ญหำที่เกิดจำกกำรเชื่อมโยงควำมสัมพันธ์ระหว่ำงข้อมูล
ไม่ได้
Database Management System
4.93
Fan Trap แบบ 1
ั เอนติต้ ีอื่นมำกกว่ำ 1
เกิดจำกเอนติต้ ีที่มีควำมสัมพันธ์กบ
ตัวและมีชนิดควำมสัมพันธ์ออกจำกตัวเองเป็ น 1 ส่ วนอีก
ข้ำงหนึ่งเป็ น M
นักศึกษำ
M
สังกัด
1
คณะ
1
มี
M
หลักสู ตร
Database Management System
4.94
Fan Trap(ต่ อ)
สมคิดและจริยำ เรียนคณะบัญชี แต่ ไม่ สำมำรถบอกได้ ว่ำใครเรียนหลักสู ตรบัญชีหรื อบริหำร
สมคิด
r1
จริ ยำ
r2
บัญชี
r4
บริ หำร
r5
บัญชี
มนุษย์
สำยใจ
r3
r6
ภำษำอังกฤษ
Database Management System
4.95
ทางแก้ Fan Trap แบบ 1
เปลี่ยนแปลงตำแหน่งของเอนติต้ ี
คณะ
1
มี
M
หลักสู ตร
1
สังกัด
M
นักศึกษำ
Database Management System
4.96
Fan Trap แบบ 2
เกิดจำกกำรที่เอนติต้ ีมีควำมสัมพันธ์แบบเชื่อมต่อเนื่ องกัน
เป็ นวงกลม
M
ผูข้ ำย
M
ขำย
สิ นค้ำ
M
M
ซื้อ
ใช้
M
โครงกำร
•ผูข้ ำยขำยสิ นค้ำอะไร
•โครงกำรติดต่อซื้อจำกผูข้ ำยรำยใด
•โครงกำรต้องกำรใช้สินค้ำใดบ้ำง
M
เมื่อโครงกำรติดต่อซื้อขำยจำก
ผูข้ ำยแต่ละรำยแล้ว จะซื้อสิ นค้ำ
อะไรจำกผูข้ ำยรำยนั้นๆ
?
Database Management System
4.97
ทางแก้ Fan Trap แบบ 2
โดยเพิ่มเอนติต้ ีตวั กลำง
ผูข้ ำย
1
ขำย
M
ทะเบียนกำรซื้ อ-ใช้
สิ นค้ำ
M
ซื้ อ
M
ใช้
1
สิ นค้ำ
1
โครงกำร
Database Management System
4.98
Chasm Trap
ั เอน
 เป็ นปั ญหำที่เกิดจำกกำรเขียนเอนติต้ ีที่มีควำมสัมพันธ์กบ
ติต้ ีอื่นๆมำกกว่ำ 1 ตัวและควำมสัมพันธ์บำงส่ วนเป็ น
partial participation ทำให้กำรจับคู่ขอ้ มูล
ระหว่ำงเอนติต้ ีไม่ได้ครบถ้วน
หลักสู ตร
1
สังกัด
M
นักศึกษำ
M
ช่วยงำน
1
โครงงำน
Database Management System
4.99
Chasm Trap (ต่ อ)
โครงงำนชื่ อ งำน1 ไม่ มนี ักศึกษำช่ วยงำน ทำให้ ไม่ ทรำบว่ ำโครงงำนนีเ้ ป็ นของหลักสู ตรใด
บัญชี
r1
สมคิด
บริ หำร
r2
จริ ยำ
มนุษย์
r3
สำยใจ
r4
งำน1
งำน2
r5
งำน3
Database Management System
4.100
ทางแก้ Chasm Trap
 เพิ่มควำมสัมพันธ์ที่เชื่อมเอนติต้ ีหลักสู ตรกับโครงงำน
หลักสู ตร
1
สังกัด
M
1
นักศึกษำ
เจ้ำของ
M
ช่วยงำน
1
โครงงำน
M
Database Management System
4.101
แบบฝึ กหัดท้ ายบทที่ 4
ยกตัวอย่ำงควำมสัมพันธ์แบบ 1-1, 1 to M, M to M
มำแบบละ 2 ตัวอย่ำง
 2. เขียน ER-Diagram จำกควำมต้องกำรของระบบยืม-คืน
หนังสื อในห้องสมุด ดังต่อไปนี้
 1.
– หนังสื ออำจมีเหมือนกันหลำยเล่ม บรรณำรักษ์จึงไม่สำมำรถใช้ ISBN
เพื่อแยกระหว่ำงเล่มที่เหมือนกันได้ ต้องสร้ำงรหัสของหนังสื อแต่ละเล่ม
ขึ้นมำใหม่
– หนังสื อแต่ละเล่มมีผแู ้ ต่งเพียงหนึ่ งคน
– กำรยืมหนังสื อในห้องสมุดแห่ งนี้ เปิ ดให้บริ กำรเฉพำะสมำชิกเท่ำนั้น ซึ่ ง
กำรเป็ นสมำชิกนั้น มีวนั หมดอำยุ และข้อมูลส่ วนตัวคือ ชื่อ ที่อยูแ่ ละ
Database Management System
เบอร์โทร
4.102
แบบฝึ กหัดท้ ายบทที่ 4(ต่ อ)
– สมำชิกแต่ละคนยืมหนังสื อได้ครั้งละไม่เกิน 5 เล่ม
– กำรยืม-คืนแต่ละครั้งจะต้องบันทึกด้วยว่ำยืมวันใด จะต้องส่ งหนังสื อคืน
เมื่อไร วันที่คืนหนังสื อ และถ้ำส่ งช้ำกว่ำกำหนดต้องเสี ยค่ำปรับ
 บรรณำรักษ์
ต้องจัดทำรำยงำนเพื่อสรุ ปในแต่ละเดือนและสมำชิกก็
ต้องกำรบริ กำรดังนี้
– รำยได้จำกค่ำปรับในแต่ละเดือน
– แต่ละเดือนมีผมู ้ ำใช้บริ กำรห้องสมุดจำนวนเท่ำไร และยืมหนังสื อเป็ น
จำนวนกี่เล่ม
– หนังสื อในหมวดใดที่มีสมำชิกยืมมำกสุ ด
– สมำชิกมักจะค้นหำหนังสื อที่ตอ้ งกำรด้วยชื่อหนังสื อ ชื่อผูแ้ ต่งและ
ISBN
Database Management System
4.103
แบบฝึ กหัดท้ ายบทที่ 4(ต่ อ)
จงแปลง ER diagram จำกข้อ 2 ให้เป็ นตำรำง
 4. จงแปลง ER เป็ น Relation
 3.
หน่วยกิต
ชื่อวิชำ
1
เปิ ดสอน
M
วิชำที่เปิ ดสอน
สถำนที่เรี ยน
รหัสวิชำ
ชื่อวิชำ
รหัสกำรเปิ ดสอน
ปี -ภำค
เวลำเรี ยน
กลุ่ม
Database Management System
4.104
5. จงแปลง
ER เป็ น Relation
Product Code
Product Desc
.
be a component of
Product
m
m
Uses
be an assembly of
Quantity
Used
Bills of Material
Database Management System