บทที่ 2 database design

บทที่ 2 Database Design:

บท ที่ 2 Database Design

Slide 2:

2 วงจรชีวิตการพัฒนาฐานข้อมูล Database Life Cycle : DBLC วิเคราะห์ความต้องการ Initial Study ออกแบบฐานข้อมูล Database Design สร้างฐานข้อมูล Implement and Loading ทดสอบระบบฐานข้อมูล Testing and Evaluation บำรุงรักษา Maintenance ใช้งานจริง Operation

Slide 3:

3 วงจรชีวิตของฐานข้อมูลมีดังนี้ Database Initial Study :วิเคราะห์ความต้องการของผู้ใช้ Data Design :ออกแบบฐานข้อมูล ( Data Driven, Joint Data and Function-driven) Implementation and Loading :สร้างเป็นฐานข้อมูล Testing and Evaluation :ทดสอบฐานข้อมูลที่สร้าง Operation :ใช้งานฐานข้อมูล Maintenance and Evaluation :บำรุงรักษาฐานข้อมูล Database Life Cycle :DBLC

ซีเมนติก โมเดล :

โมเดลจำลองความสัมพันธ์ระหว่างข้อมูล (ER-Diagram) ซีเมนติก โมเดล

Outline:

5 Outline ประโยชน์ ของ การออกแบบฐานข้อมูล ขั้นตอนในการออกแบบฐานข้อมูล ER-Diagram Map ER to Relation

การออกแบบฐานข้อมูลมีประโยชน์อย่างไร:

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

ขั้นตอนในการออกแบบฐานข้อมูล:

7 ขั้นตอนในการออกแบบฐานข้อมูล 1. Requirement Analysis 2. Conceptual Design 3. Logical Design 4. Schema Refinement 5. Physical Design 6. Security Design (ER-Diagram) (Normalization) DBA Database Designer 7. Maintenance 1. Requirement Analysis 2. Conceptual Design 3. Logical Design 1. Requirement Analysis 2. Conceptual Design 4. Schema Refinement 3. Logical Design 1. Requirement Analysis 2. Conceptual Design 5. Physical Design 4. Schema Refinement 3. Logical Design 1. Requirement Analysis 2. Conceptual Design 6. Security Design 5. Physical Design 4. Schema Refinement 3. Logical Design 1. Requirement Analysis 2. Conceptual Design

1. สำรวจความต้องการใช้งาน (Requirement Analysis):

8 1. สำรวจความต้องการใช้งาน (Requirement Analysis) เป็นขั้นตอนแรกที่สำคัญมากต่อระบบฐานข้อมูล จะรู้ความต้องการของผู้ใช้งานและระบบได้อย่างไร

จะรู้ความต้องการของผู้ใช้งานได้อย่างไร:

9 จะรู้ความต้องการของผู้ใช้งานได้อย่างไร ศึกษาเอกสารที่ใช้ในระบบงานนั้นๆ การใช้แบบสอบถาม การพูดคุยกับผู้ใช้โดยตรง ข้อมูลที่เราจำเป็นต้องเก็บรวบรวมเพื่อนำไปใช้ในการออกแบบระบบฐานข้อมูล ประกอบด้วย ข้อมูลแต่ละตัวที่จำเป็นต้องใช้ในระบบงาน(Entity) รายละเอียดของข้อมูลนั้น(Attribute) ความสัมพันธ์ระหว่างข้อมูลทั้งหมด(Relationship)

ตั้งคำถาม ถามระบบ:

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

2. ออกแบบฐานข้อมูลระดับแนวคิด (Conceptual Design):

11 2. ออกแบบฐานข้อมูลระดับแนวคิด (Conceptual Design) หลังจากได้ความต้องการแล้ว ก็จะทำการออกแบบเชิงแนวคิด (conceptual design) โดยใช้ตัวแบบข้อมูลเชิงแนวคิด (conceptual data model) เช่น ER-Model ในการออกแบบเค้าร่างเชิงแนวคิด ผู้ออกแบบฐานข้อมูลจะต้อง กำหนดเอนติติ้และแอตทริบิวต์ กำหนดคอนสเตรนต์ กำหนดความสัมพันธ์ หลังจากได้เค้าร่างเชิงแนวคิดแล้ว ผู้วิเคราะห์ระบบจะนำเค้าร่างเชิงแนวคิดไปยืนยันกับผู้ใช้ถึงความต้องการทั้งหมด เพื่อให้แน่ใจว่าไม่ได้หลงลืมความต้องการหรือข้อมูลบางส่วนไป

3. ออกแบบฐานข้อมูลระดับตรรกะ (Logical Design):

12 3. ออกแบบฐานข้อมูลระดับตรรกะ (Logical Design) เมื่อได้ออกแบบเค้าร่างเชิงแนวคิดที่ได้รับการยืนยันจากผู้ใช้แล้ว ก็จะจัดทำการออกแบบเชิงตรรกะ (logical design) เพื่อออกแบบเค้าร่างเชิงตรรกะ (logical schema) ให้เป็นไปตามตัวแบบข้อมูลของระบบการจัดการฐานข้อมูล เป็นขั้นตอนการแปลง ER-Diagram ไปเป็นตารางตาม Relational data Model

4. ปรับโครงสร้างข้อมูล (Schema Refinement):

13 4. ปรับโครงสร้างข้อมูล (Schema Refinement) ตารางที่ได้จากการออกแบบฐานข้อมูลในระดับ Logical ยังไม่ใช่ตารางที่เหมาะสำหรับนำไปเก็บข้อมูลจริง เนื่องจากอาจทำให้เกิดความซ้ำซ้อนของข้อมูล และปัญหาต่างๆ เช่น ปัญหาการเพิ่มข้อมูล(Insert Anomaly) ขั้นตอนนี้ เป็นการปรับโครงสร้างตาราง โดยการทำ Normalization ซึ่งจะทำให้ได้จำนวนตารางมากขึ้นกว่าเดิมแต่ปัญหาต่างๆจะถูกกำจัดออกไป

5. ออกแบบฐานข้อมูลระดับกายภาพ (Physical Design):

14 5. ออกแบบฐานข้อมูลระดับกายภาพ (Physical Design) เป็นหน้าที่ DBA เพื่อให้ระบบฐานข้อมูลเกิดประสิทธิภาพมากที่สุด การออกแบบในระดับนี้ เกี่ยวข้องกับการสร้างอินเด็กซ์ (Index)และการเลือกโครงสร้างข้อมูลระดับภายใน (Internal View) เพื่อให้สอดคล้องกับลักษณะการใช้งานข้อมูลที่เกิดขึ้นบ่อยๆ เช่น สร้างอินเด็กซ์ที่คอลัมน์ซึ่งมักถูกใช้กำหนดเป็นเงื่อนไขในการดึงข้อมูล

