chapter03 data modeling using entity-relationship (er) model

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

บทที่ 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]


รูปที่ 3.1 แผนภาพอยางงาย

แสดงเฟสหลักใน

การออกแบบ

ฐานขอมูล 3.2 ตัวอยางแอปพลิเคชันฐานขอมูล “COMPANY”

เพื่อแสดงตัวอยางในการออกแบบฐานขอมูล เราจะใชตัวอยางของฐานขอมูล “COMPANY” โดยจะเรื่มดูตั้งแตความตองการของบริษัท ซ่ึงเราสามารถแยกแยะความตองการและขอกําหนดไดดังน้ี

• บริษัทจัดระบบเปนแผนก (Department) โดยแตละแผนกจะมีชื่อ (Name) ที่ไมซํ้ากัน มีเลขที่แผนก

(Number) ที่ไมซํ้ากัน และมีพนักงานหนึ่งคนที่เปนผูจัดการ (Manager) ของแผนกนั้น ซ่ึงเราจะทํา

การเก็บวันที่ที่พนักงานผูน้ันเริ่มทํางานเปนผูจัดการของแผนกนั้น โดยแตละแผนกอาจมีที่ทําการหรือ

สํานักงานไดหลายแหง (Location) • แตละแผนกจะทําการควบคุมดูแล (Control) โครงการ (Project) จํานวนหนึ่ง ซ่ึงแตละโครงการ จะ

ประกอบดวย ชื่อโครงการและเลขที่โครงการที่ไมซํ้ากัน และแตละโครงการ location จะขึ้นอยูกับที่ทําการ (Location) เพียงแหงเดียวเทาน้ัน

• เราจะจัดเก็บขอมูลพนักงาน (Employee) ซ่ึงประกอบดวย ชื่อ รหัสประจําตัว ที่อยู เงินเดือน เพศ และ

วันเกิด โดยพนักงานแตละคนสามารถทํางาน (Work) ใหกับแผนกหนึ่งแผนกใดเทาน้ัน แตอาจทําหลาย

โครงการได โดยเราตองการจะติดตามชั่วโมงการทํางานของพนักงานแตละคน แตละโครงการ

นอกเหนือจากนั้น เรายังตองการติดตามขอมูลผูควบคมุดูแล (Direct Supervisor) ของพนักงานแตละคนอีกดวย


• นอกจากนี้ยังมีการเก็บขอมูลบุตรหรือผูอยูในอุปการะ (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) เปนตน


รูปที่ 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) เชน อายุ


• คาวาง (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


• Value set หรือโดเมน (Domain) ของแอทตริบิวต แอทตริบิวตแตละแอทตริบิวตของชนิดเอนทิตี (Entity type) จะเกี่ยวของกับ value set หน่ึงๆ (หรือ

โดเมนของ value) ซ่ึงหมายถึงชนิดขอมูลพื้นฐานที่มีใหในภาษาโปรแกรมทั่วไป เชน จํานวนเต็ม

(Integer) ขอความ (String) แบบตรรก (Boolean) จํานวนจริง (Float) แบบแจงนับ (Enumerate type) แบบยอย (Subrange) เปนตน

รูปที่ 3.8 การออกแบบขั้นตน

ของชนิดเอนทิตี

(Entity type)

รูปที่ 3.9 สรุปสัญลักษณของ

แผนภาพ อีอาร สําหรับเคาราง อี

อาร (ER Schema)


รูปที่ 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


รูปที่ 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


รูปที่ 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)


นอกจากนี้ยังมีสามารถกําหนด Minimum Cardinality ซ่ึงอาจเรียกวา เง่ือนไขบังคับการเขารวม

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

หมายความวาเอนทิตีทุกเอนทิตีไมจําเปนตองเขารวม ซ่ึงถือวาไมเปนการขึ้นตอกันเชิงปรากฎ (Existence-dependent) แตถากําหนดใหมีคาตั้งแต 1 ขึ้นไปนั้น หมายความวาทุกๆเอนทิตีจะตองเขารวมความสัมพันธ ซ่ึง

เรียกวา การขึ้นตอกันเชิงปรากฎ (Existence-dependent)

รูปที่ 3.16 ความสัมพันธแบบ

Many-to-one (N:1)


Many-to-many

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

ในแผนภาพ อีอาร (ER Diagram) จะตองทําการกําหนดชื่อบทบาทเพื่อแยกความแตกตางระหวางเอนทิตีที่

เชื่อมโยงกันดังกลาว

e1 e2 e3 e4 e5 e6 e7

r1 r2 p1

p2 p3

r8

r9



วนซ้ํา

SUPERVISION (Recursive

Relationship: SUPERVISION)

รูปที่ 3.19 ชนิดความสัมพันธ

แบบวนซ้ํา

