Transcript PowerPoint Template

LOGO
Chapter 3
DBMS : E-R Diagram
Thinaphan Nithiyuwith
Dept. of Computer Science & Information Technology
http://computer.pcru.ac.th/suchada/
1
ขั้นตอนในการออกแบบฐานข้ อมูล
1. Requirement Analysis
Database Designer
(ER-Diagram)
2. Conceptual Design
3. Logical Design
(Normalization)
4. Schema Refinement
5. Physical Design
6. Security Design
DBA
7. Maintenance
2
Entity Relationship Data Model
 โดย ดร.ปี เตอร์ เชนน์ ราวปี ค.ศ. 1976
 ER data model จัดเป็ น conceptual data model ที่ใช้ออกแบบ
ฐานข้อมูลได้อย่างอิสระ ไม่ตอ้ งคานึงถึงว่าจะใช้ DBMS ชนิด
ไหน ยีห่ อ้ อะไร ด้วยคุณสมบัติเด่นนี้ทาให้ ER-model เป็ นที่
นิยมใข้งานกันมากในการวิเคราะห์และออกแบบฐานข้อมูล
 ผลการออกแบบด้วย ER-model สามารถแสดงด้วยรู ปภาพ หรื อ
ER-Diagram
 นักวิเคราะห์และออกแบบสามารถใช้ ER-Diagram เสมือนเป็ น
เครื่ องมือในการอธิบายองค์ประกอบ(Basic Structure) และ
ข้อกาหนดเงื่อนไข(Integrity constraint) ของฐานข้อมูล
3
Entity Relationship Data Model(ต่อ)
 นา ER-Diagram ไปใช้ทบทวนยืนยันความเข้าใจที่
ถูกต้องกับ user ของระบบงานได้ เพราะ ER-Diagram
ประกอบด้วยสัญลักษณ์ที่สื่อความหมายเข้าใจได้ง่าย
 เมื่อได้ ER-Diagram ที่ถูกต้องเหมาะสมกับระบบงานแล้ว
และทราบแล้วว่าจะใช้ DBMS ชนิดใด จึงจะทาการแปลง
(Mapping) ให้ได้เป็ น Logical schema ที่ตรงกับ DBMS
4
เทคนิคการสร้ างแผนภาพความสัมพันธ์ ระหว่างข้ อมูล
Entity Relationship Model
 กาหนด Entity
 Strong Entity
 Weak Entity
 กาหนด Attribute
 Composite attribute
 Simple attribute
 Single-value attribute
 Multivalued attributes
 กาหนด Primary Key
 กาหนด Relationship
 1:1
 1:M
 M:N
 ชนิดความสัมพันธ์
 Unary/Recursive
 Binary
 Ternary
 EER
 Derived attributes
5
Symbol (Chen)
Entity
Weak Entity
Relationship
Owner Relationship
6
Symbol (Chen)
Attribute
Multivalue Attribute
Primary Key
Composite Attribute
Derived Attribute
7
A Generalization Hierarchy
with Overlapping Subtypes
8
Symbol ชนิดของความสั มพันธ์
9
Basic Structure
องค์ประกอบของโครงสร้างข้อมูล โดย ERmodel ประกอบด้วยโครงสร้างดังนี้
Entity
Relationship
Attribute
Primary Key
10
Entity
 เอนติต้ ี(Entity)
 สิ่ งที่มีอยูใ่ นขอบเขตของระบบที่เราสนใจ อาจเป็ น สิ่ งของ
คน สถานที การกระทา เหตุการณ์ โดยแต่ละเอนติต้ ีจะเก็บ
เรื่ องเดียวกัน
 เช่น นักศึกษา , รถยนต์, หนังสือ, การทาผิด,
เพลง, การเช่า ,ประวัตก
ิ ารทางาน, การประมูล,
การสัมมนา, น้าตก , บ้านเช่า เป็ นต้น
11
Attribute
 ลักษณะหรื อคุณสมบัติที่นามาใช้อธิบายสิ่ งต่างๆ(Entity) และความสัมพันธ์
ต่างๆ(Relationship) ในระบบงาน
 เช่น attribute ที่นามาอธิบาย Entity ของ ลูกค้า ในระบบงานขายสิ นค้า
 ชื่อ สกุล ที่อยู่ รายได้ สถานภาพ อาชีพ
 เช่น attribute ที่นามาอธิบาย Entity ของ การลดราคา ในระบบงานแสดงสิ นค้า
 ครั้งที่ วันที่เริ่ มต้น วันสุ ดท้าย ชื่อสถานที่จดั งาน
 เช่น attribute ที่นามาอธิบาย Relationship ของซื้อสิ นค้า ในระบบงานขาย
สิ นค้า
 วันที่ซ้ื อ วันที่ตอ้ งการส่ งสิ นค้า จานวนที่ซ้ื อสิ นค้า
12
Relationship
 ความสัมพันธ์ระหว่าง entity ต่างๆ ซึ่งเปรี ยบเทียบ
ได้กบั กริ ยาโครงสร้างของ 1 ประโยค โดยทัว่ ไป
ประกอบด้วย ประธาน กริ ยา กรรม
 ประธาน และ กรรม เป็ นคานาม เปรี ยบเป็ น Entity
 กริ ยาแสดงความสัมพันธ์ระหว่างประธานกับกรรม
เปรี ยบเป็ น Relationship
 เช่น นักศึกษา 1 คน เรี ยนได้หลายๆวิชาใน 1เทอม
13
Degree of Relationship
 Degree ของชนิดความสัมพันธ์ คือ จานวนของ
ชนิดของ entity ทีม
่ ส
ี ว่ นร่วมในความสัมพันธ์นน
้ั
 Unary (Recursive) Relationship
• ความสัมพันธ์ภายใน entity เดียวกัน
 Binary Relationship
• ความสัมพันธ์ระหว่าง 2 entities
 Ternary Relationship
