Chapter03 Data Modeling Using Entity-relationship (er) Model

3-1

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

บทที่ 3* ฐานขอมูลเบื้องตนและแบบจําลองเชิงแนวคิด Data Modeling Using Entity-Relationship (ER) Model วัตถุประสงค 1. เพื่อใหรูจักแนวคิดของแบบจําลองอีอาร (ER Model) ซึ่งเปนแบบจําลองขอมูลเชิงแนวคิดระดับสูง (High-level conceptual data model) 2. เพื่อใหรูจักสัญกรณสําหรับแผนภาพอีอาร (ER Diagram) 3. เพื่อใหรูจักแผนภาพ UML แอปพลิเคชันฐานขอมูล (Database Application) หมายถึง ฐานขอมูลและโปรแกรมที่เกี่ยวของที่ใชในการสืบคน ฐานขอมูล (Database query) และปรับปรุงฐานขอมูล (Update) เชน แอปพลิเคชันทางธนาคาร (BANK Application) ที่ทําหนาที่ในการจัดเก็บและติดตามบัญชี (Account) ของลูกคานั้น จะตองมีโปรแกรมเพื่อทําการ ฝากและถอนเงิน ดังนั้นงานสวนหนึ่งในการจัดทําฐานขอมูลนั้น จะตองประกอบดวยการออกแบบ การพัฒนา และ การทดสอบแอปพลิเคชันโปรแกรมดวย

3.1

ระเบียบวิธีการออกแบบฐานขอมูล และระเบียบวิธีทางวิศวกรรม ซอฟตแวร (Database design methodology & Software engineering methodology) ระเบียบวิธีการออกแบบฐานขอมูล (Database design methodology) นั้นจะกลาวถึงแนวคิดในการกําหนด วิธีการดําเนินการ (Operation) กับวัตถุฐานขอมูล (Database object) สวนระเบียบวิธีการทางวิศวกรรม ซอฟตแวร (Software engineering methodology) นั้นจะระบุรายละเอียดเกี่ยวกับโครงสรางของฐานขอมูลที่ โปรแกรมจะใช และเขาถึงฐานขอมูล ซึ่งจะเห็นไดวา ทั้งสองสวนมีความเกี่ยวเนื่องกันอยางมาก

* อางอิงจากบทที่ 3 ของเอกสารอางอิง [1]

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

3-2

รูปที่ 3.1 แผนภาพอยางงาย แสดงเฟสหลักใน การออกแบบ ฐานขอมูล

3.2

ตัวอยางแอปพลิเคชันฐานขอมูล “COMPANY” เพื่อแสดงตัวอยางในการออกแบบฐานขอมูล เราจะใชตัวอยางของฐานขอมูล “COMPANY” โดยจะเรื่มดูตั้งแต ความตองการของบริษัท ซึ่งเราสามารถแยกแยะความตองการและขอกําหนดไดดังนี้ • บริษัทจัดระบบเปนแผนก (Department) โดยแตละแผนกจะมีชื่อ (Name) ที่ไมซ้ํากัน มีเลขที่แผนก (Number) ที่ไมซ้ํากัน และมีพนักงานหนึ่งคนที่เปนผูจัดการ (Manager) ของแผนกนั้น ซึ่งเราจะทํา การเก็บวันที่ที่พนักงานผูนั้นเริ่มทํางานเปนผูจัดการของแผนกนั้น โดยแตละแผนกอาจมีที่ทําการหรือ สํานักงานไดหลายแหง (Location) • แตละแผนกจะทําการควบคุมดูแล (Control) โครงการ (Project) จํานวนหนึ่ง ซึ่งแตละโครงการ จะ ประกอบดวย ชื่อโครงการและเลขที่โครงการที่ไมซ้ํากัน และแตละโครงการ location จะขึ้นอยูกับที่ทํา การ (Location) เพียงแหงเดียวเทานั้น • เราจะจัดเก็บขอมูลพนักงาน (Employee) ซึ่งประกอบดวย ชื่อ รหัสประจําตัว ที่อยู เงินเดือน เพศ และ วันเกิด โดยพนักงานแตละคนสามารถทํางาน (Work) ใหกับแผนกหนึ่งแผนกใดเทานั้น แตอาจทําหลาย โครงการได โดยเราตองการจะติดตามชั่วโมงการทํางานของพนักงานแตละคน แตละโครงการ นอกเหนือจากนั้น เรายังตองการติดตามขอมูลผูควบคุมดูแล (Direct Supervisor) ของพนักงานแตละ คนอีกดวย

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย •

3-3

นอกจากนี้ยังมีการเก็บขอมูลบุตรหรือผูอยูในอุปการะ (Dependent) ของพนักงานแตละคน ซึ่งพนักงาน คนหนึ่งๆ สามารถมีบุตรหรือผูอยูในอุปการะไดหลายคน โดยจะเก็บขอมูล ชื่อ เพศ วันเกิด และ ความสัมพันธกับพนักงานผูนั้น

รูปที่ 3.2 แผนภาพเคารางอี อาร (ER schema diagram) สําหรับ ฐานขอมูล COMPANY

3.3

แนวคิดของแบบจําลองอีอาร (ER Model Concepts) 3.3.1 เอนทิตี (Entity) และแอทตริบิวต (Attribute) เอนทิตี (Entity) คือ วัตถุตางๆ ในมินิเวิรลที่เราสนใจ เชน พนักงาน (EMPLOYEE) แผนก (DEPARTMENT) หรือ โครงการ (PROJECT) เปนตน สวนแอทตริบิวต (Attribute) คือ สมบัติ (Property) ของเอนทิตี เชน เอนทิตีพนักงาน (EMPLOYEE) อาจมี แอทตริบิวตคือ ชื่อพนักงาน รหัสประจําตัว ที่อยู เพศ วันเกิด เปนตน เอนทิตีแตละเอนทิตีจะมีคาที่ระบุไวสําหรับแตละแอทตริบิวต เชน เอนทิตีพนักงาน (EMPLOYEE) อาจมีคา ชื่อ พนักงาน = John Smith รหัสประจําตัว = 123456789 ที่อยู = 731, Frondren, Houston, TX เพศ = ชาย วันเกิด = 9 ม.ค. 55 เปนตน นอกจากนี้ แตละแอทตริบิวตจะตองมีขนิดของขอมูล (Value set หรือ Data type) กํากับอยู เชน จํานวนเต็ม (Integer) ขอความ (String) แบบพิสัยยอย (Subrange) แบบแจงนับ (Enumerated type) เปนตน

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

3-4

รูปที่ 3.3 เอนทิตีพนักงาน (e1) และบริษัท (c1) และแอทตริ บิวตของแตละเอนทิ ตี แอทตริบิวตสามารถแบงออกเปนประเภทตางๆ ดังนี้ • แอทตริบิวตเชืงเดียว (Simple attribute) และ แอทตริบิวตเชิงประกอบ (Composite attribute) - แอทตริบิวตเชืงเดียว (Simple attribute) เปนแอทตริบิวตที่แตละเอนทิตีจะมีคาไดเพียงคา เดียว และไมสามารถจะแบงยอยไดอีก เชน รหัสประจําตัว หรือ เพศ - แอทตริบิวตเชิงประกอบ (Composite attribute) เปนแอทตริบิวตที่ประกอบดวย สวนประกอบตางๆ เชน ที่อยู จะประกอบดวยบานเลขที่ ถนน แขวง เขต จังหวัด รหัสไปรษณีย และประเทศ เปนตน • แอทตริบิวตแบบคาเดี่ยว (Single-valued attribute) และ แอทตริบิวตแบบหลายคา (Multi-valued attribute) - แอทตริบิวตแบบคาเดี่ยว (Single-valued attribute) เปนแอทตริบิวตที่มีไดคาเดียว เชน -

