งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

งานนำเสนอกำลังจะดาวน์โหลด โปรดรอ

ส่วนที่ 4 System Design การออกแบบระบบ.

งานนำเสนอที่คล้ายกัน


งานนำเสนอเรื่อง: "ส่วนที่ 4 System Design การออกแบบระบบ."— ใบสำเนางานนำเสนอ:

1 ส่วนที่ 4 System Design การออกแบบระบบ

2 Chapter 12 Database Design การออกแบบฐานข้อมูล

3 System Development Life Cycle : SDLC
กิจกรรมในขั้นตอนนี้ได้แก่ 1. การออกแบบฟอร์มและรายงาน 2. การออกแบบ GUI 3. การออกแบบฐานข้อมูล 12.2

4 Learning Objectives เพื่อให้ผู้เรียนสามารถเข้าใจและอธิบายต้นแบบของฐานข้อมูลได้ เข้าใจและสามารถปรับปรุงโครงสร้างข้อมูลของฐานข้อมูลโดยการทำ Normalization ได้ สามารถอธิบายการออกแบบฐานข้อมูล Database Design 12.3

5 Topics การออกแบบฐานข้อมูล ฐานข้อมูลเชิงสัมพันธ์
การออกแบบฐานข้อมูลระดับตรรกะ Normalization 12.4

6 การออกแบบฐานข้อมูล ขั้นตอนการออกแบบฐานข้อมูล แบ่งออกเป็น 3 ระดับ คือ
Conceptual Design Logical Design Physical Design 12.5

7 การออกแบบฐานข้อมูล Conceptual Design : การอธิบายถึงข้อมูลและความสัมพันธ์กันของข้อมูลในระบบที่เราวิเคราะห์มา โดยกำหนดว่าจากความต้องการของผู้ใช้ จะต้องมีข้อมูลอะไรบ้าง และข้อมูลแต่ละตัวมีความสัมพันธ์กันอย่างไร และมีข้อจำกัดอะไรบ้าง แสดงโดยใช้ High-Level Conceptual Data Model ในที่นี้เราใช้ E-R Model Logical Design : จากโครงสร้างของฐานข้อมูลที่ได้จากการออกแบบฐานข้อมูลในระดับ Conceptual แล้วนำโครงสร้างนั้นมาอิงกับ Data Model เพื่อแปลงเป็นตาราง (Relational Data Model) หรือความสัมพันธ์ตามแนวคิดของ Data Model จากนั้นต้องมีการปรับปรุงโครงสร้างของฐานข้อมูลให้มีความซ้ำซ้อนกันน้อยที่สุด โดยใช้ทฤษฎีการทำ Normalization Physical Design : จากนั้นเป็นขั้นตอนการ Implement โดยนำ DBMS มาใช้ Implement ผลลัพธ์ที่ได้ คือ Database Schema และขั้นตอนสุดท้าย คือการออกแบบการจัดเก็บข้อมูลลงใน Disk เป็นเรื่องของ Internal Storage Structure การเข้าถึงข้อมูลจะทำอย่างไร 12.6

8 ตัวอย่างฐานข้อมูลเชิงสัมพันธ์
12.7

9 แบบจำลองข้อมูลเชิงสัมพันธ์ (Relational Database Model)
คือ แบบจำลองที่นำเสนอโครงสร้างของข้อมูลที่อยู่ในฐานข้อมูลเชิงสัมพันธ์ โดยเสนอในรูปแบบตาราง (Table) หรือ Relations Relations คือ ตาราง 2 มิติที่ใช้บรรจุข้อมูล โดยแต่ละ Relations จะ ประกอบด้วยชุดของแถว (Row) เรียกว่า “Tuple”และ คอลัมน์ (Column) เรียกว่า “Field” หรือ “Attribute” 12.8