SUPERVISION ที่มีการระบุบทบาท

ลงในแผนภาพ

เง่ือนไขบังคับเก่ียวกับโครงสราง (Structural Constraints) น้ัน นับเปนทางเดียวในการแสดงความหมายของ

ความสัมพันธ โดยเงื่อนไขบังคับดานโครงสรางบนความสัมพันธ (Structural constraints on relationship) จะประกอบดวย

• Cardinality ratio สําหรับความสัมพันธแบบไบนารี เปนการระบุจํานวนความสัมพันธทั้งหมดที่แตละเอนทิตีสามารถเขารวมได เชน 1:1, 1:N, N:1 หรือ M:N ซ่ึงสามารถแสดงโดยการใสเลขที่เหมาะสมลงบนเสนเชื่อม

• เง่ือนไขบังคับการเขารวม (Participation constraint) บนแตละเอนทิตีที่เขารวม เปนการระบุจํานวนความสัมพันธนอยสุดที่แตละเอนทิตีจะตองเขารวม ซ่ึงสามารถแบงไดเปน 2 ประเภท คือ

e1 e2 e3 e4

EMPLOYEE

r1 r2 r

SUPERVISION

2 1

1 2

2 1

1

1 2

1

2

2

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


- แบบทั้งหมด (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 • สามารถอนุมานไดจากความรูเก่ียวกับขอบังคับของมินิเวิรลด

ตัวอยาง • แตละแผนกจะมีผูบริหารได 1 คน สวนพนักงานแตละคนสามารถบริหารแผนกไดมากท่ีสุดเพียงแผนก

เดียวเทาน้ัน - ระบุ (0, 1) สําหรับการเขารวมของ EMPLOYEE บนความสัมพันธ MANAGES - ระบุ (1, 1) สําหรับการเขารวมของ DEPARTMENT บนความสัมพันธ MANAGES

• พนักงานแตละคนสามารถทํางานใหกับแผนกใดแผนกหนึ่งเทาน้ัน แตแผนกหนึ่งๆสามารถมีสมาชิก

พนักงานเทาใดก็ได - ระบุ (1, 1) สําหรับการเขารวมของ EMPLOYEE บนความสัมพันธ WORKS_FOR - ระบุ (1, n) สําหรับการเขารวมของ DEPARTMENT บนความสัมพันธ WORKS_FOR

รูปที่ 3.20 เง่ือนไขบังคับดาน

ความสัมพันธ โดย

ใชสัญลักษณมาก

สุดนอยสุด ((min, max) notation)

(1,1) (0,1)

(1,N) (1,1)


รูปที่ 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.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

รูปที่ 3.23 เครื่องมือออกแบบ

ฐานขอมูลอัตโนมัติ

ที่มีในปจจุบัน

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

Visio Enterprise Visio

Data modeling, business logic modeling Enterprise Application SuiteSybase

Conceptual modeling up to code maintenance Xcase Resolution Ltd.

Mapping from O-O to relational model RW Metro Rogue Ware

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

Rational Rose Rational

Mapping from O-O to relational model Pwertier Persistence Inc.

Data, process, and business component modeling Platinum Enterprice Modeling Suite: Erwin, BPWin, Paradigm Plus

Platinum Technology

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

System Architect 2001 Popkin Software

Database modeling, application development Developer 2000 and Designer 2000

Oracle

Database administration and space and security management

DB Artisan

Database Modeling in ER and IDEF1X ER Studio Embarcadero Technologies

FUNCTIONALITY TOOL COMPANY


รูปที่ 3.24 แผนภาพ อีอาร

(ER Diagram) สําหรับฐานขอมูล

BANK 3.7 ปญหาเกี่ยวกับสัญกรณอีอาร (ER notation)

แบบจําลอง อีอาร ในรูปแบบแรกเริ่มไมสนับสนุนการทํา Specialization/Generalization abstraction

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

• เพิ่ม Set-subset relationships • เพิ่ม Specialization/Generalization Hierarchies • ในบทถัดไปจะเปนการนําเสนอวาแบบจําลอง อีอาร สามารถขยายความสามารถในดานตางๆ เชน Set-

subset relationships และ Specialization/Generalization Hierarchies ไดอยางไร รวมถึงการสรางแผนภาพ EER (EER Diagram)

รูปที่ 3.25 เคารางระดับ

แนวคิด

(Conceptual schema) ของ

COMPANY ในรูปแบบแผนภาพ

UML


แบบฝกหัด 1. จงอธิบายความแตกตางระหวาง Attribute และ Value set 2. จงอธิบายความสัมพันธแบบวนซ้ํา(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

chapter03 data modeling using entity-relationship (er) model

Documents

Transcript of chapter03 data modeling using entity-relationship (er) model