Data Modeling Using the Entity-Relationship Model

งานนำเสนอเรื่อง: "Data Modeling Using the Entity-Relationship Model"— ใบสำเนางานนำเสนอ:

1 Data Modeling Using the Entity-Relationship Model

2 เนื้อหา การออกแบบฐานข้อมูล Entity-Relationship Model
หลักการของอีอาร์โมเดล กรณีตัวอย่าง การทำแผนภาพอีอาร์

3 Phases of Database Design
Requirements Collection and Analysis Phases of Database Design Functional Requirements Data Requirements FUNCTIONAL ANALYSIS CONCEPTUAL DESIGN Conceptual Schema (in a high-level data model) High-level Transaction Specification LOGICAL DESIGN (DATA MODEL MAPPING) Logical (Conceptual) Schema (In the data model of a specific DBMS) APPLICATION PROGRAM DESIGN First step shown is requirements collection and analysis. This step, the database designers interview user to user stand and document their requirements. The results is set of user requirements. The requirement have be collected and analyzes, the next step is to create a conceptual schema for the database, using a high level conceptual schema for the database. The conceptual schema is a description of the data requirements of the users and includes detailed description of the entity types, relationships and constraints. Present by using high level data model. Because concepts do not include do not include implementation details, they are usually easier to understand and can be used to communicate with user. The next step is actual implementation of the database, using a commercial DBMS. Most commercial DBMS use an implementation Data Model such as relation model or the object-relational database model. This step is transformed from the high-level data model into the implementation data model. The last step is the physical design phase. During which the internal storage structures, indexes, access paths, and file organizations for the database files are specified. PHYSICAL DESIGN TRANSACTION IMPLEMENTATION Internal Schema Application Program

4 Phases of Database Design
Requirements Collection and Analysis Phases of Database Design The next step is to create a conceptual schema for the database, using a high level conceptual schema for the database. The conceptual schema is a description of the data requirements of the users and includes detailed description of the entity types, relationships and constraints, present by using high level data model. Because concepts do not include do not include implementation details, they are usually easier to understand and can be used to communicate with user. Data Requirements Functional Requirements FUNCTIONAL ANALYSIS High-level Transaction Specification APPLICATION PROGRAM DESIGN TRANSACTION IMPLEMENTATION Application Program CONCEPTUAL DESIGN The last step is the physical design phase. During which the internal storage structures, indexes, access paths, and file organizations for the database files are specified. First step shown is requirements collection and analysis. This step, the database designers interview user to understand and document their requirements. The next step is actual implementation of the database, using a commercial DBMS. Most commercial DBMS use an implementation Data Model such as relation model or the object-relational database model. This step is transformed from the high-level data model into the implementation data model. Conceptual Schema (in a high-level data model) LOGICAL DESIGN (DATA MODEL MAPPING) Logical (Conceptual) Schema (In the data model of a specific DBMS) First step shown is requirements collection and analysis. This step, the database designers interview user to user stand and document their requirements. The results is set of user requirements. The requirement have be collected and analyzes, the next step is to create a conceptual schema for the database, using a high level conceptual schema for the database. The conceptual schema is a description of the data requirements of the users and includes detailed description of the entity types, relationships and constraints. Present by using high level data model. Because concepts do not include do not include implementation details, they are usually easier to understand and can be used to communicate with user. The next step is actual implementation of the database, using a commercial DBMS. Most commercial DBMS use an implementation Data Model such as relation model or the object-relational database model. This step is transformed from the high-level data model into the implementation data model. The last step is the physical design phase. During which the internal storage structures, indexes, access paths, and file organizations for the database files are specified. PHYSICAL DESIGN Internal Schema

5 Entity Relationship Data Model
ER-Model describes data as Entities Attributes Relationships

6 Entities และ Attributes
Entity คือ วัตถุสิ่งของหรือนามธรรมที่เราสนใจ Entity อาจเป็นออปเจกที่จับต้องได้ (object with a physical existence) เช่น person, car , house, employee Entity อาจเป็นออปเจกเชิงหลักการ (object with a conceptual existence) เช่น job, a university course.