10 EMPLOYEE(Emp_ID,Emp_Sex,Emp_Name,Emp_Dep,Salary)
แบบจำลองข้อมูลเชิงสัมพันธ์ (Relational Database Model) Emp_ID Emp_Name Emp_Sex Emp_Dep Salary 110 วิลาวัลย์ ขำคม F โปรแกรมเมอร์ 15,000 112 อุษาวดี เจริญกุล 15,100 091 นพพร บุญชู M การตลาด 12,000 010 กษมา ร่มเย็น 11,000 001 วนิดา แซ่ลี้ 12,500 EMPLOYEE(Emp_ID,Emp_Sex,Emp_Name,Emp_Dep,Salary) 12.9

11 คุณสมบัติของ Relation
1. ข้อมูลที่อยู่ใน Attribute 1 Attribute และ Row 1 Row จะต้องมี คุณสมบัติ Atomic คือมีค่าเพียงค่าเดียวเท่านั้น หรือเรียกว่า “Single- Valued” 2. ข้อมูลที่อยู่ใน Attribute เดียวกันจะต้องอยู่ภายในขอบเขตของค่าที่ เป็นไปได้ (Domain) เดียวกัน 3. ข้อมูลในแต่ละแถว (Tuple) จะต้องมีค่าไม่ซ้ำกันเลย เช่น กรณีที่ใน แผนกงานหนึ่ง มีพนักงานชื่อและนามสกุลเดียวกัน 2 คน ในการเก็บข้อมูล ของพนักงานทั้งสองจะต้องไม่มีค่าซ้ำกันดังตัวอย่าง 12.10

12 คุณสมบัติของ Relation
Emp_ID Emp_Name Emp_Sex Emp_Dep Salary 110 วิลาวัลย์ ขำคม F โปรแกรมเมอร์ 15,000 111 112 อุษาวดี เจริญกุล 15,100 091 นพพร บุญชู M การตลาด 12,000 010 กษมา ร่มเย็น 11,000 001 วนิดา แซ่ลี้ 12,500 มี Emp_ID ทำให้ไม่ซ้ำกัน 12.11

13 คุณสมบัติของ Relation
4. ลำดับการจัดเรียงของ Attributes จากซ้ายไปขวา ไม่จำเป็นต้องมีการ เรียงลำดับ 5. ลำดับของข้อมูลแต่ละแถวจากบนลงล่าง ไม่จำเป็นต้องมีการเรียงลำดับ 12.12

14 คุณสมบัติของ Relation
Emp_ID Emp_Name Emp_Sex Emp_Dep Salary 110 วิลาวัลย์ ขำคม F โปรแกรมเมอร์ 15,000 112 อุษาวดี เจริญกุล 15,100 M นพพร บุญชู 002 การตลาด ฝ่ายขาย 18,000 010 กษมา ร่มเย็น 11,000 001 วนิดา แซ่ลี้ 12,500 1 2 2 12.13

15 คุณสมบัติของ Relation
Emp_ID Emp_Name Emp_Sex Emp_Dep Salary 110 วิลาวัลย์ ขำคม F โปรแกรมเมอร์ 15,000 111 112 อุษาวดี เจริญกุล 15,100 091 นพพร บุญชู M การตลาด 12,000 010 กษมา ร่มเย็น 11,000 001 วนิดา แซ่ลี้ 12,500 4,5 12.14

16 Integrity Rule สามารถแบ่งเป็น 2 ส่วน ดังนี้
Entity Integrity Rule เป็นกฏเกณฑ์เพื่อควบคุมความถูกต้องของ Entity ซึ่งจะต้องมีลักษณะจำแนกความแตกต่างหรืออ้างถึงสมาชิกได้ และจะต้องไม่เป็นค่าว่าง “Primary Key” Referential Integrity Rule เป็นกฏเกณฑ์ที่ใช้รักษาความสัมพันธ์ของข้อมูล และใช้ในการอ้างถึงข้อมูลระหว่าง Table “Foreign Key” 12.15