6. ควบคุมการนำไปใช้ (Security Design):

15 6. ควบคุมการนำไปใช้ (Security Design) เป็นการกำหนดสิทธิในการใช้งานข้อมูลที่ DBA จะกำหนดขึ้นตามความเหมาะสมและความต้องการของผู้ใช้งาน

7. การบำรุงรักษาระบบ (Maintenance Database System):

16 7. การบำรุงรักษาระบบ (Maintenance Database System) เป็นขั้นตอนที่มีความสำคัญกับระบบมาก เมื่อระบบทำงานช้าลง ต้องตรวจสอบ เมื่อพบข้อผิดพลาดจากข้อมูลที่เก็บ เมื่อความต้องการของระบบหรือผู้ใช้เปลี่ยนไป เมื่อนโยบายขององค์กรเปลี่ยนไป การสำรองข้อมูล เมื่อไร backup / การกู้คืนข้อมูล การป้องกันไวรัสทุกชนิด โจรกรรมข้อมูล

การออกแบบฐานข้อมูล:

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

Entity Relationship Data Model:

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) ของฐานข้อมูล

Entity Relationship Data Model(ต่อ):

19 Entity Relationship Data Model( ต่อ) นำ ER-Diagram ไปใช้ทบทวนยืนยันความเข้าใจที่ถูกต้องกับ user ของระบบงานได้ เพราะ ER-Diagram ประกอบด้วยสัญลักษณ์ที่สื่อความหมายเข้าใจได้ง่าย เมื่อได้ ER-Diagram ที่ถูกต้องเหมาะสมกับระบบงานแล้วและทราบแล้วว่าจะใช้ DBMS ชนิดใด จึงจะทำการแปลง (Mapping) ให้ได้เป็น Logical schema ที่ตรงกับ DBMS

Basic Structure:

20 Basic Structure องค์ประกอบของโครงสร้างข้อมูล โดย ER-model ประกอบด้วยโครงสร้างดังนี้ Entity Relationship Attribute Primary Key

Entity:

21 Entity เอนติตี้(Entity) สิ่งที่มีอยู่ใน ขอบเขตของ ระบบที่เราสนใจ อาจเป็น สิ่งของ คน สถานที การกระทำ เหตุการณ์ โดยแต่ละเอนติตี้จะเก็บเรื่องเดียวกัน เช่น นักศึกษา , รถยนต์, หนังสือ, การทำผิด, เพลง, การเช่า ,ประวัติการทำงาน, การประมูล, การสัมมนา, น้ำตก , บ้านเช่า เป็นต้น

Attribute:

22 Attribute ลักษณะหรือคุณสมบัติที่นำมาใช้อธิบายสิ่งต่างๆ( Entity) และความสัมพันธ์ต่างๆ (Relationship) ในระบบงาน เช่น attribute ที่นำมาอธิบาย Entity ของ ลูกค้า ในระบบงานขายสินค้า ชื่อ สกุล ที่อยู่ รายได้ สถานภาพ อาชีพ เช่น attribute ที่นำมาอธิบาย Entity ของ การลดราคา ในระบบงานแสดงสินค้า ครั้งที่ วันที่เริ่มต้น วันสุดท้าย ชื่อสถานที่จัดงาน เช่น attribute ที่นำมาอธิบาย Relationship ของซื้อสินค้า ในระบบงานขายสินค้า วันที่ซื้อ วันที่ต้องการส่งสินค้า จำนวนที่ซื้อสินค้า

Relationship:

23 Relationship ความสัมพันธ์ระหว่าง entity ต่างๆ ซึ่งเปรียบเทียบได้กับกริยาโครงสร้างของ 1 ประโยค โดยทั่วไปประกอบด้วย ประธาน กริยา กรรม ประธาน และ กรรม เป็นคำนาม เปรียบเป็น Entity กริยาแสดงความสัมพันธ์ระหว่างประธานกับกรรม เปรียบเป็น Relationship เช่น นักศึกษา 1 คน เรียน ได้หลายๆวิชาใน 1 เทอม

Degree of Relationship :

24 Degree of Relationship Degree ของชนิดความสัมพันธ์ คือ จำนวนของชนิดของ entity ที่มีส่วนร่วมในความสัมพันธ์นั้น Unary (Recursive) Relationship ความสัมพันธ์ภายใน entity เดียวกัน Binary Relationship ความสัมพันธ์ระหว่าง 2 entities Ternary Relationship ความสัมพันธ์ระหว่าง 3 entities

ตัวอย่าง ของ Degree of Relationship:

25 ตัวอย่าง ของ Degree of Relationship พนักงาน หัวหน้างาน 1 m Unary M วิชาเรียน หนังสือ อาจารย์ สอน M M Ternary นักศึกษา ลงทะเบียน วิชาเรียน Binary M M

Cardinality of Relationships:

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)

Mapping Cardinalities:

27 Mapping Cardinalities One to one One to many

Mapping Cardinalities :

28 Mapping Cardinalities Many to one Many to many

One to One Relationship:

29 One to One Relationship ความสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติตี้แรก สามารถจับคู่กับข้อมูลในเอนติตี้ที่สองได้เพียงแถวเดียวเท่านั้น เช่น ระบบข้อมูลมหาวิทยาลัย อาจารย์ 1 คน เป็นคณบดีได้เพียง 1 คณะ และ แต่ละคณะ มีอาจารย์ที่เป็นคณบดีได้คนเดียวเท่านั้น อาจารย์ เป็นคณบดี 1 1 คณะ

One to Many:

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

Many to Many:

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

Primary Key:

32 Primary Key Attribute หรือ กลุ่มของ attribute ที่แสดงเอกลักษณ์ของสิ่งใดสิ่งหนึ่งได้ ดังนั้นสิ่งต่างๆ จะมีค่า primary key ไม่ซ้ำกันเสมอ

Slide 33:

เอนติตี้ เอนติติ้แบบอ่อน (Weak Entity) ความสัมพันธ์ ความสัมพันธ์แบบอ่อน (Weak Relationship) แอตทริบิวต์ แอตทริบิวต์ที่เป็น primary key แอตทริบิวต์ที่มีหลายค่า แอตทริบิวต์ประกอบ Partial Key เป็น key ของ weak entity ซึ่งค่า partial key ซ้ำกันได้ E1 E2 derived attribute เก็บผลของการคำนวณ หรือแปลงค่ามาจากแอตทริบิวเดิม ความสัมพันธ์ที่ข้อมูลทุกๆ แถวในเอนติติ้ E2 สามารถจับคู่ได้กับข้อมูลแถวใดแถวหนึ่งของ E1 ได้ เรียกว่า ข้อมูลใน E2 เป็น total participation กับ E1 ความสัมพันธ์ที่ข้อมูลทุกๆแถวในเอนติติ้ E1 สามารถจับคู่ได้กับข้อมูลแถวใดแถวหนึ่งของ E2 ได้เรียกว่า ข้อมูลใน E2 เป็น partial participation กับ E1 R E1 E2 R

สัญลักษณ์ของ ER Model:

34 สัญลักษณ์ของ ER Model สัญลักษณ์ ความหมาย สี่เหลี่ยมผืนผ้า เอนติตี้ เอนติติ้แบบอ่อน (Weak Entity) ความสัมพันธ์ ER-Model ตามแบบของ Peter Pin Shan Chen

สัญลักษณ์ของ ER model(ต่อ):

35 สัญลักษณ์ของ ER model(ต่อ) สัญลักษณ์ ความหมาย ความสัมพันธ์แบบอ่อน (Weak Relationship) แอตทริบิวต์ แอตทริบิวต์ที่เป็น primary key

สัญลักษณ์ของ ER Model(ต่อ):

36 สัญลักษณ์ของ ER Model(ต่อ) สัญลักษณ์ ความหมาย แอตทริบิวต์ที่มีหลายค่า แอตทริบิวต์ประกอบ (แอตทริบิวต์ด้านบนเป็นส่วนประกอบของแอตทริบิวต์ด้านล่าง) Partial Key เป็น key ของ weak entity ซึ่งค่า partial key ซ้ำกันได้

สัญลักษณ์ของ ER model(ต่อ):

37 สัญลักษณ์ของ ER model(ต่อ) สัญลักษณ์ ความหมาย ดีไรฟ์แอตทริบิ่วต์(derived attribute) เก็บผลของการคำนวณหรือแปลงค่ามาจากแอตทริบิวเดิม ความสัมพันธ์ที่ข้อมูลทุกๆแถวในเอนติติ้ E2 สามารถจับคู่ได้กับข้อมูลแถวใดแถวหนึ่งของ E1 ได้ เรียกว่า ข้อมูลใน E2 เป็น total participation กับ E1 E1 E2 R

สัญลักษณ์ของ ER model(ต่อ):

38 สัญลักษณ์ของ ER model(ต่อ) สัญลักษณ์ ความหมาย ความสัมพันธ์ที่ข้อมูลทุกๆแถวในเอนติติ้ E1 สามารถจับคู่ได้กับข้อมูลแถวใดแถวหนึ่งของ E2 ได้เรียกว่า ข้อมูลใน E2 เป็น partial participation กับ E1 E1 E2 R

Participation Constraint:

39 Participation Constraint เงื่อนไขการมีส่วนร่วม คือ จำนวนต่ำสุดของ entity ที่อีก entity หนึ่งมีความสัมพันธ์ด้วย มี 2 แบบคือ Total Participation การที่ entity หนึ่ง entity จะต้องมีความสัมพันธ์กับ entity อื่นอย่างน้อยหนี่ง entity เช่น อาจารย์ทุกคนต้องสังกัดอย่างน้อยใน หนี่งคณะ เป็นต้น การมีส่วนร่วมทั้งหมดจะแสดงด้วยเส้นคู่ทางด้านชนิดของ entity ที่ทุก entity ในชนิดนั้นต้องเข้าร่วมในความสัมพันธ์ อาจารย์ สังกัด คณะ M 1

Participation Constraint(ต่อ):

40 Participation Constraint( ต่อ) Partial Participation การที่ entity หนึ่ง entity มีความสัมพันธ์กับ entity อื่นอย่างน้อยศูนย์ entity คือในชนิดของ entity เดียวกันอาจมีบาง entity ที่มีส่วนร่วมในความสัมพันธ์นั้น ในขณะที่บาง entity ที่ไม่มีส่วนร่วมในความสัมพันธ์นั้นเลย เช่น แผนกบางแผนกไม่มีพนักงานสังกัดเลย และบางแผนกอาจมีพนักงานสังกัดหลายคน การมีส่วนร่วมบางส่วนจะแสดงโดยใช้เส้นเดียวด้านชนิดของ entity ที่บาง entity ในชนิดนั้นมีส่วนร่วมในความสัมพันธ์ เช่น เส้นเดียวจาก entity แผนก อาจารย์ สังกัด แผนก M 1

ประเภทของ attribute:

41 ประเภทของ attribute Simple Attribute คือ แอตทริบิวที่เก็บค่าได้เพียงค่าเดียวเท่านั้น เช่น รหัสลูกค้า ลูกค้า 1 คนมีรหัสลูกค้าได้หมายเลขเดียว Multi-valued attribute คือ แอตทริบิวต์ที่เก็บค่าได้ตั้งแต่ 1 ค่าขึ้นไป เช่น เบอร์โทรศัพท์ ของลูกค้า มีทั้งเบอร์บ้าน เบอร์มือถือ เป็นต้น ลูกค้า เบอร์โทรศัพท์

ประเภทของแอตทริบิวต์(ต่อ):

42 ประเภทของแอตทริบิวต์(ต่อ) Composite attribute คือแอตทริบิวต์ที่ประกอบด้วยแอตทริบิวต์หลายตัวมารวมกันจึงให้ความหมายที่ชัดเจน ชื่อ - สกุล ลูกค้า ชื่อ สกุล ที่อยู่ ถนน จังหวัด อำเภอ

ประเภทของแอตทริบิวต์(ต่อ):

43 ประเภทของแอตทริบิวต์(ต่อ) Derived attribute คือ แอตทริบิวต์ที่เก็บผลการคำนวณหรือแปลงค่ามาจากแอตทริบิวต์อื่นๆ เช่น จำนวนเงิน(ราคา*จำนวน) แผนก จำนวนพนักงาน รหัสแผนก

Weak Entity:

44 Weak Entity Weak entity ต้องมีคุณสมบัติ 2 ข้อ คือ 1. ไม่มี Primary Key มีเพียง partial key (ซึ่งเป็นค่าที่ซ้ำกันได้) ดังนั้นนำเอา partial key ไปรวมกับ Primary key ของ Strong Entity ก็จะเป็นค่าที่ไม่ซ้ำได้ 2. Weak entity ต้องมีความสัมพันธ์กับ Strong Entity อย่างน้อย 1 entity คือ ลักษณะของการขึ้นต่อกัน คือ การที่เอนติตี้หนึ่งจะเกิดขึ้นได้นั้น ขึ้นกับอีกเอนติตี้หนึ่งว่าปรากฏอยู่หรือไม่

