อาจารย์ ดร.ณัฐพงศ์วงศ์พร้อมมูล...

LOGO Relational Database Design

อาจารย์ ดร.ณัฐพงศ์ วงศ์พร้อมมูล คณะวศิวกรรมศาสตร์และเทคโนโลยีอุตสาหกรรม

มหาวทิยาลัยศิลปากร

High-Level Conceptual Data Models for Database Design

REQUIREMENTS COLLECTION AND ANALYSIS o ระหว่างการท าขั้นตอนนี้ ผู้ออกแบบฐานข้อมูล

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

o ผลลัพธ์ของขั้นตอนนี้ ได้แก่ เอกสารความต้องการของผู้ใช้งาน

o ความต้องการควรจะระบุรายละเอียดให้ชัดเจน และมีรายละเอียดมากที่สุดเท่าที่จะระบุได้


REQUIREMENTS COLLECTION AND ANALYSIS o สิ่งที่ท าขนานไปกับการเก็บความต้องการด้าน

ข้อมูลเพื่อให้เกิดประโยชน์สูงสุดคือ การเก็บความต้องการด้านฟังก์ชันของแอพพลิเคชัน

o ประกอบไปด้วย การวิเคราะห์การใช้งานของผู้ใช้งานที่มีการเรียกใช้งานฐานข้อมูลทั้ง Retrievals และ Updates


CONCEPTUAL DESIGN o เมื่อผ่านการเก็บรวบรวมความต้องการและ

วิ เคราะห์แล้ ว ขั้ นตอนถัด ไปคือการสร้ า ง Conceptual Schema ส าหรับฐานข้อมูล

o Conceptual Schema คือค าอธิบายของความต้องการด้านข้อมูลของผู้ใช้งานอย่างกระชับ รวมถึงรายละเอียดของ ชนิดของ Entity, Relationships และ เงื่อนไขข้อก าหนด

o เนื่องจาก Concept ไม่มีรายละเอียดของการ Implement ท าให้สามารถเข้าใจได้ง่ายและสามารถสื่อสารกับผู้ใช้งานที่ไม่รู้เทคนิคเข้าใจได้ง่าย


CONCEPTUAL DESIGN o Conceptual Schema ระดับสูงสามารถใช้

อ้างอิง เพื่อตรวจสอบความครบถ้วนในการเก็บรวบรวมความต้องการของผู้ใช้งาน และเพื่อยืนยันว่าความต้องการของผู้ใช้งานไม่ได้ขัดแย้งกัน

o ขั้ น ต อ น นี้ ผู้ อ อ กแบ บฐ านข้ อ มู ล ต้ อ ง ใ ห้ความส าคัญในการระบุรายละเอียดของข้อมูล โดยไม่จ าเป็นต้องค านึงถึงขนาดของข้อมูล พื้นที่จัดเก็บ และรายละเอียดในการ Implement


CONCEPTUAL DESIGN o ร ะ ห ว่ า ง ห รื อ ห ลั ง จ า ก ก า ร อ อ ก แ บ บ

Conceptual Schema ผู้ออกแบบสามารถใช้ Data Model พื้นฐานในการระบุการใช้งานข้อมูลของผู้ใช้งาน (Queries) และการเข้าใช้งานสามารถระบุได้ระหว่างการวิเคราะห์ฟังก์ชัน

• ขั้นตอนนี้ยังช่วยยืนยันว่า Conceptual Schema มีความครบถ้วนในการเก็บรวบรวมความต้องการด้านฟังก์ชันของผู้ใช้งาน

• การปรับเปลี่ยน Conceptual Schema สามารถท าได้หาก Conceptual Schema เดิมไม่รองรับ ความต้องการทางด้านฟังก์ชัน


LOGICAL DESIGN (DATA MODEL MAPPING) o ขั้นตอนถัดมาในการออกแบบฐานข้อมูลคือ การ

Implement ฐานข้อมูลโดยใช้ DBMS

o Conceptual Schema ถูกแปลงจาก Data Model ระดับสูง ให้เป็น Data Model ส าหรับการ Implement

o ผลลัพธ์ของขั้นตอนนี้คือ Database Schema ในรูปแบบของ Data Model ของ DBMS ที่ใช้ในการ Implement


PHYSICAL DESIGN o ระบุค่าเริ่มต้นของ โครงสร้างพื้นที่จัดเก็บ, การ

จัดการไฟล์, Indexes, Paths และการออกแบบค่าคงที่ทงการภาพส าหรับไฟล์ฐานข้อมูล

o สิ่งที่ท าขนานไปกับขั้นตอนนี้ได้แก่ การออกแบบและ Implement แอพพลิเคชันที่เก่ียวข้องกับTransaction ของฐานข้อมูล