17 การปรับเปลี่ยนโครงสร้างของข้อมูลให้อยู่ในระดับตรรกะ
ในการปรับเปลี่ยนโครงสร้างของข้อมูลให้อยู่ในระดับตรรกะมีดังนี้ การกำจัด Composite Attribute การกำจัด Multi-valued Attribute การกำจัด External Identifier 12.16

18 การกำจัด Composite Attribute
วิธีที่ 1 แยก Composite Attribute ออกเป็น Attribute ย่อย PERSON Name Age Sex Address Street City State 12.17

19 การกำจัด Composite Attribute
วิธีที่ 2 ยุบ Composite Attribute ให้เหลือเพียง Attribute เดียว PERSON Name Age Sex Address Street City State 12.18

20 การกำจัด Multivalued Attribute
กรณีกำจัด Multi-valued Attribute ของ Entity จะมีขั้นตอนดังนี้ แปลง Multi-valued Attribute ของ Entity ไปเป็น Entity ใหม่โดยที่ Entity ใหม่นี้จะประกอบไปด้วย Attribute ที่ได้มาจาก Multi-valued Attribute และ Identifier ของ Entity เดิม รวมทุก Attribute ของ Entity ใหม่เป็น Identifier ของ Entity ใหม่ 12.19

21 การกำจัด Multi-valued Attribute
กรณีกำจัด Multi-valued Attribute ของ Relationship จะมีขั้นตอนดังนี้ แปลง Multi-valued Attribute ของ Relationshipไปเป็น Entity ใหม่ โดยที่ Entity ใหม่นี้จะประกอบด้วย Attribute ที่ได้มาจาก Multi-valued Attribute และ Identifier ของ Entity ที่มีความสัมพันธ์กับ Relationship นั้น สำหรับการเลือก Identifier มาเป็น Attribute ของ Entity ใหม่จะมีหลักการดังนี้ ถ้าเป็น One-to-One Relationship ให้เลือก Identifier จาก Entity ใดก็ได้ที่มีความสัมพันธ์กับ Relationship นั้นมาเป็น Attribute ของ Entity ใหม่ ถ้าเป็น One-to-Many Relationship ให้เลือก Identifier จาก Entity ทางด้าน Many ที่มีความสัมพันธ์กับ Relationship นั้นมาเป็น Attribute ของ Entity ใหม่ ถ้าเป็น Many-to-Many Relationship ให้เลือก Identifier จากทั้ง 2 Entityที่มีความสัมพันธ์กับ Relationship นั้นมาเป็น Attribute ของ Entity ใหม่ รวมทุก Attribute ของ Entity ใหม่เป็น Identifier ของ Entity ใหม่ 12.20

22 การกำจัด Multi-valued Attribute
Material_Code Description Product_Code Price PRODUCT Material_Code Product_Code PRODUCT_MATERIAL 12.21

23 การกำจัด External Identifier
เนื่องจาก Relational Model จะไม่ปรากฏ Identifier แบบ External Identifierดังนั้นจึงต้องแปลง External Identifier ให้อยู่ในรูป Internal Identifier โดยมีขั้นตอนดังนี้ แปลง External Identifier ไปเป็น Attribute ใหม่ของ Weak โดย Attribute ใหม่นี้จะทำหน้าที่เป็น Identifier ร่วมกับ Identifier เดิมของ Weak Entity ตัด Relationship ระหว่าง Strong Entity และ Weak Entity ทิ้ง 12.22

24 การกำจัด External Identifier
ของ Entity Student U_Name University-Code City University ENROLL STUDENT Student_No Age STD_Name 12.23

25 การกำจัด External Identifier
University University-Code U_Name City STD_Name Student_No Age STUDENT 12.24