Weak Entity (ต่อ):

45 Weak Entity ( ต่อ) ตัวอย่าง เอนติตี้พนักงานและเอนติตี้ญาติ ถ้าไม่มีเอนติตี้พนักงาน เอนติตี้ญาติก็จะไม่เกิดขึ้น เอนติตี้ญาติ เป็น Weak Entity เอนติตี้พนักงาน เป็น Entity พนักงาน มี ญาติ 1 M - ญาติ เป็น weak entity ที่ไม่มี primary key โดยคุณสมบัติ ลำดับที่ มีค่าซ้ำกันในรีเลชั่น ญาติ เพราะคุณสมบัติ ลำดับที่ มีค่าซ้ำๆ กันได้ในหลายญาติ เช่น ลำดับที่ 1 เป็นญาติ นายขาว และลำดับที่ 1 เป็นญาติ นายแดง - ฝั่งชนิดของ entity ญาติ เป็นแบบ Total Participation ลำดับที่ รหัสพนักงาน

Weak Entities(ต่อ):

Weak Entities(ต่อ) ชื่อวิชา( รหัสวิชา , ชื่อวิชา) วิชาที่เปิดสอน( รหัสวิชา* , ปี-ภาค , กลุ่ม , เวลาเรียน) วิชา เปิดสอน วิชาที่เปิดสอน 1 M รหัสวิชา ชื่อวิชา รหัสการเปิดสอน เวลาเรียน ปี-ภาค กลุ่ม

ตัวอย่าง Recursive Relationships:

47 ตัวอย่าง Recursive Relationships Course Precond. วิชาที่ลงทะเบียน วิชาที่ต้องผ่านก่อน Course( CourseID , CourseName, Unit, PrecondCourseID* ) 1 1 ตัวอย่าง การลงทะเบียนบางวิชา จะต้องเรียนวิชาอื่นมา 1 วิชา (one to one)

Recursive Relationships(ต่อ):

48 Recursive Relationships(ต่อ) CourseID CourseName Unit PrecondCourseID* Database Management System 3 4122202 4122202 Introduction to Database 3 4121202 Programming and algorithm 3 4122101 Programing Language 1 3 4121202 4123601

ตัวอย่าง Recursive Relationships:

ตัวอย่าง Recursive Relationships Course Precond. วิชาที่ลงทะเบียน วิชาที่ต้องผ่านก่อน Precondition( CourseID , PrecondCourseID ) Course( CourseID , CourseName, Unit) m m ตัวอย่าง การลงทะเบียนบางวิชา จะต้องเรียนวิชาอื่นมา 1 วิชาหรือหลายๆวิชา (many to many)

Recursive Relationships(ต่อ):

Recursive Relationships(ต่อ) CourseID CourseName Unit 4123601 Database Management System 3 4122202 Introduction to Database 3 4121202 Programming and algorithm 3 4122101 Programing Language 1 3 Course CourseID PrecondCourseID 4123601 4122202 4123601 4122101 4121202 4121101 4122101 4121202 Precondition

ตัวอย่าง Recursive Relationships:

ตัวอย่าง Recursive Relationships ตัวอย่าง พนักงานที่เป็นหัวหน้า 1 คน มีลูกน้องได้หลายคน ทั้งหัวหน้าและลูกน้องก็เป็นพนักงานทั้งคู่ (one to many) Employees Manage หัวหน้า ลูกน้อง 1 m Employees( EmpID , EmpName, BirthDate, MangerID*)

Slide 52:

เป็นความสัมพันธ์ที่มีเอนติตี้ที่เกี่ยวข้อง 3 เอนติตี้ เช่นความสัมพันธ์ดีกรี 3 ของความสัมพันธ์ระหว่าง ผู้ขาย โครงการ สินค้า เนื่องจากผู้ขายสามารถขายสินค้าให้กับโครงการใดก็ได้ ตัวอย่าง Ternary Relationships

Slide 53:

ตัวอย่าง Ternary Relationships M ผู้ขาย สินค้า โครงการ สำหรับ M M รหัสโครงการ รหัสผู้ขาย รหัสสินค้า ผู้ขาย-โครงการ-สินค้า( รหัสผู้ขาย, รหัสโครงการ, รหัสสินค้า , จำนวน) จำนวน

Slide 54:

ตัวอย่าง Ternary Relationships M E2 E3 E1 R M 1 ID1 ID2 ID3 R ( ID3 , ID2 , ID1) M E2 E3 E1 R M M ID1 ID2 ID3 R ( ID3, ID2 , ID1 )

Aggregation:

55 Aggregation Treat aggregation as any other entity type Treatment Physician Patient Treat M M Drug Use M M Physician(…), Patient(…), Drug(…) Treat ( PhysicianID, PatientID ) Use( PhysicianID, PatientID, DrugID )

หลักการแปลง ER เป็นรีเลชั่น:

หลักการแปลง ER เป็นรีเลชั่น ให้แปลงเอนติติ้ทุกตัวเป็นรีเลชั่น และแปลงแอตทริบิวต์ทุกตัวของเอนติตี้ให้เป็นแอตทริบิวต์ของรีเลชั่น Customer CusID CusName CusSurName CusAdd Customer( CusID , CusName, CusSurName, CusAdd)

หลักการแปลง ER เป็นรีเลชั่น(ต่อ):

หลักการแปลง ER เป็นรีเลชั่น ( ต่อ ) 2. เพิ่มแอตทริบิวต์ให้กับรีเลชั่น 2.1 ถ้าความสัมพันธ์เป็นแบบ 1 to 1 ให้นำ pk ของรีเลชั่นฝั่งใดฝั่งหนึ่งไปอยู่ในรีเลชั่นของอีกฝั่งหนึ่ง ** ต้องให้ค่าในแอตทริบิวใหม่เป็น Null น้อยสุดหรือไม่มี Teacher ThID ThName ThSurName Teacher( ThID , ThName, ThSurName) Faculty( FacID ,FacName,ThID*) เป็นคณบดี Faculty FacID FacName 1 1

Slide 58:

58 Teacher( ThID , ThName, ThSurName) Faculty( FacID ,FacName,ThID*) Teacher( ThID , ThName, ThSurName,FacID*) Faculty( FacID ,FacName)

Slide 59:

59 FacID FacName ThID* 1 วิทยาศาสตร์ 001 2 มนุษย์ 034 3 วิทยาการจัดการ 253 4 ครุศาสตร์ 333 5 เทคโนโลยีอุตฯ 111 ThID ThName ThSurName 001 ผศ.วาสนา ใจดี 034 อ.สมคิด ใจดี 253 รศ.ฉลาด ใจดี 333 ผศ.สมาธิ ใจดี 111 อ. ดุษฎี ใจดี 002 อ. ประสงค์ ใจดี 003 อ. ปรานี ใจดี

Slide 60:

60 FacID FacName 1 วิทยาศาสตร์ 2 มนุษย์ 3 วิทยาการจัดการ 4 ครุศาสตร์ 5 เทคโนโลยีอุตฯ ThID ThName ThSurName FacID 001 ผศ.วาสนา ใจดี 1 034 อ.สมคิด ใจดี 2 253 รศ.ฉลาด ใจดี 3 333 ผศ.สมาธิ ใจดี 4 111 อ. ดุษฎี ใจดี 5 002 อ. ประสงค์ ใจดี 003 อ. ปรานี ใจดี

หมายเหตุ:

61 หมายเหตุ กรณีที่เป็น Total Partial Relationship นำ PK ของด้านที่เป็น Partial Relationship ไปเป็น FK ของด้านที่เป็น Total Relationship

หลักการแปลง ER เป็นรีเลชั่น(ต่อ):

หลักการแปลง ER เป็นรีเลชั่น(ต่อ) 2. เพิ่มแอตทริบิวต์ให้กับรีเลชั่น 2.2 ถ้าความสัมพันธ์เป็นแบบ 1 to Mให้นำ pk ของรีเลชั่นฝั่งที่เป็น 1ไปอยู่ในรีเลชั่นของฝั่งที่เป็น M Customer CusID CusName CusSurName Customer( CusID , CusName, CusSurName) Orders( OID ,OrderDate, ReqDate ,CusID*) สั่งซื้อ Orders OID OrderDate 1 M ReqDate

หลักการแปลง ER เป็นรีเลชั่น(ต่อ):

หลักการแปลง ER เป็นรีเลชั่น(ต่อ) 2. เพิ่มแอตทริบิวต์ให้กับรีเลชั่น 2.3 แอตทริบิวต์ที่อยู่บนความสัมพันธ์ จะนำไปใส่ในรีเลชั่นใด ก็ขึ้นอยู่กับว่าเมื่อใส่ลงในรีเลชั่นนั้นแล้ว จะมีบางแถวหรือไม่มีแถวข้อมูลใดเลยที่มีค่าในแอตทริบิวต์เป็น Null Customer CusID CusName CusSurName Customer( CusID , CusName, CusSurName) Orders( OID ,OrderDate, ReqDate ,CusID*) สั่งซื้อ Orders OID OrderDate 1 M ReqDate

หลักการแปลง ER เป็นรีเลชั่น(ต่อ):

หลักการแปลง ER เป็นรีเลชั่น(ต่อ) 3. สร้างรีเลชั่นใหม่สำหรับความสัมพันธ์แบบ M to M โดยสร้าง PK ได้จาก การนำเอา PK ของแต่ละรีเลชั่น มาประกอบกัน หรือ สร้างแอตทริบิวส์ขึ้นมาใหม่ Products PID PName Price Product(P ID , PName, Price) Orders( OID ,OrderDate, ReqDate ,CusID*) OrderDetail( OID* , PID* , Discount, Amount, UnitPrice) รายการสั่งซื่อ Orders OID UnitPrice M M Amount Discount

ตัวอย่าง สร้าง primary key ใหม่:

65 ตัวอย่าง สร้าง primary key ใหม่ นักศึกษา วิชา ลงทะเบียน รหัสนักศึกษา ชื่อ-นามสกุล ชื่อวิชา กลุ่ม รหัสวิชา M M เกรด นักศึกษา ( รหัสนักศึกษา ,ชื่อ-นามสกุล) วิชา ( รหัสวิชา,กลุ่ม, ชื่อวิชา) ลงทะเบียน ( รหัสการลงทะเบียน , รหัสนักศึกษา * ,รหัสวิชา * ,กลุ่ม * ,เกรด)

หลักการแปลง ER เป็นรีเลชั่น(ต่อ):

หลักการแปลง ER เป็นรีเลชั่น(ต่อ) 4. สำหรับเอนติติ้ที่มีแอตทริบิวต์แบบหลายค่า ให้สร้างรีเลชั่นเพิ่ม ที่มีแอตทริบิวต์แบบหลายค่านั้น PK ของรีเลชั่นใหม่เกิดจาก PK ของรีเลชั่นเดิมประกอบกับ แอตทริบิวต์ที่เกิดจากแอตทริบิวแบบหลายค่า Customer CusID CusName CusSurName Customer( CusID , CusName, CusSurName) CusCredit( CusID* , CreditNum ) CreditNum

Slide 67:

67 หากพบ multivalued attribute ควรแยกออกมาเป็น composite attribute พนักงาน รหัส ชื่อ เบอร์โทรศัพท์ พนักงาน( รหัส ,ชื่อ , นามสกุล,เบอร์โทรศัพท์1,เบอร์โทรศัพท์2) นามสกุล

หลักการแปลง ER เป็นรีเลชั่น(ต่อ):

หลักการแปลง ER เป็นรีเลชั่น(ต่อ) 5. สำหรับเอนติตี้แบบอ่อน ให้สร้างเป็นรีเลชั่น และมี PK ที่มาจาก PK ของรีเลชั่นหนึ่งรวมกับ PK ของเอนติตี้แบบอ่อน Invoice( Inv no , Date) InvoiceDetail( Inv no* , Line ) Date Invoice has Invoice Detail Inv no Line 1 M

Mulitvalued Attributes และการแปลงเป็นรีเลชั่น:

69 Mulitvalued Attributes และการแปลงเป็นรีเลชั่น FACULTY_MEMBER ( Name , Phone) FACULTY_DEGREES ( Name*, Degree ) Faculty Member Degrees Phone Faculty Member has Degree Name Degree

EER model (Enhanced Entity Relationship Model):