• ความสัมพันธ์ระหว่าง 3 entities
14
ตัวอย่าง ของ Degree of Relationship
Unary
นักศึกษา
m
พนักงาน
หัวหน้างาน
M
ลงทะเบียน
1
M
วิชาเรี ยน
อาจารย์
Ternary
M
วิชาเรียน
M
สอน
M
หนังสื อ
Binary
15
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)
16
Mapping Cardinalities
One to one
One to many
17
Mapping Cardinalities
Many to one
Many to many
18
One to One Relationship
 ความสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติต้ ีแรก สามารถจับคู่กบั
ข้อมูลในเอนติต้ ีที่สองได้เพียงแถวเดียวเท่านั้น
 เช่น ระบบข้อมูลมหาวิทยาลัย
อาจารย์
1
เป็ นคณบดี
1
คณะ
 อาจารย์ 1 คน เป็ นคณบดีได้เพียง 1 คณะ และ
 แต่ละคณะ มีอาจารย์ที่เป็ นคณบดีได้คนเดียวเท่านั้น
19
One to Many
 ความสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติต้ ีแรก สามารถจับคู่กบั
ข้อมูลในเอนติต้ ีที่สองได้มากกว่าหนึ่งแถว
 เช่น ระบบสัง่ ซื้อสิ นค้าของลูกค้า
ลูกค้า
1
สัง่ ซื้อ
M
ใบสัง่ ซื่อ
 ลูกค้า 1 คนสัง่ ซื้อใบสัง่ ซื้อได้หลายใบ และ
 ใบสัง่ ซื้อแต่ละใบ ถูกสัง่ ซื้ อจากลูกค้าเพียงคนเดียว
20
Many to Many
 ความสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติต้ ีแรก สามารถจับคู่กบั ข้อมูลในเอน
ติต้ ีที่สองได้มากกว่าหนึ่ งแถว
และในทางกลับกันข้อมูลแต่ละแถวของฝั่งเอนติต้ ีที่สองก็สามารถจับคู่กบั ข้อมูลใน
เอนติต้ ีแรกได้มากกว่าหนึ่ งแถว
 เช่น ระบบสั่งซื้อสิ นค้าของลูกค้า
สิ นค้ า
M
ถูกสัง่ ซื้อ
M
ใบสั่ งซื้อ
 สิ นค้า 1 อย่าง ถูกสัง่ ซื้ อตามใบสัง่ ซื้อได้หลายใบ และ
 ใบสัง่ ซื้อ 1 ใบสัง่ ซื้อสิ นค้าได้หลายอย่าง
21
Primary Key
 Attribute หรือ กลุม่ ของ attribute ทีแ่ สดง
เอกลักษณ์ ของสิง่ ใดสิง่ หนึ่งได้ ดังนัน
้ สิง่ ต่างๆ
จะมีคา่ primary key ไม่ซา้ กันเสมอ
22
Symbol (Chen)
partial
E1
E1
Total
R
1
R
E2
N
E2
Cardinality Ratio
23
Participation Constraint
 เงือ่ นไขการมีสว่ นร่วม คือ จานวนตา่ สุดของ
entity ทีอ
่ ก
ี entityหนึ่งมีความสัมพันธ์ดว้ ย มี 2
แบบคือ
 Total Participation
• การที่ entity หนึ่งentity จะต้องมีความสัมพันธ์กบั entity
อืน
่ อย่างน้อยหนี่ง entity เช่น อาจารย์ทก
ุ คนต้องสังกัด
อย่างน้อยใน หนี่งคณะ เป็ นต้น การมีสว่ นร่วมทัง้ หมดจะ
แสดงด้วยเส้นคูท
่ างด้านชนิดของentityทีท
่ ก
ุ entity ใน
ชนิดนัน
้ ต้องเข้าร่วมในความสัมพันธ์
อาจารย์
M
สังกัด
1
คณะ
24
Participation Constraint(ต่อ)
 Partial Participation
• การทีe
่ ntity หนึ่งentity มีความสัมพันธ์กบั entity อืน
่
อย่างน้อยศูนย์entity คือในชนิดของentity เดียวกันอาจมี
บางentity ทีม
่ ีสว่ นร่วมในความสัมพันธ์นน
้ ั ในขณะทีบ
่ าง
entity ทีไ่ ม่มีสว่ นร่วมในความสัมพันธ์นน
้ ั เลย เช่น แผนก
บางแผนกไม่มีพนักงานสังกัดเลย และบางแผนกอาจมี
พนักงานสังกัดหลายคน
• การมีสว่ นร่วมบางส่วนจะแสดงโดยใช้เส้นเดียวด้านชนิด
ของentity ทีบ
่ างentityในชนิดนัน
้ มีสว่ นร่วมใน
ความสัมพันธ์ เช่น เส้นเดียวจากentity แผนก
อาจารย์
M
สังกัด
1
แผนก
25
Connectivity and Cardinality in an
ERD
The “Inside” symbols indicate a
minimum
minimum
The “Outside” symbols indicate a
maximum
maximum
26
An Optional CLASS Entity in the Relationship
27
Mandatory Relationship
M
CLASS
28
Exercise Mandatory and Optional
Comment :
29
Exercise Mandatory and Optional
Comment :
30
Exercise Mandatory and Optional
Comment :
31
Summary of cardinality constraints
© Pearson Education Limited 1995, 2005
32
The M:N Relationship
33
A Composite Entity in an ERD
34
ประเภทของ attribute
 Simple Attribute คือ แอตทริ บิวที่เก็บค่าได้เพียงค่าเดียว
เท่านั้น เช่น รหัสลูกค้า ลูกค้า 1 คนมีรหัสลูกค้าได้หมายเลขเดียว
 Multi-valued attribute คือ แอตทริ บิวต์ที่เก็บค่าได้ต้ งั แต่
1 ค่าขึ้นไป เช่น เบอร์โทรศัพท์ ของลูกค้า มีทง้ ั เบอร์
บ้าน เบอร์มอ
ื ถือ เป็ นต้น
ลูกค้า
เบอร์โทรศัพท์
35
ประเภทของแอตทริบิวต์ (ต่ อ)
 Composite attribute คือแอตทริ บิวต์ที่ประกอบด้วยแอ