26 Relation-Name(A1,A2,A3,…,An)
Relational Schema Relational Schema เป็นรูปแบบที่ใช้แสดงถึงโครงสร้างของแต่ละ Entity ใน Relational Model ซึ่งประกอบขึ้นจากเซตของ Attribute ภายใต้ Relation นั้น โดยมีรูปแบบ ดังนี้ Relation-Name(A1,A2,A3,…,An) โดยที่ Relation-Name หมายถึง ชื่อของ Relation A1,A2,….,An หมายถึง รายชื่อ Attribute ภายใต้ Relation นั้น เมื่อนำแต่ละ Relation มาประกอบกันจะปรากฏเป็นโครงสร้างทั้งหมดของฐานข้อมูล เรียกว่า Relational Database Schema 12.25

27 EMPLOYEE(Emp-No,Emp-Name,Sex,Age)
การแปลง Entity ไปเป็น Relation Emp_Name EMPLOYEE Emp-No Sex Age EMPLOYEE(Emp-No,Emp-Name,Sex,Age) 12.26

28 การแปลง Relationship ไปเป็น Relation
ในการแปลง Relationship ไปเป็น Relation นั้นจะแปลงตาม Cardinality ของ Relationship ได้ดังนี้ กรณีที่เป็น One-to-One Relationship ในการแปลงสามารถทำได้ 2 กรณี ดังนี้ กรณีที่ 1 Entity มีความสัมพันธ์กับแบบ Total Participation คือ สมาชิกทุก ตัวใน Entity หนึ่งมีความสัมพันธ์กับอีก Entity หนึ่ง อย่างน้อย 1 ตัว โดยในกรณีนี้ ให้ทำการแปลงทั้ง Entity และ Relationship ที่สัมพันธ์กันเป็น Relation เดียวที่ ประกอบขึ้นจาก Attribute ของทั้ง Entity และ Relationship ที่สัมพันธ์กันนั้น พร้อมกับกำหนด Primary key จาก Identifier ของ Entity ใด Entity หนึ่งที่ สัมพันธ์กัน 12.27

29 CUST-SHIPPING(Cust-No,Cust-Name,Ship-Address)
การแปลง Relationship ไปเป็น Relation CUSTOMER Cust-No Cust_Name Ship-Address CUST-SHIPPING(Cust-No,Cust-Name,Ship-Address) WITH SHIPPING-INFO 1 (1,1) 12.28

30 การแปลง Relationship ไปเป็น Relation
กรณีที่ 2 Entity มีความสัมพันธ์กับแบบ Partial Participation คือ สมาชิกบาง ตัวใน Entity หนึ่งไปมีความสัมพันธ์กับสมาชิกบางตัวของอีก Entity หนึ่ง โดยใน กรณีนี้ ให้ทำการแปลงแต่ละ Entity ที่มีสัมพันธ์กันเป็นแต่ละ Relation ที่มี Primary key ซึ่งเลือกจาก Identifier ของ Entity เหล่านั้นส่วน Relationship สามารถทำได้ 2 วิธีดังนี้ วิธีที่ 1 แปลง Relationship ไปเป็น Relation ที่ประกอบด้วย Attribute ของ Relationship นั้นเองรวมกับ Attribute ที่เป็น Identifier ของ Entity ที่สัมพันธ์กับ Relationship นั้นส่วน Primary Key ให้เลือกจาก Identifier ของ Entity ใด Entity หนึ่งที่สัมพันธ์กับ Relationship นั้น 12.29

31 CUSTOMER(Cust-No,Cust-Name)
การแปลงโครงร่างของ Relationship ให้อยู่ในรูปของ Relational Schema แบบ Partial Participant 12.30 CUSTOMER Cust-No Cust_Name Credit-Limit CUSTOMER(Cust-No,Cust-Name) CREDIT-CARD(Card_Type,Card-No,Credit-Limit) POSSESSES-CARD(Card-Type,Card-No,Cust-No) Possesses CREDIT-CARD 1 (0,1) (1,1) Card-No Card-Type