70 EER model ( Enhanced Entity Relationship Model) เป็น Model ที่นำแนวคิดของ ER Model มาเพิ่มเติมในเรื่อง 1. ความสัมพันธ์แบบ Superclass/Subclass หรือ Supertype/Subtype 2. แนวคิดของ Generalization/Specialization ซึ่งเป็นแนวคิดที่ใช้ในการสร้างความสัมพันธ์ของ Entity ที่เป็น Superclass/Subclass รวมทั้งการถ่ายทอดคุณสมบัติ (Attribute Inheritance) เหมาะที่จะนำมาใช้กับระบบงานทางธุรกิจที่มีความสลับซับซ้อน ซึ่งจะช่วยลดความซับซ้อนของข้อมูล การเขียน Model ทำได้ง่าย

EER model:

71 EER model Superclass คือ รูปแบบของ Entity ที่เป็นต้นแบบของ Entity อื่นๆ โดย Superclass จะประกอบไปด้วย Subclass ต่างๆ Subclass คือ Entity ที่มีคุณสมบัติบางอย่างที่แตกต่างจากสมาชิกของ Subclass ด้วยกัน แต่จะมีคุณสมบัติพื้นฐานตาม Superclass ตัวอย่าง : Entity พนักงาน เป็น Superclass ประกอบด้วยข้อมูล รหัสพนักงาน,ชื่อ ,วันที่เริ่มทำงาน Entity นี้ประกอบด้วย Subclass คือ - ผู้บริหาร จะมีข้อมูลเฉพาะ คือ รถและเงินเดือนประจำตำแหน่ง - ผู้เชี่ยวชาญ จะมีข้อมูลเฉพาะเกี่ยวกับความชำนาญและค่าตอบแทน - พนักงานแรงงาน จะมีข้อมูลเฉพาะ คืออัตราค่าจ้างรายวัน ข้อมูลของ Entity ที่เป็น Subclass จะต้องมีข้อมูลทั้งหมดจากS uperclass

Slide 72:

72 Manager Specialist Labor - รถประจำตำแหน่ง -เงินเดือนประจำตำแหน่ง -ความชำนาญ - ค่าตอบแทนผู้เชี่ยวชาญ -ค่าจ้างรายวัน Superclass/Subclass รหัสพนักงาน ชื่อพนักงาน วันที่เริ่มงาน Employee

การถ่ายทอดคุณสมบัติ (Attribute Inheritance):

73 การถ่ายทอดคุณสมบัติ (Attribute Inheritance) Subclass จะรับถ่ายทอดคุณสมบัติทุกๆอย่างจาก Superclass ทำให้ไม่ต้องกำหนด Attribute ซ้ำซ้อนใน Subclass ตัวอย่าง : Subclass ผู้บริหาร,ผู้เชี่ยวชาญและพนักงานแรงงาน จะได้รับถ่ายทอดคุณสมบัติทุกๆอย่างจาก Superclass Employee

Generalization:

74 Generalization เป็นกระบวนการจัดการกับ Entity ที่ เ ป็นแม่แบบ เพื่อใช้กำหนด ลักษณะที่เหมือนกันหรือร่วมกัน วิธีการนี้เป็นวิธีแบบล่างขึ้นบน (Bottom-Up Approach) ด้วยการมองหาสิ่งที่เหมือนกันใน Subclass เช่น การพิจารณา Entity ที่เป็น Subclass คือ ผู้บริหาร, ผู้เชี่ยวชาญและพนักงานแรงงาน ว่ามีลักษณะอะไรที่เหมือนกัน เพื่อออกแบบ Entity ที่เป็น Superclass คือ Employee ซึ่งมีข้อมูลร่วมกัน คือ รหัสพนักงาน ชื่อและวันที่เริ่มทำงาน จะกำหนดซับคลาสก่อน แล้วค่อยหาว่าซับคลาสทั้งหมดนั้นมีแอตทริบิวต์อะไรที่เหมือนกันบ้าง

Specialization:

75 Specialization เป็นกระบวนการจัดการกับ Entity ที่มีความแตกต่างกันในกลุ่มของสมาชิกซึ่งขึ้นกับ Superclass วิธีนี้เป็นวิธีแบบบนลงล่าง (Top-Down Approach) ด้วยการมองจุดที่แตกต่างกันระหว่าง Subclass เช่น Superclass Employee ประกอบด้วยพนักงานที่เป็นผู้บริหาร ผู้เชี่ยวชาญและพนักงานแรงงาน ซึ่งมี รายละเอียดเฉพาะ ตามประเภทพนักงาน เครื่องหมายที่ใช้แสดงความสัมพันธ์ ของ Superclass/Subclass เครื่องหมาย U แสดงว่า Subclass เป็น Subset ของ Superclass จุดเชื่อมต่อ คือ วงกลม เส้นที่ลากจาก Superclass มายัง Subclass คือ เส้นที่ถ่ายทอดคุณสมบัติ

ตัวอย่าง ธุรกิจมีการว่าจ้างพนักงาน:

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)

Slide 77:

77 Employee Emp_no Emp_name Address Date_hired d Hourly Employee Salary Employee Consultant Hourly_rate Annual_Salary Contact_no Billing_Rate U U U

สร้าง EER model ตามหลักการ specialization:

78 สร้าง EER model ตามหลักการ specialization พนักงาน พนักงานที่ได้รับ เงินเดือน พนักงานที่ได้รับค่าตอบแทนเป็นชั่วโมง d เงินเดือน รายชั่วโมง รหัสพนักงาน ชื่อพนักงาน ตำแหน่ง อัตราค่าแรงต่อชม. เงินเดือน พนักงานได้รับค่าจ้างเป็นแบบใดแบบหนึ่ง ชนิดค่าตอบแทน

แปลง EER เป็น relation:

79 แปลง EER เป็น relation แบ่ง 4 กรณี แปลงได้ 1 ตาราง โดยนำแอตทริบิวต์ของ subclass ทุกตัว จับมาไว้ในตารางของ superclass แปลงได้ตารางเท่ากับจำนวนของ subclass โดยนำแอตทริบิวต์ของ superclass ทุกตัวไปรวมกับแอตทริบิวต์ของแต่ละ subclass

แปลง EER เป็น relation:

80 แปลง EER เป็น relation แบ่ง 4 กรณี 3. แปลงได้ตารางเท่ากับจำนวน superclass และ subclass โดยตารางที่เป็น superclass จะมีแอตทริบิวต์ของตัวมันเอง แต่สำหรับ subclass ให้นำ pk ของ superclass ไปรวมไว้ยังแต่ละ subclass ด้วย

แปลง EER เป็น relation:

81 แปลง EER เป็น relation แบ่ง 4 กรณี 4. ใช้ได้กับความสัมพันธ์ superclass-subclass แบบ overlapped แปลงตารางได้เพียงตารางเดียวเท่านั้น คือ ตารางที่เกิดจาก superclass โดยนำ attribute ทุกตัวมาจาก subclass และเพิ่ม attribute ใหม่ ให้มีจำนวนเท่ากับ subclass เพื่อเก็บ flag ของ subclass

