Data Modeling Using the Entity-Relationship Model

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

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

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

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

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

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

Attribute & Attribute Value Student Name Faculty Major ID 475020126-3 Kamonphon Science IT 465020100-0 PiyathiDa Science Comp SC. Attribute Value

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

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

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

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

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

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

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

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

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

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

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”

Example Entity Employee Department Project Dependent

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

Participation type Partial participation Total participation (existence dependency)

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

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

Symbol Entity Weak Entity Relationship

Weak Entity Attribute Key Attribute Composite Attribute Derived Attribute

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

ER-Diagram

Another ER-Diagram

UML Class diagram