32 การแปลง Relationship ไปเป็น Relation
วิธีที่ 2 วิธีนี้สามารถทำได้เช่นเดียวกับวิธีที่ 1 แต่การเลือกPrimary Key ให้เลือกจาก Identifier ของทุก Entity ที่สัมพันธ์กับ Relationship นั้น ดัง ตัวอย่าง 12.31

33 FEMALE(Female-SSN, Name) MARRIAGE(Male-SSN,Female-SSN,Date,Duration)
การแปลงโครงร่างของ Relationship ให้อยู่ในรูปของ Relational Schema แบบ Partial Participant MALE Male-SSN Name MALE(Male-SSN, Name) FEMALE(Female-SSN, Name) MARRIAGE(Male-SSN,Female-SSN,Date,Duration) MARRIAGE FEMALE 1 (0,1) Female-SSN Date Duration 12.32

34 การแปลง Relationship ไปเป็น Relation
กรณีที่เป็น One-to-Many Relationship ในการแปลงสามารถทำได้ 2 กรณี ดังนี้ กรณีที่ 1 Entity มีความสัมพันธ์กับแบบ Total Participation คือ ให้ย้ายทุก Attribute ของRelationship รวมทั้งสำเนา Identifier ของ Entity ทางด้าน One ไปเป็น Attribute ของ Entity ทางด้าน Many จากนั้นจึงแปลงทั้ง 2 Entity ไป เป็น Relation ดังตัวอย่าง 12.33

35 การแปลงโครงร่างของ Relationship ให้อยู่ในรูปของ Relational Schema
CITY BELONG-TO City-Name Population Governor State-Name STATE (1,1) (1,n) M 1 CITY(City-Name,State-Name,Population) STATE(State-Name,Governor,Population) 12.34

36 การแปลง Relationship ไปเป็น Relation
กรณีที่ 2 Entity มีความสัมพันธ์กับแบบ Partial Participation ให้แปลงทั้ง 2 Entity และ Relationship ไปเป็นแต่ละ Relation แต่ Relation ของ Relationship จะประกอบด้วย Attribute ของ Relationship เองรวมกับ Identifier ของทั้ง 2 Entity ที่สัมพันธ์กับ Relationship นั้น ส่วน Primary Key ให้เลือกจาก Identifier ของ Entity ใด Entity หนึ่งที่สัมพันธ์กับ Relationship นั้น ดังตัวอย่าง 12.35

37 การแปลงโครงร่างของ Relationship ให้อยู่ในรูปของ Relational Schema
SALEMAN WRITES Name Phone-No Date Order_No ORDER (1,n) (0,1) M 1 SALEMAN(Name, Phone-No) ORDER(Order-No, Date) SALE-ORDER(Order-No, Name, Discount-Rate) Discount- Rate 12.36

38 การแปลง Relationship ไปเป็น Relation
กรณีที่เป็น Many-to-Many Relationship ให้ทำการแปลงทั้ง 2 Entity และ Relationship ไปเป็นแต่ละ Relation แต่ Relation ของ Relationship จะประกอบด้วย Attribute ของ Relationship เอง รวมกับIdentifier ของทั้ง 2 Entity ที่สัมพันธ์กับ Relationship นั้น ส่วน Primary Key ให้เลือกจาก Identifier ของทั้ง2 Entity ที่สัมพันธ์กับ Relationship นั้น ดัง ตัวอย่าง 12.37

39 การแปลงโครงร่างของ Relationship ให้อยู่ในรูปของ Relational Schema
STUDENT Student-No Name Course_No COURSE (1,n) M N STUDENT(Student_No, Last-Name,GPA) COURSE(Course-No, Course-Name) ENROLL-IN(Student-No, Course-No, Semester,Grade) GPA Grade Semester Course-Name ENROLL-IN 12.38