ตทริ บิวต์หลายตัวมารวมกันจึงให้ความหมายที่ชดั เจน
จังหวัด
ชื่อ
ถนน
สกุล
อาเภอ
ชื่อ-สกุล
ที่อยู่
ลูกค้า
36
ประเภทของแอตทริบิวต์ (ต่ อ)
 Derived attribute คือ แอตทริ บิวต์ที่เก็บผลการคานวณหรื อ
แปลงค่ามาจากแอตทริ บิวต์อื่นๆ เช่น จานวนเงิน(ราคา*จานวน)
จานวนพนักงาน
แผนก
รหัสแผนก
37
Weak Entity
 Weak entity ต้องมีคณ
ุ สมบัติ 2 ข้อ คือ
1. ไม่มี Primary Key มีเพียง partial key (ซึง่ เป็ นค่าที่
ซา้ กันได้) ดังนัน
้ นาเอา partial key ไปรวมกับ
Primary key ของ Strong Entity ก็จะเป็ นค่าทีไ่ ม่ซา้
ได้
2. Weak entity ต้องมีความสัมพันธ์กบั Strong Entity
อย่างน้อย 1 entity คือ ลักษณะของการขึ้นต่อกัน คือ การที่เอนติต้ ี
หนึ่งจะเกิดขึ้นได้น้ นั ขึ้นกับอีกเอนติต้ ีหนึ่งว่าปรากฏอยูห่ รื อไม่
38
Weak Entity (ต่อ)
 ตัวอย่าง เอนติต้ ีพนักงานและเอนติต้ ีญาติ ถ้าไม่มีเอนติต้ ีพนักงาน
เอนติต้ ีญาติกจ็ ะไม่เกิดขึ้น
รหัสพนักงาน
 เอนติต้ ีญาติ เป็ น Weak Entity
 เอนติต้ ีพนักงาน เป็ น Entity
พนักงาน
1
มี
ลาดับที่
M
ญาติ
-ญาติ เป็ น weak entity ที่ไม่มี primary key โดยคุณสมบัติ ลาดับที่ มีคา่ ซ้ ากันใน
รี เลชัน่ ญาติ เพราะคุณสมบัติ ลาดับที่ มีค่าซ้ าๆ กันได้ในหลายญาติ เช่น ลาดับที่ 1 เป็ นญาติ นาย
ขาว และลาดับที่ 1 เป็ นญาติ นายแดง
-ฝั่งชนิดของentity ญาติ เป็ นแบบ Total Participation
39
Weak Entities(ต่ อ)
วิชา
1
เปิ ดสอน
M
วิชาที่เปิ ดสอน
รหัสวิชา
ชื่อวิชา
ปี -ภาค
รหัสการเปิ ดสอน
กลุ่ม
เวลาเรี ยน
ชื่อวิชา(รหัสวิชา, ชื่อวิชา)
วิชาที่เปิ ดสอน(รหัสวิชา*, ปี -ภาค, กลุ่ม, เวลาเรี ยน)
40
ตัวอย่าง Recursive Relationships
 ตัวอย่าง การลงทะเบียนบางวิชา จะต้องเรี ยนวิชาอื่นมา 1 วิชา
(one to one)
1
วิชาที่ลงทะเบียน
Precond.
Course
1
วิชาที่ตอ้ งผ่านก่อน
Course(CourseID, CourseName, Unit, PrecondCourseID*)
41
Recursive Relationships(ต่ อ)
CourseID
CourseName
Unit
PrecondCourseID*
Database Management
System
3
4122202
4122202
4123601
Introduction to Database
3
4121202
Programming and
algorithm
3
4122101
Programing Language 1
3
4121202
42
ตัวอย่าง Recursive Relationships
 ตัวอย่าง การลงทะเบียนบางวิชา จะต้องเรี ยนวิชาอื่นมา 1 วิชาหรื อหลายๆ
วิชา (many to many)
วิชาที่ลงทะเบียน
m
Precond.
Course
m
วิชาที่ตอ้ งผ่านก่อน
Precondition(CourseID, PrecondCourseID)
Course(CourseID , CourseName, Unit)
43
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
44
ตัวอย่าง Recursive Relationships
 ตัวอย่าง พนักงานที่เป็ นหัวหน้า 1 คน มีลูกน้องได้หลายคน ทั้ง
หัวหน้าและลูกน้องก็เป็ นพนักงานทั้งคู่ (one to many)
1
หัวหน้า
Manage
Employees
m
ลูกน้อง
Employees( EmpID, EmpName, BirthDate, MangerID*)
45
ตัวอย่าง Ternary Relationships
 เป็ นความสัมพันธ์ที่มีเอนติต้ ีที่เกี่ยวข้อง 3 เอนติต้ ี
 เช่นความสัมพันธ์ดีกรี 3 ของความสัมพันธ์ระหว่าง ผูข้ าย โครงการ
สิ นค้า
 เนื่องจากผูข้ ายสามารถขายสิ นค้าให้กบั โครงการใดก็ได้
46
ตัวอย่าง Ternary Relationships
รหัสโครงการ
โครงการ
รหัสผูข้ าย
รหัสสิ นค้า
M
ผูข้ าย
M
สาหรับ
M
สิ นค้า
จานวน
ผูข้ าย-โครงการ-สิ นค้า(รหัสผูข้ าย, รหัสโครงการ, รหัสสิ นค้า, จานวน)
47
ตัวอย่าง 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)
48
Aggregation
 Treat aggregation as any other entity type