7 Attributes Attribute คือ คุณสมบัติเฉพาะที่ใช้อธิบายเอนติตี หรือ เป็นคุณสมบัติของเอนติตีแต่ละตัวนั่นเอง ค่าของแอตตริบิว (attribute values) ที่อธิบายแต่ละเอนติตีคือข้อมูลทีถูกเก็บในฐานข้อมูลต่อไป ตัวอย่าง เอนติตี Employee มีคุณสมบัติดังต่อไปนี้ ชื่อพนักงาน (Name), อายุ (Age), ที่อยู่ (address), เงินเดือน (salary) และตำแหน่งงาน (job)

8 Attribute & Attribute Value
Student Name Faculty Major ID Kamonphon Science IT PiyathiDa Science Comp SC. Attribute Value

9 แต่ละเอนติตีมีชื่อเรียก (ชื่อที่ตั้งควรสื่อถึงสิ่งที่กล่าวถึงด้วย)
แต่ละเอนติตีประกอบด้วยแอตตริบิว (บอกคุณสมบัติ) เอนติตีแต่ละรายการก็มีค่าที่ปรากฏในแต่ละแอตตริบิวของมัน ค่าของแอตตริบิวที่อธิบายแต่ละเอนติตีคือข้อมูลทีถูกเก็บในฐานข้อมูลต่อไป.

10 Attribute Type Composite Attributes Single-Valued Multi Valued
Atomic Attribute Composite Attributes Single-Valued Multi Valued Stored Attribute Derived Attribute

11 Atomic Attribute Atomic Attribute คือแอตตริบิวที่ไม่สามารถแยกย่อยออกไปได้อีก เรียกว่า Atomic หรือ Simple Attributes. ตัวอย่างเช่น Student Atomic Simple First Name Last Name Age

12 Composite Attributes Composite Attributes สามารถที่จะแบ่งออกเป็นส่วนของแอตตริบิวย่อย ที่มีความหมายที่เป็นอิสระต่อกันได้ Composite Attribute Address Street Address Tambol District Province ZipCode Composite Attribute? Atomic Attribute

13 Single-Valued VS Multi Valued Attributes
Multi Value Attribute: มีค่าได้หลายค่า

14 Example Attribute Age Attribute Value Degree B : 27 Years
A : B.Sc. B : B.Sc, M.Sc., Dr. Eng. Age A : 24 Years B : 27 Years Attribute Value

15 Stored VS Derived Attributed
Stored Attribute Derived Attribute: คือค่าของแอตตริบิวดังกล่าวสามารถกำหนดหรือคำนวณจากแอตตริบิวอื่นๆ หรือ เอนติตีอื่นๆ ที่มีความเกี่ยวข้องกันได้

16 Example Attribute Age Attribute Value Birth Day B : 40 Years
A : 13 July 1980 B : 23 Dec 1964 Age A : 24 Years B : 40 Years Stored Attribute Attribute Value Derived Attribute

17 คุณสมบัติของคีย์แอตตริบิว
Key Attribute Key Attribute คือแอตตริบิว (หรือกลุ่มของแอตตริบิว) ที่ค่าของมันสามารถใช้แยกความแตกต่างของเอนติตีแต่ละตัวในเอนติตีเซตได้ หรือกล่าวได้ว่าเป็นแอตตริบิวที่ใช้เป็นตัวแทนของแต่ละเอนติตีในเอนติตีเช็ค คุณสมบัติของคีย์แอตตริบิว Unique Not Null

18 สำหรับบางกรณีเอนติตีบางตัวอาจไม่มีค่าปรากฏในบางแอตตริบิว
Null Value สำหรับบางกรณีเอนติตีบางตัวอาจไม่มีค่าปรากฏในบางแอตตริบิว ยกตัวอย่างเช่น Degree attribute จะปรากฏค่าเฉพาะสำหรับคนที่สำเร็จการศึกษาในระดับวิทยาลัย/มหาวิทยาลัย ในสถานการณ์ดังกล่าวค่าของ Degree attribute จะมีค่าพิเศษเรียกว่าค่า null