อายุ และสวนสูง เปนตน แอทตริบิวตแบบหลายคา (Multi-valued attribute) เปนแอทตริบิวตที่มีไดหลายคา เชน สี ของรถ วุฒิการศึกษา ซึ่งเขียนในรูปของ {Color} และ {PreviousDegree}

รูปที่ 3.4 การแตกสาขาของ แอทตริบิวตเชิง ประกอบ (Composite attributes)

รูปที่ 3.5 แอทตริบิวตเชิงซอน (Complex attribute): AddressPhone

โดยทั่วไปแลว แอทตริบิวตเชิงประกอบ (Composite attribute) และแบบหลายคา (Multi-valued attribute) อาจมีการซอนมากมายหลายระดับได ถึงแมวาจะเกิดขึ้นไดยากก็ตาม เชน วุฒิการศึกษาของนักศึกษา (STUDENT) เปนแอทตริบิวตเชิงประกอบชนิดหลายคา (Composite multi-value attribute) ซึ่งสามารถ เขียนในรูปของ {วุฒิการศึกษา (มหาวิทยาลัย, ป, วุฒปิ ริญญา, สาขา)} หรือ {PreviouseDegrees (College, Year, Degree, Field)} เปนตน • แอทตริบิวตที่เก็บไว (Stored attribute) และ แอทตริบิวตที่ไดจากการอนุมาน (Derived attribute) - แอทตริบิวตที่เก็บไว (Stored attribute) เชน วันเกิด - แอทตริบิวตที่ไดจากการอนุมาน (Derived attribute) เชน อายุ

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย •

3-5

คาวาง (Null values) บางแอทตริบิวตอาจไมมีคาที่เหมาะสม เชน เลขที่อพารทเมนท (สําหรับคนที่อาศัยอยูบานเดี่ยว) วุฒิ มหาวิทยาลัย เปนตน โดยในการระบุจะใชคาวางในกรณีที่ไมทราบคาของแอทตริบิวต เชน - มีคาที่สามารถระบุลงในแอทตริบิวตแตขาดหายไป เชน ความสูง - ไมทราบคา ถึงแมวาจะมีคานั้นอยู เชน เบอรโทรศัพทบาน เปนตน

3.3.2 ชนิดเอนทิตี (Entity Type) และ แอทตริบิวตที่เปนคีย (Key Attribute) พิจารณารูปที่ 3.2 • เอนทิตีที่มีแอทตริบิวต (Attribute) พื้นฐานเหมือนกัน จะถูกจัดกลุมหรือจัดประเภท ลงในชนิดเอนทิตี (Entity type) เดียวกัน เชน ชนิดเอนทิตีพนักงาน (EMPLOYEE) ชนิดเอนทิตีโครงการ (PROJECT) เปนตน • กลุมของเอนทิตีทุกเอนทิตีที่อยูในชนิดเอนทิตีเดียวกันในฐานขอมูลที่เวลาใดเวลาหนึ่ง จะถูกเรียกวา กลุม เอนทิตี (Entity set) • แอทตริบิวตของเอนทิตีหนึ่งๆที่มีคาแอทตริบิวตเปนคาเฉพาะสําหรับแตละเอนทิตี จะเรียกวา แอทตริบิวต ที่เปนคีย (Key attribute) โดยยึดหลักความเฉพาะเจาะจง เชน รหัสประจําตัวของพนักงาน เปนตน โดยชนิดเอนทิตีหนึ่งๆ อาจมีคียมากกวาหนึ่งคีย เชน ชนิดเอนทิตี CAR ซึ่งอาจมีคียเปน VenhicleIdentificationNumber (VIN) VehicleTagNumber (Number, State) หรือที่เรียกวา license_plate number นอกจากนี้ แอทตริบิวตที่เปนคีย อาจเปนแอทตริบิวตเชิงประกอบ (Composite attribute) เชน VehicleTagNumber เปนคียของเอนทิตี CAR ซึ่งประกอบดวย (เลขที่,รัฐ) -

รูปที่ 3.6 ชนิดเอนทิตี (Entity type)