Physician
Treatment
M
Treat
M
Patient
M
Us
e
M
Drug
Physician(…), Patient(…), Drug(…)
Treat (PhysicianID, PatientID)
Use(PhysicianID, PatientID, DrugID)
49
หลักการแปลง ER เป็ นรีเลชั่น
1. ให้แปลงเอนติติ้ทุกตัวเป็ นรี เลชัน่ และแปลงแอตทริ บิวต์
ทุกตัวของเอนติต้ ีให้เป็ นแอตทริ บิวต์ของรี เลชัน่
Customer
CusID
CusName
CusAdd
CusSurName
Customer(CusID, CusName, CusSurName, CusAdd)
50
หลักการแปลง ER เป็ นรีเลชั่น(ต่ อ)
2. เพิ่มแอตทริ บิวต์ให้กบั รี เลชัน่
2.1 ถ้าความสัมพันธ์เป็ นแบบ 1 to 1 ให้นา pk ของรี เลชัน่ ฝั่งใดฝั่ง
หนึ่งไปอยูใ่ นรี เลชัน่ ของอีกฝั่งหนึ่ ง
**ต้องให้ค่าในแอตทริ บิวใหม่เป็ น Null น้อยสุ ดหรื อไม่มี
Teacher
ThID
1
เป็ นคณบดี
ThName
ThSurName
1
Faculty
FacID
FacName
Teacher(ThID, ThName, ThSurName)
Faculty(FacID,FacName,ThID*)
51
Teacher(ThID, ThName, ThSurName)
Faculty(FacID,FacName,ThID*)
Teacher(ThID, ThName, ThSurName,FacID*)
Faculty(FacID,FacName)
52
ThID
001
ThName
ผศ.วาสนา
ThSurName
ใจดี
034
253
333
อ.สมคิด
รศ.ฉลาด
ผศ.สมาธิ
ใจดี
ใจดี
ใจดี
111
002
อ. ดุษฎี
อ. ประสงค์
ใจดี
ใจดี
003
อ. ปรานี
ใจดี
FacID
FacName
ThID*
1
วิทยาศาสตร์
001
2
มนุษย์
034
3
วิทยาการจัดการ
253
4
ครุ ศาสตร์
333
5
เทคโนโลยีอุตฯ
111
53
ThID
001
034
253
333
111
002
003
ThName
ผศ.วาสนา
อ.สมคิด
รศ.ฉลาด
ผศ.สมาธิ
อ. ดุษฎี
อ. ประสงค์
อ. ปรานี
FacID
ThSurName
ใจดี
ใจดี
ใจดี
ใจดี
ใจดี
ใจดี
ใจดี
FacID
1
2
3
4
5
FacName
1
วิทยาศาสตร์
2
มนุษย์
3
วิทยาการจัดการ
4
ครุ ศาสตร์
5
เทคโนโลยีอุตฯ
54
หมายเหตุ
กรณี ที่เป็ น Total Partial Relationship
นา PK ของด้านที่เป็ น Partial Relationship
ไปเป็ น FK ของด้านที่เป็ น Total Relationship
55
หลักการแปลง ER เป็ นรีเลชั่น(ต่ อ)
2. เพิ่มแอตทริ บิวต์ให้กบั รี เลชัน่
2.2 ถ้าความสัมพันธ์เป็ นแบบ 1 to Mให้นา pk ของรี เลชัน่ ฝั่งที่เป็ น
1ไปอยูใ่ นรี เลชัน่ ของฝั่งที่เป็ น M
CusName
Customer
1
ReqDate
CusID
M
สัง่ ซื้ อ
Orders
OrderDate
CusSurName
OID
Customer(CusID, CusName, CusSurName)
Orders(OID,OrderDate, ReqDate ,CusID*)
56
หลักการแปลง ER เป็ นรีเลชั่น(ต่ อ)
2. เพิ่มแอตทริ บิวต์ให้กบั รี เลชัน่
2.3 แอตทริ บิวต์ที่อยูบ่ นความสัมพันธ์ จะนาไปใส่ ในรี เลชัน่ ใด ก็ข้ ึนอยู่
กับว่าเมื่อใส่ ลงในรี เลชัน่ นั้นแล้ว จะมีบางแถวหรื อไม่มีแถวข้อมูลใดเลยที่มี
ค่าในแอตทริ บิวต์เป็ น Null
CusName
Customer
1
ReqDate
CusID
M
สัง่ ซื้ อ
Orders
OrderDate
CusSurName
OID
Customer(CusID, CusName, CusSurName)
Orders(OID,OrderDate, ReqDate ,CusID*)
57
หลักการแปลง ER เป็ นรีเลชั่น(ต่ อ)
3. สร้างรี เลชัน่ ใหม่สาหรับความสัมพันธ์แบบ M to M
โดยสร้าง PK ได้จาก การนาเอา PK ของแต่ละรี เลชัน่
มาประกอบกัน หรือ สร้างแอตทริบวิ ส์ขน
ึ้ มาใหม่
Discount
PName
Products
M
รายการสัง่ ซื่อ
Amount
PID
M
Orders
UnitPrice
Price
OID
Product(PID, PName, Price)
Orders(OID,OrderDate, ReqDate ,CusID*)
OrderDetail(OID*, PID*, Discount, Amount, UnitPrice)
58
ตัวอย่าง สร้าง primary key ใหม่
รหัสนักศึกษา ชื่อ-นามสกุล
นักศึกษา
M
เกรด
ลงทะเบียน
กลุ่ม
รหัสวิชา
M
วิชา
นักศึกษา (รหัสนักศึกษา,ชื่อ-นามสกุล)
ชื่อวิชา
วิชา (รหัสวิชา,กลุ่ม,ชื่อวิชา)
ลงทะเบียน (รหัสการลงทะเบียน,รหั สนักศึกษา*,รหั สวิชา*,กลุ่ม*,เกรด)
59
หลักการแปลง ER เป็ นรีเลชั่น(ต่ อ)
4. สาหรับเอนติติ้ที่มีแอตทริ บิวต์แบบหลายค่า
 ให้สร้างรี เลชัน่ เพิม่ ที่มีแอตทริ บิวต์แบบหลายค่านั้น
 PK ของรี เลชัน่ ใหม่เกิดจาก PK ของรี เลชัน่ เดิมประกอบกับ แอตทริ บิวต์ที่