การแปลงเป็นรีเลชั่น:

82 การแปลงเป็นรีเลชั่น ทำได้ 2 วิธีคือ วิธี 1 แปลงเป็น 3 รีเลชั่น คือ พนักงาน( รหัสพนักงาน , ชื่อพนักงาน, ตำแหน่ง, ชนิดค่าตอบแทน) เงินเดือน( รหัสพนักงาน , เงินเดือน) ค่าตอบแทนเป็นชม( รหัสพนักงาน , อัตราค่าแรง) เหมาะกับการใช้ข้อมูลพนักงานบ่อยๆโดยไม่สนเรื่องค่าจ้าง วิธี 2 แปลงเป็น 2 รีเลชั่น คือ พนักงานที่ได้รับเงินเดือน( รหัสพนักงาน , ชื่อพนักงาน, ตำแหน่ง, เงินเดือน) พนักงานที่ได้รับค่าตอบแทนเป็นชม( รหัสพนักงาน , ชื่อพนักงาน, ตำแหน่ง, อัตราค่าแรงเป็นชม) เหมาะกับความต้องการใช้ข้อมูลพนักงานแยกกัน

สร้าง EER model ตามหลักการ specialization(ต่อ):

83 สร้าง EER model ตามหลักการ specialization (ต่อ) พนักงาน พนักงานที่ได้รับ เงินเดือน พนักงานที่ได้รับค่าตอบแทนเป็นชั่วโมง O เงินเดือน รายชั่วโมง รหัสพนักงาน ชื่อพนักงาน ตำแหน่ง อัตราค่าแรงต่อชม. เงินเดือน พนักงานแต่ละคนมีสิทธิ์ได้รับทั้งเงินเดือนและค่าตอบแทนเป็นชั่วโมงด้วย ชนิดค่าตอบแทน

การแปลงเป็นรีเลชั่น:

84 การแปลงเป็นรีเลชั่น แปลงได้รีเลชั่นเดียวและเก็บข้อมูลทุกอย่างลงไป เพิ่มแอตทริบิวต์ที่ทำหน้าที่เป็นแฟล็ก สำหรับเก็บค่า T หรือ F พนักงาน( รหัสพนักงาน , ชื่อพนักงาน, ตำแหน่ง, แฟล็กเงินเดือน, เงินเดือน, แฟล็กค่าตอบแทนเป็นชม, อัตราค่าแรงต่อชม) ถ้าแฟล็กเงินเดือน มีค่าเป็นจริง, ควรต้องมีค่าในช่องเงินเดือนด้วย

สร้าง EER model ตามหลักการ generalization:

85 สร้าง EER model ตามหลักการ generalization พนักงาน พนักงานที่ได้รับ เงินเดือน พนักงานที่ได้รับค่าตอบแทนเป็นชั่วโมง O ชนิดค่าตอบแทน เงินเดือน รายชั่วโมง

Constraint สำหรับ Specialization และ Generalization:

86 Constraint สำหรับ Specialization และ Generalization 1.Condition เงื่อนไขในการจำแนกข้อมูล 2.Disjoint/Overlap Constraint d ข้อมูลระดับ superclass สามารถสัมพันธ์กับ subclass ได้เพียงหนึ่งตัวเท่านั้น เช่น พนักงาน ทุกคน สามารถรับ เงินเดือนหรือค่าตอบแทนเป็นชม. เพียงอย่างใดอย่างหนึ่งเท่านั้น o ข้อมูลระดับ superclass สามารถสัมพันธ์กับ subclass ได้มากกว่าหนึ่งตัว พนักงาน ทุกคน สามารถรับเงินเดือนหรือค่าตอบแทนเป็นชม. อย่างใดอย่างหนึ่งหรือได้รับทั้งสองอย่างก็ได้

Constraint สำหรับ Specialization และ Generalization(ต่อ):

87 Constraint สำหรับ Specialization และ Generalization (ต่อ) 3.Completeness/Incompleteness หากระบุ subclass ทั้งหมดได้อย่างครบถ้วน เรียกว่า Completeness

ข้อมูลพนักงาน แบ่งประเภทของงานที่รับผิดชอบเป็น 3 กลุ่มเท่านั้น Completeness :

88 ข้อมูลพนักงาน แบ่งประเภทของงานที่รับผิดชอบเป็น 3 กลุ่มเท่านั้น Completeness พนักงาน ผู้จัดการ เลขานุการ d ผู้จัดการ เลขานุการ รหัสพนักงาน ชื่อพนักงาน ประเภทงาน วิศวกร วิศวกร

ข้อมูลยานพาหนะ แบ่งซับคลาสได้ 2 กลุ่ม ไม่ครอบคลุมรถยนต์ประเภทอื่นๆ Incompleteness :

89 ข้อมูลยานพาหนะ แบ่งซับคลาสได้ 2 กลุ่ม ไม่ครอบคลุมรถยนต์ประเภทอื่นๆ Incompleteness รถ รถยนต์ รถบรรทุก d รถยนต์ รถบรรทุก ประเภทงาน

ลักษณะของการจับคู่ข้อมูล(Participation):

90 ลักษณะของการจับคู่ข้อมูล (Participation) Disjoint and Total Participation พนักงาน ทุกคน สามารถรับ เงินเดือนหรือค่าตอบแทนเป็นชม. เพียงอย่างใดอย่างหนึ่งเท่านั้น Disjoint and Partial Participation พนักงาน ที่ได้รับเงิน ต้องได้รับ เงินเดือนหรือค่าตอบแทนเป็นชม. เพียงอย่างใดอย่างหนึ่งเท่านั้น แต่อาจมีพนักงานบางคนที่ไม่ได้รับเงินแบบใดๆเลย

ลักษณะของการจับคู่ข้อมูล(Participation):

91 ลักษณะของการจับคู่ข้อมูล (Participation) Overlap and Total Participation พนักงาน ทุกคน สามารถรับเงินเดือนหรือค่าตอบแทนเป็นชม. อย่างใดอย่างหนึ่งหรือได้รับทั้งสองอย่างก็ได้ Overlap and Partial Participation พนักงาน ที่ได้รับเงิน ต้องได้รับ เงินเดือนหรือค่าตอบแทนเป็นชม. อย่างใดอย่างหนึ่งหรือได้รับทั้งสองอย่างก็ได้ แต่อาจมีพนักงานบางคนไม่ได้รับค่าเงินแบบใดๆ