19 Entity Type Strong Entity Type Weak Entity Type
คือเอนติตีที่มีคีย์แอตตริบิวของตนเอง (Entity that do have a key attribute) Weak Entity Type คือเอนติตีที่ไม่มีคีย์แอตตริบิวของตนเอง เป็นเอนติตีที่ขึ้นกับเอนติตีอื่น(Depend on other entities) เอนติตีที่ถูกขึ้นตรงจะเรียกว่า owner entity ความสัมพันธ์ระหว่าง Owner กับ Weak entities ถูกเรียกว่า “identifying relationship”

20 Example Entity Employee Department Project Dependent

21 Entity Type, Entity Sets, Keys, Value Set
Entity set ปกติใช้ชื่อเดียวกันกับเอนติ entity type.

22 Key attribute of Entity type
Key or Uniqueness constraint แอตตริบิวที่ค่าของมันสามารถใช้ในการแยกความแตกต่างสำหรับแต่ละเอนติตีในเอนติตีเช็คได้

23 Relationship เป็นความสัมพันธ์ระหว่างเอนติตี

24 Relationship Type Relationship type R ระหว่าง n entity types E1,E2,…,En บอกกลุ่มความสัมพันธ์ (association or relationship) ระหว่าง entities Mathematically, the relationship set R คือเซตของความสัมพันธ์ ri, โดยที่แต่ละ ri สัมพันธ์กับ n individual entities (e1,e2,…, en) และแต่ละเอนติตี ej ใน ri คือสมาชิกของแต่ละเอนติตีEj, 1 ≤ j ≤ n.

25 Relationship Degree Degree ของ relationship type คือจำนวนของเอนติตีเช็ค ที่เกิดความสัมพันธ์กัน For example - Degree ของความสัมพันธ์ระหว่างอาจารย์และนักศึกษาจะมี ค่าเท่ากับ สอง - Degree ที่มีค่าเท่ากับสองเรียกว่า binary สาม คือ ternary ตามลำดับ

26 Constraint on Relationship Types
Two main Type of relationship constraints Cardinality ratio Participation

27 Cardinality Ratios Cardinality ratio กำหนดค่ามากสุดของสมาชิกของความสัมพันธ์ที่เอนติตีเข้าไปมีส่วนเกี่ยวข้อง 1 to 1 Relationship (1:1) 1 to many relationship (1:N) Many to Many relationship (N:M)

28 1:1 Relationship R1 R2 R3 R4 T1 T2 T3 T4 T5 T6 T7 D1 D2 D3 D4
Entity E2 Entity T Relationship

29 1:1 Relationship Head Apisak Pusadee Pramot Somjit Pattana Kriat
Sartra CompSc Stat Physics Math Entity E2 Entity T Relationship

30 1 to Many Relationship R1 R2 R3 R4 E1 E2 E3 E4 E5 E6 E7 D1 D2 D3 D4
Entity D Entity E Relationship

31 1:1 Relationship work Work Apisak Pusadee Somjit Pramot Pattana
Tasanee Jirasuk CompSc Stat Physics Math Entity E2 Entity T Relationship

32 Many to Many Relationship
Entity E J1 J2 J3 J4 Entity J Relationship

33 Many to Many Relationship
Aim Daw Dam Aun Nuu Nam F Student Project File&DB English Cal Subject Register

34 Participation Constraints and Existence Dependencies
เป็นการระบุว่าสมาชิกเอนติตีในเอนติตีเซ็ตขึ้นกับเอนติตีอื่นโดยผ่านทางความสัมพันธ์ มันจะระบุจำนวนที่น้อยที่สุดของสมาชิกในเอนติตีที่มีความสัมพันธ์หรือที่เกี่ยวข้องไว้ ซึ่งเราเรียกว่า minimum cardinality constraint.

35 Participation type Partial participation Total participation
(existence dependency)

36 Total participation สังกัด R1 R2 R3 R4 E1 E2 E3 E4 E5 E6 E7 D1 D2 D3
Entity แผนก Entity พนักงาน Relationship สังกัด

37 Partial participation
D1 D2 D3 D4 E1 E2 E3 E4 E5 E6 E7 Entity E Entity D Relationship

38 Symbol Entity Weak Entity Relationship

39 Weak Entity Attribute Key Attribute Composite Attribute Derived Attribute

40 partial Total E1 E2 R E1 E2 R 1 N Cardinality Ratio

41 ER-Diagram

42 Another ER-Diagram

43 UML Class diagram