เกิดจากแอตทริ บิวแบบหลายค่า
CusName
Customer
CreditNum
CusID
CusSurName
Customer(CusID, CusName, CusSurName)
CusCredit(CusID*, CreditNum)
60
หากพบ multivalued attribute ควรแยก
ออกมาเป็ น composite attribute
ชื่อ
รหัส
นามสกุล
เบอร์โทรศัพท์
พนักงาน
พนักงาน(รหัส,ชื่อ,นามสกุล,เบอร์โทรศัพท์1,เบอร์โทรศัพท์2)
61
หลักการแปลง ER เป็ นรีเลชั่น(ต่ อ)
5. สาหรับเอนติต้ ีแบบอ่อน ให้สร้างเป็ นรี เลชัน่ และมี PK ที่มาจาก PK ของรี
เลชัน่ หนึ่งรวมกับ PK ของเอนติต้ ีแบบอ่อน
Invoice
Inv no
1
M
has
Date
Invoice
Detail
Line
Invoice(Inv no, Date)
InvoiceDetail( Inv no* ,Line)
62
Mulitvalued Attributes
และการแปลงเป็ นรีเลชั่น
Phone
Faculty Member
Degrees
Name
FACULTY_MEMBER (Name, Phone)
FACULTY_DEGREES (Name*, Degree)
Faculty Member
has
Degree
Degree
63
EER model
(Enhanced Entity Relationship Model)
 เป็ น Model ที่นาแนวคิดของ ER Model มาเพิ่มเติมในเรื่ อง
1. ความสัมพันธ์แบบ Superclass/Subclass
หรื อ
Supertype/Subtype
2. แนวคิดของ Generalization/Specialization ซึ่ งเป็ นแนวคิดที่
ใช้ในการสร้างความสัมพันธ์ของ Entity ที่เป็ น
Superclass/Subclass รวมทั้งการถ่ายทอดคุณสมบัติ (Attribute
Inheritance)
 เหมาะที่จะนามาใช้กบั ระบบงานทางธุรกิจที่มีความสลับซับซ้อน ซึ่ งจะช่วยลด
ความซับซ้อนของข้อมูล การเขียน Model ทาได้ง่าย
64
EER model
 Superclass คือ รู ปแบบของ Entity ที่เป็ นต้นแบบของ Entity อื่นๆ โดย
Superclass จะประกอบไปด้วย Subclass ต่างๆ
 Subclass คือ Entity ที่มีคุณสมบัติบางอย่างที่แตกต่างจากสมาชิกของSubclass
ด้วยกัน แต่จะมีคุณสมบัติพ้นื ฐานตาม Superclass
 ตัวอย่าง : Entity พนักงาน เป็ น Superclass ประกอบด้วยข้อมูล รหัสพนักงาน
,ชื่อ ,วันที่เริ่ มทางาน
Entity นี้ประกอบด้วย Subclass คือ
- ผูบ้ ริ หาร จะมีขอ้ มูลเฉพาะ คือ รถและเงินเดือนประจาตาแหน่ง - ผูเ้ ชี่ยวชาญ จะมี
ข้อมูลเฉพาะเกี่ยวกับความชานาญและค่าตอบแทน
- พนักงานแรงงาน จะมีขอ้ มูลเฉพาะ คืออัตราค่าจ้างรายวัน
ข้อมูลของ Entity ที่เป็ น Subclass จะต้องมีขอ้ มูลทั้งหมดจากSuperclass
65
Superclass/Subclass
รหัสพนักงาน
ชื่อพนักงาน
Manager
Employee
Specialist
-รถประจาตาแหน่ง
-ความชานาญ
-เงินเดือนประจาตาแหน่ง
- ค่าตอบแทนผูเ้ ชี่ยวชาญ
วันที่เริ่ มงาน
Labor
-ค่าจ้างรายวัน
66
การถ่ายทอดคุณสมบัติ
(Attribute Inheritance)
- Subclass จะรับถ่ายทอดคุณสมบัติทุกๆอย่างจาก
Superclass
- ทาให้ไม่ตอ้ งกาหนด Attribute ซ้ าซ้อนใน Subclass
- ตัวอย่าง : Subclass ผูบ้ ริ หาร,ผูเ้ ชี่ยวชาญและพนักงานแรงงาน จะ
ได้รับถ่ายทอดคุณสมบัติทุกๆอย่างจาก Superclass
Employee
67
Generalization
• เป็ นกระบวนการจัดการกับ Entity
ที่เป็ นแม่แบบ เพื่อใช้กาหนด
ลักษณะทีเ่ หมือนกันหรือร่ วมกัน วิธก
ี ารนี้เป็ นวิธแ
ี บบลางขึ
น
้
่
บน (Bottom-Up Approach) ด้ วยการมองหาสิ่ งที่เหมือนกันใน
Subclass เช่น การพิจารณา Entity ที่เป็ น Subclass คือ
ผูบ้ ริ หาร, ผูเ้ ชี่ยวชาญและพนักงานแรงงาน ว่ามีลกั ษณะอะไรที่เหมือนกัน เพื่อ
ออกแบบ Entity ที่เป็ น Superclass คือ Employee ซึ่ งมี
ข้อมูลร่ วมกัน คือ รหัสพนักงาน ชื่อและวันที่เริ่ มทางาน
• จะกาหนดซับคลาสก่อน แล้วค่อยหาว่าซับคลาสทั้งหมดนั้นมีแอตทริ บิวต์อะไร
ที่เหมือนกันบ้าง
68
Specialization
• เป็ นกระบวนการจัดการกับ Entity ทีม
่ ีความแตกต่างกันในกลุม
่ ของ
้ กับ Superclass วิธน
สมาชิกซึง่ ขึน
ี ี้เป็ นวิธแ
ี บบบนลงล่าง (TopDown Approach) ด้วยการมองจุดทีแ
่ ตกต่างกันระหว่าง
Subclass เช่น Superclass Employee ประกอบด้วยพนักงานที่
เป็ นผูบ
้ ริหาร ผูเ้ ชีย่ วชาญและพนักงานแรงงาน ซึง่ มีรายละเอียด
เฉพาะตามประเภทพนักงาน
• เครือ
่ งหมายทีใ่ ช้แสดงความสัมพันธ์ของ Superclass/Subclass
• เครือ
่ งหมาย U แสดงว่า Subclass เป็ น Subset ของ Superclass
• จุดเชือ
่ มต่อ คือ วงกลม
• เส้นทีล่ ากจาก Superclass มายัง Subclass คือ เส้นทีถ
่ า่ ยทอดคุณสมบัติ
69
Constraint สาหรับ Specialization และ
Generalization
 1.Condition เงื่อนไขในการจาแนกข้อมูล
 2.Disjoint/Overlap Constraint
 d ข้อมูลระดับ superclass สามารถสัมพันธ์กบั subclass