ปัญหาในการเขียน ER-Diagram:

92 ปัญหาในการเขียน ER-Diagram Fan Trap เป็นปัญหาที่เกิดจากลักษณะการจัดความสัมพันธ์ระหว่าง Entity Chasm Trap เป็นปัญหาที่เกิดจากการเชื่อมโยงความสัมพันธ์ระหว่างข้อมูลไม่ได้

Fan Trap แบบ 1 :

93 Fan Trap แบบ 1 นักศึกษา เกิดจากเอนติตี้ที่มีความสัมพันธ์กับเอนติตี้อื่นมากกว่า 1 ตัวและมีชนิดความสัมพันธ์ออกจากตัวเองเป็น 1 ส่วนอีกข้างหนึ่งเป็น M คณะ หลักสูตร สังกัด มี M M 1 1

Fan Trap(ต่อ):

94 Fan Trap (ต่อ) สมคิด จริยา สายใจ r1 r2 r3 บัญชี มนุษย์ r 4 r 5 r 6 บริหาร บัญชี ภาษาอังกฤษ สมคิดและจริยา เรียนคณะบัญชี แต่ไม่สามารถบอกได้ว่าใครเรียนหลักสูตรบัญชีหรือบริหาร

ทางแก้ Fan Trap แบบ 1:

95 ทางแก้ Fan Trap แบบ 1 คณะ เปลี่ยนแปลงตำแหน่งของเอนติตี้ หลักสูตร นักศึกษา มี สังกัด M M 1 1

Fan Trap แบบ 2 :

96 Fan Trap แบบ 2 เกิดจากการที่เอนติตี้มีความสัมพันธ์แบบเชื่อมต่อเนื่องกันเป็นวงกลม โครงการ ผู้ขาย สินค้า ขาย M M ใช้ ซื้อ M M M M ผู้ขายขายสินค้าอะไร โครงการติดต่อซื้อจากผู้ขายรายใด โครงการต้องการใช้สินค้าใดบ้าง เมื่อโครงการติดต่อซื้อขายจากผู้ขายแต่ละรายแล้ว จะซื้อสินค้าอะไรจากผู้ขายรายนั้นๆ ?

ทางแก้ Fan Trap แบบ 2:

97 ทางแก้ Fan Trap แบบ 2 โดยเพิ่มเอนติตี้ตัวกลาง โครงการ ผู้ขาย ทะเบียนการซื้อ-ใช้สินค้า ขาย M 1 ใช้ ซื้อ M 1 M สินค้า 1

Chasm Trap:

98 Chasm Trap เป็นปัญหาที่เกิดจากการเขียนเอนติตี้ที่มีความสัมพันธ์กับเอนติตี้อื่นๆมากกว่า 1 ตัวและความสัมพันธ์บางส่วนเป็น partial participation ทำให้การจับคู่ข้อมูลระหว่างเอนติตี้ไม่ได้ครบถ้วน หลักสูตร นักศึกษา โครงงาน สังกัด ช่วยงาน M 1 1 M

Chasm Trap (ต่อ):

99 Chasm Trap (ต่อ) บัญชี บริหาร มนุษย์ r1 r2 r3 สมคิด จริยา สายใจ r 4 r 5 งาน1 งาน2 งาน3 โครงงานชื่อ งาน1 ไม่มีนักศึกษาช่วยงาน ทำให้ไม่ทราบว่าโครงงานนี้เป็นของหลักสูตรใด

ทางแก้ Chasm Trap :

100 ทางแก้ Chasm Trap หลักสูตร นักศึกษา โครงงาน สังกัด ช่วยงาน M 1 1 M 1 เจ้าของ M เพิ่มความสัมพันธ์ที่เชื่อมเอนติตี้หลักสูตรกับโครงงาน

แบบฝึกหัดท้ายบทที่ 4:

101 แบบฝึกหัดท้ายบทที่ 4 1. ยกตัวอย่างความสัมพันธ์แบบ 1-1, 1 to M, M to M มาแบบละ 2 ตัวอย่าง 2. เขียน ER-Diagram จากความต้องการของระบบยืม-คืนหนังสือในห้องสมุด ดังต่อไปนี้ หนังสืออาจมีเหมือนกันหลายเล่ม บรรณารักษ์จึงไม่สามารถใช้ ISBN เพื่อแยกระหว่างเล่มที่เหมือนกันได้ ต้องสร้างรหัสของหนังสือแต่ละเล่มขึ้นมาใหม่ หนังสือแต่ละเล่มมีผู้แต่งเพียงหนึ่งคน การยืมหนังสือในห้องสมุดแห่งนี้ เปิดให้บริการเฉพาะสมาชิกเท่านั้น ซึ่งการเป็นสมาชิกนั้น มีวันหมดอายุ และข้อมูลส่วนตัวคือ ชื่อ ที่อยู่และเบอร์โทร

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

102 แบบฝึกหัดท้ายบท สมาชิกแต่ละคนยืมหนังสือได้ครั้งละไม่เกิน 5 เล่ม การยืม-คืนแต่ละครั้งจะต้องบันทึกด้วยว่ายืมวันใด จะต้องส่งหนังสือคืนเมื่อไร วันที่คืนหนังสือ และถ้าส่งช้ากว่ากำหนดต้องเสียค่าปรับ บรรณารักษ์ ต้องจัดทำรายงานเพื่อสรุปในแต่ละเดือนและสมาชิกก็ต้องการบริการดังนี้ รายได้จากค่าปรับในแต่ละเดือน แต่ละเดือนมีผู้มาใช้บริการห้องสมุดจำนวนเท่าไร และยืมหนังสือเป็นจำนวนกี่เล่ม หนังสือในหมวดใดที่มีสมาชิกยืมมากสุด สมาชิกมักจะค้นหาหนังสือที่ต้องการด้วยชื่อหนังสือ ชื่อผู้แต่งและ ISBN

แบบฝึกหัดท้ายบทที่ 4(ต่อ):

103 แบบฝึกหัดท้ายบทที่ 4 (ต่อ) 3. จงแปลง ER diagram จากข้อ 2 ให้เป็นตาราง 4. จงแปลง ER เป็น Relation ชื่อวิชา เปิดสอน วิชาที่เปิดสอน รหัสวิชา รหัสการเปิดสอน 1 M ชื่อวิชา หน่วยกิต ปี-ภาค กลุ่ม สถานที่เรียน เวลาเรียน

Slide 104:

104 Product Uses Quantity Used Product Code be a component of be an assembly of Bills of Material Product Desc . m m 5. จงแปลง ER เป็น Relation