พนักงาน (EMPLOYEE)

และบริษัท (COMPANY)

รูปที่ 3.7 ชนิดเอนทิตี CAR ซึ่งมีแอทตริบิวต 2 แอทตริบิวตที่เปน คีย คือ Registration และ Vehicle ID

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย •

รูปที่ 3.8 การออกแบบขั้นตน ของชนิดเอนทิตี (Entity type)

รูปที่ 3.9 สรุปสัญลักษณของ แผนภาพ อีอาร สําหรับเคาราง อี อาร (ER Schema)

3-6

Value set หรือโดเมน (Domain) ของแอทตริบิวต แอทตริบิวตแตละแอทตริบิวตของชนิดเอนทิตี (Entity type) จะเกี่ยวของกับ value set หนึ่งๆ (หรือ โดเมนของ value) ซึ่งหมายถึงชนิดขอมูลพื้นฐานที่มีใหในภาษาโปรแกรมทั่วไป เชน จํานวนเต็ม (Integer) ขอความ (String) แบบตรรก (Boolean) จํานวนจริง (Float) แบบแจงนับ (Enumerate type) แบบยอย (Subrange) เปนตน

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

3-7

รูปที่ 3.10 แผนภาพ อีอาร ซึ่ง มีชนิดเอนทิตี คือ EMPLOYEE, DEPARTMEN T, PROJECT, DEPENDENT

3.4

ความสัมพันธ (Relationship) และชนิดความสัมพันธ (Relationship type) ความสัมพันธ (Relationship) เปนตัวเชื่อมเอนทิตีที่แตกตางกันตั้งแต 2 เอนทิตีขึ้นไป โดยมีจุดประสงคที่แนนอน เชน พนักงานชื่อ John Smith (EMPLOYEE John Smith) ทํางาน (Work on) โครงการเกี่ยวกับผลิตภัณฑ X (ProductX PROJECT) หรือ พนักงานชื่อ Franklin Wong (EMPLOYEE Franklin Wong) บริหาร (Manage) แผนกการวิจัย (Research DEPARTMENT) เปนตน (Relationship) ประเภทเดียวกัน จะถูกจัดกลุมหรือจัดประเภทลงในชนิดความสัมพันธ (Relationship type) เดียวกัน เชน ชนิดความสัมพันธ WORKS_ON ซึ่งเชื่อมระหวาง EMPLOYEEs และ PROJECTs หรือ ชนิดความสัมพันธ MANAGES ซึ่งเชื่อมระหวาง EMPLOYEEs และ DEPARTMENTs

ความสัมพันธ

ดีกรีของชนิดความสัมพันธ (Degree of relationship type) คือจํานวนของชนิดเอนทิตี (Entity type) ที่เขา รวม ซึ่งจากตัวอยางดังกลาว จะเห็นวาทั้ง MANAGES และ WORKS_ON ตางก็มีดีกรีเทากับ 2 หรือเรียกได วาความสัมพันธแบบไบนารี (Binary relationship)

รูปที่ 3.11 แสดงชนิด ความสัมพันธ (Relationship type) WORKS_FOR

ระหวาง EMPLOYEE

และ DEPARTMENT

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

3-8

รูปที่ 3.12 12 แสดงชนิด ความสัมพันธ (Relationship type) WORKS_ON

ระหวาง EMPLOYEE และ PROJECT

ในการสรางความสัมพันธ สามารถมีชนิดความสัมพันธ (Relationship type) ไดมากกวา 1 ชนิด ที่เชื่อมระหวาง คูชนิดเอนทิตีที่เขารวมเดียวกัน เชน MANAGES และ WORKS_FOR ซึ่งตางก็เชื่อมระหวาง EMPLOYEE และ DEPARTMENT แตโดยความหมายและรูปแบบความสัมพันธที่แตกตางกัน

รูปที่ 3.13 แผนภาพ อีอาร (ER Diagram) แสดงชนิด ความสัมพันธ (Relationship type) คือ WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENT_OF