ได้เพียงหนึ่งตัวเท่านั้น
 เช่น พนักงานทุกคนสามารถรับ เงินเดือนหรื อค่าตอบแทนเป็ นชม. เพียง
อย่างใดอย่างหนึ่ งเท่านั้น
 o ข้อมูลระดับ superclass สามารถสัมพันธ์กบั subclass
ได้มากกว่าหนึ่ งตัว
 พนักงานทุกคนสามารถรับเงินเดือนหรื อค่าตอบแทนเป็ นชม. อย่างใด
อย่างหนึ่งหรื อได้รับทั้งสองอย่างก็ได้
70
ตัวอย่าง ธุรกิจมีการว่าจ้างพนักงาน
โดยมีพนักงานทีแ
่ ตกต่างกัน 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)
71
Emp_name
Emp_no
Address
Date_hired
Employee
d
U
U
Hourly
Employee
Salary
Employee
Hourly_rate
Annual_Salary
U
Consultant
Contact_no
Billing_Rate
72
สร้ าง EER model
ตามหลักการ specialization
ตาแหน่ง
รหัสพนักงาน
พนักงาน
ชนิดค่าตอบแทน
ชื่อพนักงาน
เงินเดือน
เงินเดือน
พนักงานที่ได้รับ เงินเดือน
d
รายชัว่ โมง
อัตราค่าแรงต่อชม.
พนักงานที่ได้รับค่าตอบแทนเป็ น
ชัว่ โมง
พนักงานได้รับค่าจ้างเป็ นแบบใดแบบหนึ่ง
73
สร้ าง EER model
ตามหลักการ specialization(ต่ อ)
ตาแหน่ง
รหัสพนักงาน
พนักงาน
ชนิดค่าตอบแทน
ชื่อพนักงาน
เงินเดือน
เงินเดือน
พนักงานที่ได้รับ เงินเดือน
O
รายชัว่ โมง
อัตราค่าแรงต่อชม.
พนักงานที่ได้รับค่าตอบแทนเป็ น
ชัว่ โมง
พนักงานแต่ละคนมีสิทธิ์ได้รับทั้งเงินเดือนและค่าตอบแทนเป็ นชัว่ โมงด้วย
74
สร้ าง EER model
ตามหลักการ generalization
พนักงานที่ได้รับ เงินเดือน
พนักงานที่ได้รับค่าตอบแทนเป็ น
ชัว่ โมง
เงินเดือน
รายชัว่ โมง
O
ชนิดค่าตอบแทน
พนักงาน
75
A Generalization Hierarchy :
Disjoint subtype
76
A Generalization Hierarchy :
Overlapping Subtypes
77
A Generalization Hierarchy
with Overlapping Subtypes and Disjoint Subtypes
78
ลักษณะของการจับคู่ข้อมูล
(Participation)
 Disjoint and Total Participation
 พนักงานทุกคนสามารถรับ เงินเดือนหรื อค่าตอบแทน
เป็ นชม. เพียงอย่างใดอย่างหนึ่งเท่านั้น
 Disjoint and Partial Participation
 พนักงานที่ได้รับเงิน ต้องได้รับเงินเดือนหรื อ
ค่าตอบแทนเป็ นชม. เพียงอย่างใดอย่างหนึ่งเท่านั้น แต่
อาจมีพนักงานบางคนที่ไม่ได้รับเงินแบบใดๆเลย
79
ลักษณะของการจับคู่ข้อมูล
(Participation)
 Overlap and Total Participation
 พนักงานทุกคนสามารถรับเงินเดือนหรื อค่าตอบแทนเป็ นชม.
อย่างใดอย่างหนึ่งหรื อได้รับทั้งสองอย่างก็ได้
 Overlap and Partial Participation
 พนักงานที่ได้รับเงิน ต้องได้รับเงินเดือนหรื อ
ค่าตอบแทนเป็ นชม. อย่างใดอย่างหนึ่งหรื อได้รับทั้งสอง
อย่างก็ได้ แต่อาจมีพนักงานบางคนไม่ได้รับค่าเงินแบบใดๆ
80
ปัญหาในการเขียน ER-Diagram
 Fan Trap
 เป็ นปัญหาที่เกิดจากลักษณะการจัดความสัมพันธ์ระหว่าง Entity
 Chasm Trap
 เป็ นปั ญหาที่เกิดจากการเชื่อมโยงความสัมพันธ์ระหว่างข้อมูลไม่ได้
81
Fan Trap แบบ 1
 เกิดจากเอนติต้ ีที่มีความสัมพันธ์กบั เอนติต้ ีอื่นมากกว่า 1
ตัวและมีชนิดความสัมพันธ์ออกจากตัวเองเป็ น 1 ส่ วนอีก
ข้างหนึ่งเป็ น M
นักศึกษา
M
สังกัด
1
คณะ
1
มี
M
หลักสูตร
82
Fan Trap(ต่ อ)
สมคิดและจริยา เรียนคณะบัญชี แต่ ไม่ สามารถบอกได้ ว่าใครเรียนหลักสู ตรบัญชีหรือบริหาร
สมคิด
r1
จริ ยา
r2
บัญชี
r4
บริ หาร
r5
บัญชี
มนุษย์
สายใจ
r3
r6
ภาษาอังกฤษ
83
ทางแก้ Fan Trap แบบ 1
 เปลี่ยนแปลงตาแหน่งของเอนติต้ ี
คณะ
1
มี
M
หลักสูตร
1
สังกัด
M
นักศึกษา
84
Fan Trap แบบ 2
 เกิดจากการที่เอนติต้ ีมีความสัมพันธ์แบบเชื่อมต่อเนื่องกันเป็ นวงกลม