40 การแปลง Relationship ไปเป็น Relation
กรณีที่เป็น N-ary Relationship ให้แปลงทุก Entity และ Relationship ไปเป็นแต่ละ Relation แต่ Relation ของ Relationship จะประกอบด้วย Attribute ของ Relationship เอง รวมกับ Identifier ของทุก Entity ที่สัมพันธ์กับ Relationship นั้น ส่วน Primary Key ให้เลือกจาก Identifier ของทุก Entity ที่สัมพันธ์กับ Relationship นั้น ดัง ตัวอย่าง 12.39

41 การแปลงโครงร่างของ Relationship ให้อยู่ในรูปของ Relational Schema
Product-Code Name M PRODUCT(Product-Code, Name, Description) PART(Part-Code, Description) SUPPLIER(Supplier-Code, Name, Address, Telephone) SUPPLY(Product-Code, Part-Code, Supplier-Code, Quantity) Description Part-Code PRODUCT PART SUPPLY Supplier-Code Quantity Address Telephone SUPPLIER 12.40

42 การแปลง Relationship ไปเป็น Relation
กรณีที่เป็น Recursive Relationship ให้แปลงทุก Entity และ Relationship ไปเป็นแต่ละ Relation แต่ Relation ของ Relationship จะประกอบขึ้นจาก Identifier ของ Entity ที่สัมพันธ์กับ Relationship นั้นจำนวน 2 ชุด ซึ่งแต่ละชุดจะให้ชื่อตาม Role ของ Entity ใน Relationship นั้นรวมกับ Attribute ของ Relationship เอง ส่วนการเลือก Primary Key จะสามารถทำได้ 2 กรณีดังนี้ กรณีเป็น One-to-Many Relationship ให้เลือก Primary Key จาก Identifier ทางด้าน Many กรณีเป็น Many-to-Many Relationship ให้เลือก Primary Key 2 ด้าน รวมกัน 12.41

43 การแปลงโครงร่างของ Relationship ให้อยู่ในรูปของ Relational Schema
EMPLOYEE Name IS-Subord MANAGER-OF Date-of-Birth IS-Manager-of 12.42

44 กรณีที่เป็น Recursive Relationship
1. กรณีกำหนดให้ลูกจ้างแต่ละคนสามารถมีนายจ้างได้หลายคน ความสัมพันธ์จึงอยู่ ในลักษณะ Many-to-Many ดังนั้นทั้ง Attribute “NAME-OF-MANAGER” และ “NAME-OF-SUBORDINATE” จึงถูกกำหนดให้เป็น Primary Key ของ Relation ดังนี้ EMPLOYEE(Name, Date-Of-Birth) MANAGER-OF (Name-Of-Manager, Name-of-Subordinate) 12.43

45 กรณีที่เป็น Recursive Relationship
2. กรณีกำหนดให้ลูกจ้างแต่ละคนสามารถมีนายจ้างได้เพียงคนเดียว ความสัมพันธ์ จึงอยู่ในลักษณะ One-to-Many ดังนั้น Attribute “Name-Of-Subordinate” จึงถูก กำหนดให้เป็น Primary Key ของ Relationเพียง Attribute ดังนี้ EMPLOYEE(Name, Date-Of-Birth) MANAGER-OF (Name-Of-Subordinate, Name-of-Manager) แต่บางกรณี ถ้าค่าของ Attribute “Name-of-Subordinate” ของ Relation “Manager-Of” และ Attribute “Name” ของ Relation “Employee” มีค่า เดียวกัน สามารถยุบ Relation “Manager-Of” เพื่อไปเป็น Attribute ของ Relation “Employee” EMPLOYEE(Name, Date-Of-Birth, Name-Of-Manager) 12.44