3.4.1 ดีกรีของความสัมพันธ (Relationship) • • • • •

ชนิดความสัมพันธ (Relationship type) ที่มีดีกรีเทากับ 2 จะถูกเรียกวา ไบนารี (Binary) ชนิดความสัมพันธ (Relationship type) ที่มีดีกรีเทากับ 3 จะถูกเรียกวา เทอนารี (Ternary) ชนิดความสัมพันธ (Relationship type) ที่มีดีกรีเทากับ n จะถูกเรียกวา เอนนารี (n-ary) โดยทั่วไปแลวชนิดความสัมพันธแบบเอนนารี นั้นไมเทากับ n ความสัมพันธไบนารี สวน Higher-order relationship นั้น จะอธิบายภายหลังในบทที่ 4

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

3-9

รูปที่ 3.14 แสดงความสัมพันธ ของกลุม ความสัมพันธ (Relationship set) SUPPLY ซึ่ง

เปนแบบเทอนารี

3.4.2 แอทตริบิวตของชนิดความสัมพันธ (Attribute of Relationship type) ชนิดความสัมพันธ (Relationship type) ก็สามารถมีแอทตริบิวต (Attribute) ไดเชนกัน เชน จํานวนชั่วโมงใน การทํางานตอหนึ่งสัปดาห (HoursPerWeek) ซึ่งเปนแอทตริบิวตของชนิดความสัมพันธ WORKS_ON ซึ่งมี คาที่ระบุเปน จํานวนชั่วโมงในการทํางานตอหนึ่งสัปดาหที่พนักงานทําบนโครงการหนึ่งๆ (EMPLOYEE works on a PROJECT)

รูปที่ 3.15 แอทตริบิวตของ ชนิดความสัมพันธ คือ Hours ของ WORKS_ON

3.4.3 เงื่อนไขบังคับเกี่ยวกับความสัมพันธ (Constraints on Relationships) เงื่อนไขบังคับบนชนิดความสัมพันธ (Constraints on Relationship type) หรือที่เรียกกันวา เงื่อนไขบังคับ อัตราสวน (Ratio constraint) ทําไดโดยการกําหนดคา Maximum Cardinality ซึ่งหมายถึง จํานวน ความสัมพันธมากที่สุดที่แตละเอนทิตีสามารถเขารวมได เชน • • •

One-to-one (1:1) One-to-many (1:N) หรือ Many-to-one (N:1) Many-to-many (M:N)

3-10

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

นอกจากนี้ยังมีสามารถกําหนด

Minimum

Cardinality

ซึ่งอาจเรียกวา เงื่อนไขบังคับการเขารวม (Participation constraint) หรือเงื่อนไขบังคับการขึ้นตอกันเชิงปรากฎ (Existence dependency constraints) ซึ่งหมายถึง จํานวนความสัมพันธนอยสุดที่แตละเอนทิตีจะตองเขารวม โดยถากําหนดคาเปน 0 จะ หมายความวาเอนทิตีทุกเอนทิตีไมจําเปนตองเขารวม ซึ่งถือวาไมเปนการขึ้นตอกันเชิงปรากฎ (Existencedependent) แตถากําหนดใหมีคาตั้งแต 1 ขึ้นไปนั้น หมายความวาทุกๆเอนทิตีจะตองเขารวมความสัมพันธ ซึ่ง เรียกวา การขึ้นตอกันเชิงปรากฎ (Existence-dependent)

รูปที่ 3.16 ความสัมพันธแบบ Many-to-one (N:1)

e1 z e2 z e3 z e4 z e5 z e6 z e7 z รูปที่ 3.17 ความสัมพันธแบบ

r9 r 1 r2

p p z 2 p z 3 z 1

r8

Many-to-many