M
ผูข้ าย
M
ขาย
สิ นค้า
M
M
ซื้อ
ใช้
M
โครงการ
•ผูข้ ายขายสิ นค้าอะไร
•โครงการติดต่อซื้อจากผูข้ ายรายใด
•โครงการต้องการใช้สินค้าใดบ้าง
M
เมื่อโครงการติดต่อซื้อขายจาก
ผูข้ ายแต่ละรายแล้ว จะซื้อสิ นค้า
อะไรจากผูข้ ายรายนั้นๆ
?
85
ทางแก้ Fan Trap แบบ 2
 โดยเพิ่มเอนติต้ ีตวั กลาง
ผูข้ าย
1
ขาย
M
ทะเบียนการซื้ อ-ใช้
สิ นค้า
M
ซื้ อ
M
ใช้
1
สิ นค้า
1
โครงการ
86
Chasm Trap
 เป็ นปัญหาที่เกิดจากการเขียนเอนติต้ ีที่มีความสัมพันธ์กบั เอนติต้ ี
อื่นๆมากกว่า 1 ตัวและความสัมพันธ์บางส่ วนเป็ น partial
participation ทาให้การจับคู่ขอ้ มูลระหว่างเอนติต้ ีไม่ได้
ครบถ้วน
หลักสูตร
1
สังกัด
M
นักศึกษา
M
ช่วยงาน
1
โครงงาน
87
Chasm Trap (ต่ อ)
โครงงานชื่อ งาน1 ไม่ มนี ักศึกษาช่ วยงาน ทาให้ ไม่ ทราบว่ าโครงงานนีเ้ ป็ นของหลักสู ตรใด
บัญชี
r1
สมคิด
บริ หาร
r2
จริ ยา
มนุษย์
r3
สายใจ
r4
งาน1
งาน2
r5
งาน3
88
ทางแก้ Chasm Trap
 เพิ่มความสัมพันธ์ที่เชื่อมเอนติต้ ีหลักสูตรกับโครงงาน
หลักสูตร
1
สังกัด
M
1
นักศึกษา
เจ้าของ
M
ช่วยงาน
1
โครงงาน
M
89
LOGO
การแปลงแผนภาพความสั มพันธ์ เป็ นรีเลชั่น
Translation of ER Model to Relational Model
90
Step 1 – Entities
 Steps in transforming entities
 Create one table for each entity
 The name of the table is the name of the entity
 The names of the columns are the names of
attributes of entity
 The primary key of the table is the primary key
of the entity
91
Transforming Entities:
Example
Students
S_ID
S_ID
Firstname
Lastname
BirthYear
Students
Firstname Lastname
BirthYear
92
Step 2: One-to-Many
Relationships
 Steps in transforming one-to-many
relationships
 Add the primary key of the one side as column
of the many side
 The column will be the foreign key referencing
the primary key of the referenced table
 Steps in transforming many-to-one
relationships are the same
93
Transforming one-to-many relationship
N
Student
S_ID
Firstname
1
Has_advisor
Lastname
BirthYear
Instructor
I_ID
Firstname
Lastname
Phone
Students
S_ID FirstName LastName
BirthYear
I_ID
Instructor
I_ID Firstname
Lastname
Phone
94
Step 3: Many-to-Many Relationships
 Steps in transforming many-to-many
relationships
 Many-to-many relationships become their own tables
 Primary keys of participating entities together form the
primary key of this table
 These columns are at the same time foreign keys
referring to the primary keys of the participating
entities
 Attributes of the relationship become attributes of this
table
95
Transforming many-to-many relationship
Student
S_ID
M
N
takes
Course
…
C_ID
…
Student_course
S_ID
C_ID
Student
S_ID
Course
….
C_ID
….
96
Transforming many-to-many relationship (2)
Student
S_ID
…
M
N
takes
Registration_date
Course
C_ID
…
Student_course
S_ID
C_ID
Registration_dat
e
97
Renaming of Attributes
 Columns of the same table must have different
names
 E.g. if ‘ID’ is the name of primary key attributes of two
tables, one must be renamed before it can be added
to another table
 Renaming can be done in both the original attribute
and the added attribute
 One renaming guideline is by adding entity
name with attribute, e.g. student_id,
instructor_id, etc.
 Or add relationship name with attribute, e.g.
advisor_id, manager_id, etc.
98
Renaming of Attributes (2)
 Example
Product
ID
N
1
Customer
Bought_by
…
ID
…
Attribute Rename
Product
ID
…
Customer_ID
Customer
Customer_ID
…
99
Step 4: One-to-One
Relationships
 Normally, the translation is the same for one-tomany relationships
 Add the primary key of one side as an attribute of the
other side
 Example:
Department
D_ID
…
1
1
Employee
managed_by
E_ID
…
100
Transforming One-to-One Relationship
Department
D_ID
1
1
managed_by
…
Department
D_ID
…
E_ID
Employee
E_ID
…
Employee
E_ID
…
101
Transforming One-to-One Relationship (2)
 For a better design, transforming one-toone relationship should be separated for 3
cases of one-to-one relationships:
E1
(0,1)
E1
(0,1)
E1
(1,1)
R
R
R
(1,1)
(0,1)
(1,1)
E2
E2
E2
102
Transforming One-to-One
Relationship: (0,1) and (1,1)
 It is better to add the primary key of the (0,1) side as an
attribute of the (1,1) side to avoid null values
 Example
(1,1)
Department
D_ID
(0,1)
managed_by
…
Department
D_ID
…
E_ID
Employee
E_ID
…
Employee
E_ID
…
103
Transforming One-to-One
Relationship: (0,1) and (0,1)
 Put the primary key of any of the two tables into the
other table (null values can’t be avoided)
Employee
E_ID
(0,1)
(0,1)
has
…
O_ID
…
…
Office
Employee
E_ID
Office
O_ID
O_ID
…
 Or transform the relationship into a table (avoid null)
104
Transforming One-to-One
Relationship: (0,1) and (0,1) (2)
(0,1)
Employee
E_ID
(0,1)
…
O_ID
…
…
Office
Employee
E_ID
Office
has
O_ID
…
Employee_Office
E_ID
O_ID
105
Transforming One-to-One
Relationship: (1,1) and (1,1)
 Merge the two tables into one table
 Choose primary key of one table to be the