46 การทำ Normalization Normalization คือ กระบวนการปรับปรุงโครงสร้างข้อมูลของฐานข้อมูลที่มีความซ้ำซ้อนให้อยู่ในรูปแบบที่เป็นบรรทัดฐาน Normal Form มีอยู่ 6 ระดับด้วยกัน คือ 1. First Normal Form (1NF) เพื่อจำกัดกลุ่มข้อมูลที่ซ้ำซ้อนกัน 2. Second Normal Form (2NF) เพื่อจำกัดความสัมพันธ์แบบ Partial Dependency ที่เกิดขึ้นระหว่าง Attribute 3. Third Normal Form (3NF) เพื่อจำกัดความสัมพันธ์แบบ Transitive Dependency ที่เกิดขึ้นระหว่าง Attribute 4. Boyce-Codd Normal Form (BCNF) เพื่อจำกัดปัญหาแบบ Update Anomaly ที่อาจเหลืออยู่ 5. Fourth Normal Form (4NF) เพื่อจำกัดปัญหาแบบ Multi-Value Dependency ที่เกิดขึ้นของ Attribute 6. Fifth Normal Form (5NF) เพื่อจำกัดปัญหาแบบ Join Dependency ที่เกิดขึ้นของ Attribute 12.45

47 ขั้นตอนการทำ Normalization
Entity ที่มีข้อมูลซ้ำซ้อน 1NF 2NF 3NF กำจัดกลุ่มข้อมูลซ้ำซ้อน กำจัด Partial Dependency กำจัด Transitive 12.46

48 การทำ Normalization Partial Dependency EmpID CourseNo DateComplete
Partial Dependency คือความสัมพันธ์ที่ต้องมี Determinant-attribute มากกว่า 1 ตัว (มี Primary key/Identifier มากกว่า 1 Attributes นั่นเอง) ความสัมพันธ์ระหว่างค่าของ Attribute เมื่อ Attribute ที่เป็น Determinant บางตัวสามารถระบุค่าของ Attribute อื่นที่ไม่ใช่ Identifier ได้ EmpID CourseNo DateComplete CourseName Partial Dependency 12.47

49 การทำ Normalization Emp_ID Name Job_Class Chg_Hour
Transitive Dependency คือความสัมพันธ์ระหว่าง Attribute ที่ไม่ใช่ Determinant Attribute (Attribute ที่ไม่ใช่ Primary Key นั่นเอง) ไป ขึ้นอยู่กับ Attribute อื่นที่ไม่ได้เป็น Determinant Attribute เหมือนกัน Emp_ID Name Job_Class Chg_Hour Transitive Dependency 12.48

50 ตัวอย่างข้อมูล 12.49 EmpID EmpName DeptNo DeptName Salary Course NO
Date Complete 110 วิลาวัลย์ ขำคม 01 Account 15,000 C1 Acc PAC 12/ C2 SPSS 30/04/2002 112 อุษาวดี เจริญกุล 15,100 091 นพพร บุญชู 03 IT 12,000 C3 3D Studio max 31/03/2002 010 กสมา ร่มเย็น 11,000 001 วนิดา แซ่ลิ้ม 02 Marketing 12,500 12/06/2002 12.49

51 First Normal Form (1NF) First Normal Form (1NF) เพื่อกำจัดกลุ่มข้อมูลที่ซ้ำซ้อนกัน (Repeating Group) วิธีแก้ไข (กำจัด Repeating Group) เติมข้อมูลใน Attribute ที่ว่างให้เต็ม และนำ “CourseNo” มาเป็น Primary Key ร่วมกับ “EmpID” 12.50

52 ผลลัพธ์การทำ 1NF 12.51 EmpID EmpName DeptNo DeptName Salary Course NO
Date Complete 110 วิลาวัลย์ ขำคม 01 Account 15,000 C1 Acc PAC 12/ C2 SPSS 30/04/2002 112 อุษาวดี เจริญกุล 15,100 091 นพพร บุญชู 03 IT 12,000 C3 3D Studio max 31/03/2002 010 กษมา ร่มเย็น 11,000 001 วนิดา แซ่ลิ้ม 02 Marketing 12,500 12/06/2002 12.51