REQUIREMENTS COLLECTION AND ANALYSIS

ยกตัวอย่างแอพพลิเคชันฐานข้อมูลชื่อ COMPANY ซึ่งแสดง ER Model Concept พื้นฐาน และการใช้งานในการออกแบบ Schema o Company จัดให้มี Departments ซึ่งแต่ละ Department ต้องมีชื่อ และเลขที่ที่ Unique

และมี Employee ที่บริหาร Department นั้นๆ บริษัทให้ความสนใจกับวันเริ่มต้นเมื่อ Employee เริ่มบริหาร Department ใน Department สามารถมีได้หลาย Locations

o Department มีการบริหารจัดการ Projects ซึ่งในแต่ละ Project เองก็มีชื่อ และเลขที่ที่ Unique และมี Location เดียว

A Sample Database Application

REQUIREMENTS COLLECTION AND ANALYSIS o ทางบริษัทมีการเก็บ Employee’s name, Social Security Number, Address, Salary,

Sex (Gender) และ Birth Date ซึ่ง Employee ถูกจัดให้อยู่ภายใต้ Department ได้เพียง Department เดียว แต่อาจสังกัดได้หลาย Project ซึ่งไม่ได้ถูกบริหารจัดการด้วย Department เดียวกัน บริษัทให้ความสนใจกับชั่วโมงการท างานต่ออาทิตย์ที่ Employee ท างานในแต่ละ Project และยังสนใจ Supervisor ของ Employee (ซึ่งเป็น Employee คนอื่น)

o บริษัทสนใจ Department ของ Employee เพื่อการท า Insurance โดย Depedent เก็บ First Name, Sex, Birth Date และ Relationship


INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE จากการเก็บความต้องการ สามารถแบ่งออกได้เป็น 4 Entity

o Entity DEPARTMENT มี Attribute ชื่อ Name, Number, Locations, Manager และ Manager_start_date โดยมี Locations เป็น Multivalued Attribute เท่านั้น สามารถก าหนดให้ Name และ Number เป็น Key Attribute ได้เนื่องจาก Unique


INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE o Entity PROJECT มี Attributes ชื่อ Name, Number, Location และ Controlling_department

โดยมีทั้ง Name และ Number เป็น Key Attributes.


INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE o Entity EMPLOYEE มี Attributes ชื่อ Name, Ssn, Sex, Address, Salary, Birth_date,

Department และ Supervisor โดยมี Name และ Address ที่อาจจะเป็น Composite Attributes แต่อย่างไรก็ตามเงื่อนไขนี้ไมได้ถูกระบุในความต้องการ จึงควรกลับไปสอบถามหรือออกแบบเผื่อไว้เช่น Name — First_name, Middle_initial, Last_name ซึ่ง Address ก็จะท าในลักษณะเดียวกัน


INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE o Entity DEPENDENT มี Attribute ชื่อ Employee, Dependent_name, Sex,

Birth_date และ Relationship (to the employee).


INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE o การออกแบบยังไม่ได้กล่าวถึง Employee สามารถท างานได้หลาย Project หรือ ชั่วโมงการ

ท างานต่อสัปดาห์ของ Employee ในแต่ละ Project จากความต้องการนี้ท าให้เกิด Multivalued Composite Attribute ใน Employee ที่มีชื่อว่า Work_on ที่ประกอบไปด้วย Project และ Hours


INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE Relationship Types, Sets, and Instances

o Relationship R ระหว่าง n Entity E1, E2, ..., En บอกถึงกลุ่มของความเกี่ยวข้องหรือกลุ่มของ Relationship ระหว่าง Entity

o ในกรณีที่ Entity และกลุ่มของ Entity, Relationship มีกลุ่มของความสัมพันธ์ Relationship Instance อ้างอิงด้วยชื่อที่เหมือนกันกับ R

o ในทางคณิตศาสตร์ กลุ่มของ Relationship R เป็นกลุ่มของ ri ซึ่งแต่ละ ri เกี่ยวข้องกับ Entity (e1, e2, ..., en) ซึ่งแต่ละ Entity e1 ใน ri เป็นสมาชิกของกลุ่ม Entity Ej, 1 ≤ 𝑗 ≤ 𝑛



o พิจารณา Relationship WORKS_FOR ระหว่าง EMPLOYEE และ DEPARTMENT ซึ่งแต่ละ Employee มีความเกี่ยวข้องกับ Department ซึ่ง Employee ท างานอยู่ในกลุ่ม Entity ที่เกี่ยวข้อง