นอกจากนี้ ยังมีชนิดความสัมพันธแบบวนซ้ํา (Recursive relationship type) ซึ่งเชื่อมโยงชนิดเอนทิตี (Entity type) เดียวกันในตางบทบาท เชน ความสัมพันธ SUPERVISION ระหวางพนักงาน (EMPLOYEE) ที่มี บทบาทเปนผูควบคุมหรือเจานาย และพนักงาน (EMPLOYEE) ที่มีบทบาทเปนผูใตบังคับบัญชาหรือลูกนอง ซึ่ง แสดงใหเห็นในรูปตอไปนี้ โดยแทนสัญลักษณ “1” สําหรับบทแรก และ “2” สําหรับบทบาทที่ 2 โดยในกรณีเชนนี้ ในแผนภาพ อีอาร (ER Diagram) จะตองทําการกําหนดชื่อบทบาทเพื่อแยกความแตกตางระหวางเอนทิตีที่ เชื่อมโยงกันดังกลาว

3-11

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

EMPLOYEE e1 z e2 z e3 z e4 z

SUPERVISION

SUPERVISION (Recursive Relationship: SUPERVISION)

1 2

2 1

2 2

รูปที่ 3.18 ความสัมพันธแบบ วนซ้ํา

r1 r2 r

2 1

1

1 1

2 © The Benjamin/Cummings Publishing Company, Inc. 1994, Elmasri/Navathe, Fundamentals of Database Systems, Second Edition

รูปที่ 3.19 ชนิดความสัมพันธ แบบวนซ้ํา SUPERVISION

ที่มีการระบุบทบาท ลงในแผนภาพ เงื่อนไขบังคับเกี่ยวกับโครงสราง (Structural Constraints) นั้น นับเปนทางเดียวในการแสดงความหมายของ ความสัมพันธ โดยเงื่อนไขบังคับดานโครงสรางบนความสัมพันธ (Structural constraints on relationship) จะ ประกอบดวย • Cardinality ratio สําหรับความสัมพันธแบบไบนารี เปนการระบุจํานวนความสัมพันธทั้งหมดที่แตละ เอนทิตีสามารถเขารวมได เชน 1:1, 1:N, N:1 หรือ M:N ซึ่งสามารถแสดงโดยการใสเลขที่เหมาะสม ลงบนเสนเชื่อม • เงื่อนไขบังคับการเขารวม (Participation constraint) บนแตละเอนทิตีที่เขารวม เปนการระบุจํานวน ความสัมพันธนอยสุดที่แตละเอนทิตีจะตองเขารวม ซึ่งสามารถแบงไดเปน 2 ประเภท คือ

3-12

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

แบบทั้งหมด (Total) หรือเรียกวา การขึ้นตอกันเชิงปรากฎ (Existence dependency) ซึ่ง ทุกๆเอนทิตีในชนิดเอนทิตีเดียวกัน จะตองเขารวมความสัมพันธ โดยสามารถแสดง ความสัมพันธชนิดนี้ในแผนภาพ อีอาร ไดโดยการใชเสนเชื่อม 2 เสน - แบบบางสวน (Partial) ซึ่งทุกๆเอนทิตีไมจําเปนตองเขารวมความสัมพันธทั้งหมด โดย สามารถแสดงความสัมพันธชนิดนี้ในแผนภาพ อีอาร ไดโดยการใชเสนเชื่อม 1 เสน หมายเหตุ จะเห็นวา ทั้งหมดนี้เปนการงายสําหรับชนิดความสัมพันธแบบไบนารี (Binary relationship type) -

3.4.4 Alternative notation (min, max) •

• • •

ระบุลงในแตละการเขารวม (Participation) ของชนิดเอนทิตี E ในชนิดความสัมพันธ R โดยระบุวาแต ละเอนทิตี e ใน E จะทําการเขารวมความสัมพันธ R ไดอยางนอยเทากับ min และอยางมากเทากับ max คา Default (ไมมีขอบังคับ) คือ min = 0, max = 1 Must have min?max, min?0, min?1

สามารถอนุมานไดจากความรูเกี่ยวกับขอบังคับของมินิเวิรลด

ตัวอยาง •

•