primary key of this table
 Primary key of the other table becomes
alternate key of this table
106
Transforming One-to-One
Relationship: (1,1) and (1,1) (2)
(1,1)
Customer
C_ID
C_ID
(1,1)
CreditCard
has
Name
CNum
Name
Customer
CNum
CreditLimit
CreditLimit
107
Translation of Advanced ERConstructs
 Weak Entities
 Specialization
 Structured, Multivalued Attributes
108
Weak Entities
 Weak entity usually has many-to-one relationship (or
one-to-one) with the master entity
 However, transforming weak entities is simpler than transforming
normal many-to-one or one-to-one relationship
 Steps in transforming weak entities
 Create a table for a weak entity
 Inherits the primary key attributes of every master entity
• Together with the partial key of the weak entity, they form the
primary key of this table
 These attributes become foreign keys referencing the tables of
master entities
109
Transforming Weak Entities
Building
Building_name
(1,*)
Room
has
…
Room_number
…
Building
Building_name
…
Room
Building_name Room_number
…
110
Specialization
 There is no direct support for specialization in
Relational Model
 Supported in Object-oriented and Object-relational
models
 There are 3 possible methods of converting
specialization in ER Model to Relational Model
 Method 1: One table with a lot of null value
 Method 2: Different tables for subclasses
 Method 3: Splitting of attributes over tables
111
Example
ID
Employee
Name
Pilot
FlightHours
112
Transforming Specialization: Method 1
 One table with a lot of null value
 Add all attributes of superclass and subclass into one
table with additional attribute, e.g. Is_Pilot
Employee
ID
Name
Is_Pilot
FlightHours
• Example of DB State
Employee
ID
Name
Is_Pilot
FlightHours
1
2
3
J.K.
L.P.
F.G.
No
No
Yes
Null
Null
500
113
Transforming Specialization: Method 1 (2)
 Advantages of Method 1
 No join is needed (which will improve query
performance)
 The number of table is minimized (single
table)
 Most frequently used in practice
 Disadvantage
 Relationship of subclass can not be
represented easily, e.g. relationship between
‘pilot’ and ‘aircraft’ entity
114
Transforming Specialization: Method 2
 Different table for subclass
 One table for subclass with all attributes inherited
from superclass
 Store information of ‘normal employee’ separated
from ‘pilot’
Normal_Employee
ID
Name
Pilot
ID
Name
FlightHours
115
Transforming Specialization: Method 2 (2)
 Advantages of Method 2
 Method 2 requires UNION to get information
of every employee (which is fast)
 Efficient if information about ‘pilot’ table is
accessed often
 Disadvantage
 Can not represent relationship of superclass
easily
116
Transforming Specialization: Method 3
 Create one table for subclass with only
attribute that is primary key of superclass
and attributes that are specific to subclass
 ‘Join’ is needed to get all information about a pilot
ID
Employee
Name
Pilot
ID
FlightHours
117
Transforming Specialization: Method 3 (2)
 Advantages of Method 3
 Relationship of subclass can be represented
 Relationship of superclass can be represented
 Disadvantage
 Need ‘Join’ which requires more processing
time for query (on ‘pilot’ table)
118
Transforming Overlapping:
• แปลงตารางได้เพียงตารางเดียวเท่านัน
้ คือ ตารางที่
เกิดจาก superclass โดยนา attribute ทุกตัวมาจาก
subclass
• และเพิม
่ attribute ใหม่ ให้มจี านวนเท่ากับ
subclass เพือ
่ เก็บ flagของsubclass
119
Transforming Overlapping:
ตาแหน่ง
รหัสพนักงาน
พนักงาน
ชนิดค่าตอบแทน
ชื่อพนักงาน
เงินเดือน
เงินเดือน
พนักงานที่ได้รับ เงินเดือน
O
รายชัว่ โมง
อัตราค่าแรงต่อชม.
พนักงานที่ได้รับค่าตอบแทนเป็ น
ชัว่ โมง
พนักงานแต่ละคนมีสิทธิ์ได้รับทั้งเงินเดือนและค่าตอบแทนเป็ นชัว่ โมงด้วย
120
Transforming Overlapping:
 แปลงได้รีเลชัน่ เดียวและเก็บข้อมูลทุกอย่างลงไป
 เพิ่มแอตทริ บิวต์ที่ทาหน้าที่เป็ นแฟล็ก สาหรับเก็บค่า T หรื อ F
 พนักงาน(รหัสพนักงาน, ชื่อพนักงาน, ตาแหน่ง, แฟล็ก
เงินเดือน, เงินเดือน, แฟล็กค่าตอบแทนเป็ นชม, อัตราค่าแรงต่อ
ชม)
 ถ้าแฟล็กเงินเดือน มีค่าเป็ นจริ ง, ควรต้องมีค่าในช่องเงินเดือนด้วย
121
Structured Attributes
 Example
Instructor
name
firstname
lastname
 Relational Model has no support for structured
attributes so each column can only be created
for each detail attribute
…
Instructor
firstname lastname
122
Multivalued Attributes
 Example
ID
Instructor
Name
Degrees
 Relational model supports only singlevalued attribute
 Multivalued attribute in ER model must be
transformed into a table
 Each row has each value of the attribute
123
Transforming Multivalued
Attributes
 Example
ID
Instructor
Name
Degrees
Instructor
ID
Name
Instructor_degree
ID
Degree
124
Case Study:ระบบส่ งหนังสื ออิเล็กทรอนิกส์
 ความต้องการของระบบ







เก็บข้อมูลหนังสื อซึ่ ง มีหลายประเภท เช่น หนังสื อภายใน หนังสื อภายนอก
เก็บข้อมูลประเภทของบุคลากร
เก็บข้อมูลการสังกัดของบุคลากร โดยแบ่งเป็ น ฝ่ าย / สาขา
เก็บข้อมูลตาแหน่งของบุคลากร
เก็บข้อมูลการลงรับหนังสื อ
เก็บข้อมูลการส่ งหนังสื อ
ออกรายงานการรับหนังสื อของบุคลากรแต่ละคน
125
LOGO
FAQ
126