o แต่ละ Relationship Instance ใน Relationship WORKS_FOR มีความเกี่ยวข้องกับ EMPLOYEE และ DEPARTMENT อย่างละ 1 ความสัมพันธ์



o Employees e1, e3, และ e6 Work for Department d1

o Employees e2 และ e4 Work for Department d2

o Employees e5 และ e7 Work for Department d3.


INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE Relationship Degree, Role Names, and Recursive Relationships

Degree of a Relationship Type.

o Degree ของ Relationship คือจ านวนของ Entity ดังนั้น Relationship WORKS_FOR จีงมี Degree เท่ากับสอง โดย Relationship ที่มี Degree เท่ากับสองเรียนกว่า Binary และ Degree เท่ากับสามเรียนกว่า Ternary



Role Names.

o แต่ละ Entity ใน Relationship มี Role ในแต่ละ Relationship

o ชื่อของ Roles มีความส าคัญต่อ Entity ในแต่ละ Relationship Instant และช่วยอธิบายความหมายของ Relationship

o For example, in the WORKS_FOR relationship type,

o ตัวอย่างเช่น ใน Relationship WORKS_FOR

o EMPLOYEE มี Role เป็น ลูกจ้าง หรือ คนท างาน

o DEPARTMENT มี Role เป็น หน่วยงาน หรือ ผู้จ้างงาน



Recursive Relationships.

o ชื่อของ Role ไม่มีความจ าเป็นด้านเทคนิคใน Relationship เมื่อภายใน Entity มีค่าไม่ซ้ ากัน สามารถใช้ชื่อ Entity เป็นชื่อ Role ได้เลย

o อย่างไรก็ตาม ในบางกรณีที่ใน Entity มีค่าซ้ ากันใน Relationship และมี Role ที่ต่างกัน ในกรณีนี้ชื่อ Role มีความส าคัญในการบอกความหมายของ Entity ซึ่ง Relationship นี้เรียนกว่า Recursive Relationships




o Relationship SUPERVISION เกี่ยวข้องกับ Employee กับ Supervisor ซึ่งทั้ง Employee และ Supervisor เป็นสามาชิกของ EMPLOYEE

o ดังนั้น EMPLOYEE มีส่วนร่วมสองครั้งใน SUPERVISION

o ครั้งแรงใน Role ของ Supervisor

o อีกครั้งใน Role ของ Supervisee





o แต่ละ Relationship Instance ri ใน SUPERVISION เกี่ยวของกับสอง Entity Employee ej และ ek, อันหนึ่งมี Role เป็น Supervisor และอีกอันมี Role เป็น Supervisee

o the lines marked ‘1’ represent the supervisor role,

o เส้น ‘1’ แสดงถึง Role Supervisor

o เส้น ‘2’ แสดงถึง Role Supervisee




o e1 supervises e2 และ e3



แต่ละ Relationship Instance ต้อง

มีความสัมพันธ์ 2 เส้น,

o เส้นแรก ‘1’ (supervisor)

o อีกเส้น ‘2’ (supervisee)

INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE Cardinality Ratios for Binary Relationships

Cardinality ratio ส าหรับความสัมพันธ์แบบ Binary บอกถึงจ านวนสูงสุดของความสัมพัธ์ที่ entity สามารถท าได ้

o เช่นในความสัมพันธ์แบบ Binary WORKS_FOR

o DEPARTMENT:EMPLOYEE เป็น cardinality ratio 1:N, มีความหมายว่าแต่ละ department สามารถมีความสัมพันธ์ (จ้างงาน) กับ employee ได้อย่างไม่จ ากัด แต่ employee สามารถมีความสัมพันธ์ (ท างาน) ได้เพียง 1 department

o Department entity สามารถมีความสัมพัธ์กับ employee ได้หลายจ านวน (N เป็นค่าสูงสุด)

o Employee สามารถมีความสัมพันธ์ได้สูงสุดแค่ 1 department.

Cardinality ratios ของความสัมพัธ์แบบ binary มีความเป็นไปได้คือ 1:1, 1:N, N:1, and M:N.



ตัวอย่าง ความสัมพันธ์แบบ binary 1:1

MANAGES มีความสัมพันธ์กับ department ไปยัง employee ที่มีหน้าที่บริหาร department นั้น

o ณ เวลาใด ๆ employee สามารถมีหน้าที่บริหารได้ department เดียวเท่านั้น

o department สามารถมีผู้จัดการได้คนเดียวเท่านั้น



ความสัมพันธ์ WORKS_ON มีcardinality ratio เป็น M:N เนื่องจาก employee สามารถท างานได้หลาย project และในทางกลับกัน project ก็สามารถมี employee ท างานได้หลายคน


INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE Weak Entity Types

o พิจารณา DEPENDENT มีความสัมพันธ์กับ EMPLOYEE เพื่อใช้ในการตรวจสอบความเป็นอิสระของแต่ละ employee ผ่านความสัมพันธ์ 1:N

o ในตัวอย่าง attributes DEPENDENT ประกอบไปด้วย Name (ชื่อของ dependent), Birth_date, Sex, และ Relationship (ที่เกี่ยวกับ employee) dependents สองตัว ของ employees ที่ไม่ซ้ ากัน อาจะมีค่า Name, Birth_date, Sex และ Relationship ซ้ ากัน แต่ยังถือว่าเป็น entities ที่มีข้อมูลไม่ซ้ ากัน Entities เหล่านี้ถือเป็น entities ที่มีข้อมูลไม่ซ้ ากันหลังจากพิจารณา employee ที่มีความสัมพันธ์กับ dependent แล้วเท่านั้น แต่ละ employee entity มีความสัมพันธ์กับ dependent entities ของตัวเอง.

o Weak entity โดยปกติแล้วมี partial key เป็น attribute ซึ่งสามารถแยกได้ว่าเป็น weak entities ได้โดยง่าย.


INITIAL CONCEPTUAL DESIGN OF THE COMPANY DATABASE Weak Entity Types

o ตัวอย่าง สมมติให้ dependents 2 ตัวของ employee เดียวกันมี first name เหมือนกัน attribute Name ของ DEPENDENT เป็น partial key. กรณีที่แย่ที่สุด composite attribute ของ weak entity ทั้งหมดจะเป็น partial key.

o บางครั้ง Weak entity สามารถแสดงในรูปแบบของ complex (composite, multivalued) attributes ตัวอย่าง สามารถท าเป็น multivalued attribute Dependents ส าหรับ EMPLOYEE, ซึ่ง composite attribute ประกอบไปด้วย component attributes ได้แก่ Name, Birth_date, Sex, และ Relationship.


Refining the ER Design for the COMPANY Database สารมารถออกแบบฐานข้อมูลได้โดยเปลี่ยน attribute ที่มีความสัมพันธ์ ให้อยู่ในรูปแบบที่เหมาะสม cardinality ratio และ participation constraint ของแต่ละความสัมพันธ์ถูกออกแบบตามความต้องการของผู้ใช้งาน หากมี cardinality ratio หรือ dependency ที่ไม่สามารถออกแบบได้จากความต้องการ ผู้ใช้งานต้องถามถึงการใช้งานในอนาคตเพื่อออกแบบโครงสร้างฐานข้อมูลที่เหมาะสม


Refining the ER Design for the COMPANY Database ตัวอย่าง ก าหนดให้ความสัมพันธ์มีค่าดังนี้

o MANAGES มีความสัมพันธ์แบบ 1:1 ระหว่าง EMPLOYEE และ DEPARTMENT ส าหรับ EMPLOYEE มีความเกี่ยวข้องแบบ partial ส่วน DEPARTMENT ไม่สามารถสรุปได้จากความต้องการของผู้ใช้งาน จึงเกิดค าถามกับผู้ใช้งานสามารถสรุปได้ว่า department ต้องมีผู้จัดการตลอดเวลา attribute Start_date จึงถูกเพิ่มเข้าไปในความสัมพันธ์

o WORKS_FOR มีความสัมพันธ์แบบ 1:N ระหว่าง DEPARTMENT กับ EMPLOYEE

o CONTROLS มีความสัมพันธ์แบบ 1:N ระหว่าง DEPARTMENT กับ PROJECT จากการส ารวจมีบาง departments ไม่ได้ควบคุม projects.


Refining the ER Design for the COMPANY Database o SUPERVISION มีความสัมพันธ์แบบ 1:N ระหว่าง EMPLOYEE (ในหน้าที่ supervisor) and

EMPLOYEE (ในหน้าที่ supervisee) จากการส ารวจ employee ทุกคนไม่ได้เป็น supervisor และ employee ทุกคนไม่จ าเป็นต้องมี supervisor.

o WORKS_ON มีความสัมพันธ์แบบ M:N กับ Hours หลังจากการส ารวจพบว่า project สามารถม ีemployees หลายคนท างานได้

o DEPENDENTS_OF มีความสัมพันธ์แบบ 1:N ระหว่าง EMPLOYEE กับ DEPENDENT ซึ่งสามารถบอกได้ว่าเป็น weak entity


Summary of Notation for ER Diagrams

อาจารย์ ดร.ณัฐพงศ์วงศ์พร้อมมูล...

Documents