รูปที่ 3.20 เงื่อนไขบังคับดาน ความสัมพันธ โดย ใชสัญลักษณมาก สุดนอยสุด ((min, max) notation)

แตละแผนกจะมีผูบริหารได 1 คน สวนพนักงานแตละคนสามารถบริหารแผนกไดมากที่สุดเพียงแผนก เดียวเทานั้น - ระบุ (0, 1) สําหรับการเขารวมของ EMPLOYEE บนความสัมพันธ MANAGES - ระบุ (1, 1) สําหรับการเขารวมของ DEPARTMENT บนความสัมพันธ MANAGES พนักงานแตละคนสามารถทํางานใหกับแผนกใดแผนกหนึ่งเทานั้น แตแผนกหนึ่งๆสามารถมีสมาชิก พนักงานเทาใดก็ได - ระบุ (1, 1) สําหรับการเขารวมของ EMPLOYEE บนความสัมพันธ WORKS_FOR - ระบุ (1, n) สําหรับการเขารวมของ DEPARTMENT บนความสัมพันธ WORKS_FOR

(0,1)

(1,1)

(1,1)

(1,N)

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

3-13

รูปที่ 3.21 แผนภาพเคาราง อี อาร COMPANY ที่ ใชสัญลักษณนอย สุดมากสุด ((min, max) notation)

3.5

เอนทิตีชนิดออน (Weak entity type) เอนทิตีชนิดออน (Weak entity type) คือ เอนทิตีที่ไมมีแอทตริบิวตที่เปนคีย (Key attribute) ของตนเอง โดย เอนทิตีชนิดออนจะถูกระบุถึงไดโดยผานชนิดเอนทิตีอื่นๆที่มีคาของแอทตริบิวตเกี่ยวเนื่องกัน ซึ่งเรียกชนิดเอนทิตี ดังกลาวนี้วา เจาของ (Owner) หรือชนิดเอนทิตีระบุ (Identifying entity type) และเรียกความสัมพันธที่ เชื่อมตอระหวางเอนทิตีชนิดออนและชนิดเอนทิตีระบุนี้วา ชนิดความสัมพันธระบุ (Identifying relationship type) โดยเอนทิตีชนิดออนนี้ จะถูกระบุไดโดยใช Partial key ของเอนทิตีชนิดออน หรือผานทางเอนทิตีที่เกี่ยวของ ในชนิดเอนทิตีระบุ (Identifying entity type) ตัวอยาง กําหนดใหเอนทิตีผูเกี่ยวของ (DEPENDENT) ถูกระบุโดย ชื่อของผูเกี่ยวของ วันเกิด และชื่อพนักงานที่เกี่ยวของ ดวย จะไดวา DEPENDENT นี้จัดเปนเอนทิตีชนิดออน (Weak entity type) โดยมี EMPLOYEE เปนชนิด เอนทิตีระบุ (Identifying entity type) และเชื่อมผานความสัมพันธ DEPENDENT_OF ซึ่งเปนความสัมพันธ ระบุ (Identifying relationship type)

รูปที่ 3.22 เอนทิตีชนิดออน (Weak entity type) คือ DEPENDENT

และความสัมพันธระบุ (Identifying relationship) คือ DEPENDENTS_OF

3-14

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

3.6

เครื่องมือสรางแบบจําลองขอมูล (Data Modeling Tools) มีเครื่องมือที่ไดรับความนิยมเปนจํานวนมากที่ครอบคลุมสรางแบบจําลองระดับแนวคิด (Conceptual modeling) และการแปลง (Mapping) เปนรูปแบบเคารางความสัมพันธ (Relational schema design) ซึ่งมีขอดี คือ บริการในลักษณะเอกสารเกี่ยวกับความตองการของแอปพลิเคชัน และมีสวนติดตอผูใชที่เขาใจงายซึ่งมักสนับสนุน รูปแบบกราฟก ปญหาเกี่ยวกับเครื่องมือสําหรับสรางแบบจําลองในปจจุบัน • แผนภาพ (Diagramming) - ใชสัญลักษณที่สื่อความหมายทางแนวคิดไดไมดี - เพื่อหลีกเลี่ยงปญหาในการจัดวางรูปแบบและความสวยงามของแผนภาพ จึงใชกลองและเสน และไมทําอะไรอีกนอกจากแสดงความสัมพันธของคียหลักและคียนอก (Primary-foreign key) ระหวางตาราง • ระเบียบวิธีการ (Methodology) - ไมสนับสนุน methodology แบบ built-in -