53 Second Normal Form (2NF)
Entity หรือ Relationship จะมีคุณสมบัติเป็น 2 NF ได้เมื่อ Entity นั้นจะต้องมีคุณสมบัติ 1NF Attributes จะต้องไม่มีความสัมพันธ์กันแบบ Partial Dependency กล่าวคือ Nonprime Attribute จะต้องไม่ขึ้นอยู่กับ Identifier ตัวใดตัวหนึ่ง กรณีที่ Identifier นั้นเกิดจาก Attribute มากกว่า 1 Attribute วิธีการแก้ไข (กำจัด Partial Dependency) แยก Attribute ที่ขึ้นตรงต่อกันออกมาเป็น Relation ใหม่ โดยมี Attribute ที่สามารถระบุค่าอื่นได้เป็น Primary Key 12.52

54 ผลลัพธ์การทำ 1NF FD1: EmpID,CourseNo -> DateComplete
EmpName DeptNo DeptName Salary Course NO Name Date Complete FD1: EmpID,CourseNo -> DateComplete FD2: EmpID -> EmpName, DeptNo, DepName, Salary FD3: CourseNo -> CourseName 12.53

55 ผลลัพธ์การทำ 2NF Employee Course 12.54 EmpID EmpName DeptNo DeptName
Salary 110 วิลาวัลย์ ขำคม 01 Account 15,000 112 อุษาวดี เจริญกุล 15,100 091 นพพร บุญชู 03 IT 12,000 010 กสมา ร่มเย็น 11,000 001 วนิดา แซ่ลิ้ม 02 Marketing 12,500 Course NO Name C1 Acc PAC C2 SPSS C3 3D Studio max 12.54

56 ผลลัพธ์การทำ 2NF Emp_Course 12.55 EmpID Course NO Date Complete 110 C1
12/ C2 30/04/2002 112 091 C3 31/03/2002 010 001 12/06/2002 12.55

57 Third Normal Form (3NF) Entity หรือ Relationship จะมีคุณสมบัติเป็น 3NF ได้เมื่อ Entity นั้นจะต้องมีคุณสมบัติ 2NF ต้องเป็น Entity ที่ Attributes ไม่มีความสัมพันธ์แบบ Transitive Dependency กล่าวคือเกิดกรณีที่ Nonprime Attribute (หรือ Attribute ที่ไม่ใช่ Identifier นั่นเอง) ไปขึ้นอยู่กับ Nonprime attribute ด้วยกันเอง วิธีการแก้ไข (กำจัด Transitive Dependency) แยก Attribute ที่ขึ้นตรงต่อกันออกมาเป็น Relation ใหม่ โดยมี Attribute ที่สามารถระบุค่าอื่นได้เป็น Primary Key และเก็บ Attribute ที่เป็น Key ไว้ในทำหน้าที่เป็น Foreign Key ใน Relation เดิม 12.56

58 ผลลัพธ์การทำ 3NF FD1: EmpID -> EmpName, DeptNo, Salary
DeptName Salary FD1: EmpID -> EmpName, DeptNo, Salary FD2: DeptN0 -> DepName 12.57

59 ผลลัพธ์การทำ 3NF Employee Department 12.58 EmpID EmpName DeptNo Salary
110 วิลาวัลย์ ขำคม 01 15,000 112 อุษาวดี เจริญกุล 15,100 091 นพพร บุญชู 03 12,000 010 กสมา ร่มเย็น 11,000 001 วนิดา แซ่ลิ้ม 02 12,500 DeptNo DeptName 01 Account 02 Marketing 03 IT 12.58

60 Reference Book and Text Book
ตำราอ้างอิง การวิเคราะห์และออกแบบระบบ กิตติ ภักดีวัฒนกุล และพนิดา พานิชกุล Modern Systems Analysis & Design : Jeffrey A. Hoffer, Joey F.George, Joseph S. Valacich 12.59

61 Q & A 12.60


ดาวน์โหลด ppt ส่วนที่ 4 System Design การออกแบบระบบ.

งานนำเสนอที่คล้ายกัน


Ads by Google