Poor tradeoff analysis or user-driven design preferences Poor design verification and suggestions for improvement

COMPANY Embarcadero Technologies

รูปที่ 3.23 เครื่องมือออกแบบ ฐานขอมูลอัตโนมัติ ที่มีในปจจุบัน

TOOL

FUNCTIONALITY

ER Studio

Database Modeling in ER and IDEF1X

DB Artisan

Database administration and space and security management

Oracle

Developer 2000 and Designer 2000

Database modeling, application development

Popkin Software

System Architect 2001

Data modeling, object modeling, process modeling, structured analysis/design

Platinum Technology

Platinum Enterprice Modeling Suite: Erwin, BPWin, Paradigm Plus

Data, process, and business component modeling

Persistence Inc.

Pwertier

Mapping from O-O to relational model

Rational

Rational Rose

Modeling in UML and application generation in C++ and JAVA

Rogue Ware

RW Metro

Mapping from O-O to relational model

Resolution Ltd.

Xcase

Conceptual modeling up to code maintenance

Sybase

Enterprise Application Suite

Data modeling, business logic modeling

Visio

Visio Enterprise

Data modeling, design and reengineering Visual Basic and Visual C++

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

3-15

รูปที่ 3.24 แผนภาพ อีอาร (ER Diagram)

สําหรับฐานขอมูล BANK

3.7

ปญหาเกี่ยวกับสัญกรณอีอาร (ER notation) แบบจําลอง อีอาร ในรูปแบบแรกเริ่มไมสนับสนุนการทํา Specialization/Generalization abstraction

3.8

แบบจําลอง Extended Entity-Relationship (EER) • • •

รูปที่ 3.25 เคารางระดับ แนวคิด (Conceptual schema) ของ COMPANY ใน

รูปแบบแผนภาพ UML

เพิ่ม Set-subset relationships เพิ่ม Specialization/Generalization Hierarchies ในบทถัดไปจะเปนการนําเสนอวาแบบจําลอง อีอาร สามารถขยายความสามารถในดานตางๆ เชน Setsubset relationships และ Specialization/Generalization Hierarchies ไดอยางไร รวมถึงการ สรางแผนภาพ EER (EER Diagram)

2110422 การออกแบบระบบการจัดการฐานขอมูล ภาควิชาวิศวกรรมคอมพิวเตอร คณะวิศวกรรมศาสตร จุฬาลงกรณมหาวิทยาลัย

3-16

แบบฝกหัด 1. 2.

จงอธิบายความแตกตางระหวาง Attribute และ Value set จงอธิบายความสัมพันธแบบวนซ้ํา(Recursive relationship type) พรอมยกตัวอยางของ ความสัมพันธแบบวนซ้ํา 3. ใหพิจารณาแผนภาพ อีอาร ของฐานขอมูล BANK ในรูปที่ 3.24 เพื่อตอบคําถาม • แสดงชื่อของเอนทิตี (entity type) • แสดงชื่อของเอนทิตีชนิดออน (Weak entity type) เอนทิตีระบุ (Identifying entity type) ความสัมพันธระบุ (Identifying relationship type) และ Partial key • ถากําหนดใหลูกคา (CUSTOMER) จะมีบัญชีเงินกู(LOAN)หรือไมก็ไดแตถามีแตละคนจะมีไดไม เกิน 2 บัญชี และบัญชีเงินกูแตละบัญชีจะตองมีชื่อลูกคาอยางนอยหนึ่งคน ใหแสดง (min,max) constraintของความสัมพันธ L-C