Chapter 1-2 Database Architecture & Database Model

1. Chapter 1-2Database Architecture & Database Model อาจารย์เกศแก้ว ประดิษฐ์ สาขาวิชาจัดการเทคโนโลยีสารสนเทศ Kate_psu08@hotmail.com

2. สถาปัตยกรรม ANSI/SPARC • สถาปัตยกรรมในระดับ External • สถาปัตยกรรมในระดับ Conceptual • สถาปัตยกรรมในระดับ Internal • Mapping • Relationship • Database Model • Hierarchical Database Model • Network Database Model • Relation Database Model Database Architecture& Database Model

3. สถาปัตยกรรมฐานข้อมูล (Database Architecture) เป็นการอธิบายรูปแบบและโครงสร้างโดยทั่วไป ของข้อมูลภายในระบบฐานข้อมูล โดยไม่ขึ้นอยู่กับระบบใดระบบหนึ่ง ซึ่งที่ใช้นิยมกันคือ การอธิบายสถาปัตยกรรมฐานข้อมูลโดย ANSI/SPARC (American Nation Standards Institue / System Planing and Requirement Committee) สถาปัตยกรรม ANSI/SPARC

4. ANSI/SPARC แบ่งสถาปัตยกรรมระบบฐานข้อมูลออกเป็น 3 ระดับ คือ Internal External และ Conceptual • Internal Level เป็นสถาปัตยกรรมฐานข้อมูลระดับในสุด ซึ่งอธิบายโครงสร้างของการจัดเก็บข้อมูลในเชิงกายภาพ (Physical Structure) ผู้ที่เกี่ยวข้องกับระดับนี้คือ DBA (ผู้บริหารฐานข้อมูล) • Conceptual Level เป็นสถาปัตยกรรมข้อมูลระดับที่อยู่ระหว่าง Internal และExternal ทำหน้าที่ถ่ายทอดรูปแบบของ Internal Level ให้อยู่ในรูปแบบที่สามารเข้าใจได้ง่าย (Logical Structure) ผู้ที่เกี่ยวข้องกับระบบนี้คือ DBA สถาปัตยกรรม ANSI/SPARC

5. External Level เป็นสถาปัตยกรรมระดับนอกสุด ใกล้ชิดกับผู้ใช้ฐานข้อมูลมากที่สุด เพราะเป็นระดับที่กล่าวถึงมุมมองข้อมูลของผู้ใช้แต่ละคน (User View) ผู้ที่เกี่ยวข้องคือ User ที่ใช้ฐานข้อมูล สถาปัตยกรรม ANSI/SPARC

6. สถาปัตยกรรมระบบฐานข้อมูลทั้ง 3 ระดับ สามารถอธิบายได้โดยใช้ฐานข้อมูล Northwind ดังนี้ • Internal Level ฐานข้อมูล Northwind เก็บอยู่ในไฟล์ที่ชื่อว่า Northwind.mdb ซึ่งเป็นไฟล์ของโปรแกรม MS Access ที่ทำงานอยู่ในระบบปฏิบัติการ MS Windows 7, Vita โดยไฟล์นี้เก็บอยู่ใน C:/program file/Microsoft office/ บน Hard Disk ณ ตำแหน่ง Sector 84A6 ,Track 15 เป็นต้น สถาปัตยกรรม ANSI/SPARC

7. Conceptual Level ฐานข้อมูล Northwindประกอบด้วย Tables คือ Categories, Customer, Employee, Order Detail, Order ฯลฯ Queries คือ Category Sale for 2000 เป็นต้น Form คือ Categories , Main Switchboard , Sale Analysis Report คือ รายงานแต่ละตัวที่ทำใน Northwind สถาปัตยกรรม ANSI/SPARC

8. External Level ฐานข้อมูล Northwind แบ่งให้พนักงานแผนกต่างๆ มองเห็นได้ต่างกัน ดังนี้คือ พนักงานฝ่ายขาย มองเห็นข้อมูลใน Categories , Order, Order Detail , Products พนักงานฝ่ายบุคคล มองเห็นข้อมูลใน Employee , Order ผู้จัดการทั่วไป มองเห็นข้อมูลทั้งหมด สถาปัตยกรรม ANSI/SPARC

9. External Level#1 External Level#2 External Level#3 Conceptual Level Internal Level สถาปัตยกรรม ANSI/SPARC รูปที่ 1สถาปัตยกรรมข้อมูล ANSI/SPARC

10. โครงสร้างทางกายภาพในการจัดเก็บข้อมูลพนักงานในฐานข้อมูลแต่ละระดับ ดังรูป สถาปัตยกรรม ANSI/SPARC

12. สถาปัตยกรรมในระดับ External เป็นระดับของสถาปัตยกรรม ซึ่งไม่ได้เป็นรูปร่างหรือโครงสร้างของข้อมูลที่แท้จริง เนื่องจากโครงสร้างของข้อมูลในระดับนี้ จะแปรเปลี่ยนไปตามมุมมองของผู้ใช้ที่นำเอาข้อมูลนั้น ๆ มาใช้งาน เช่นโครงสร้างของข้อมูลที่มีต่อโปรแกรมเมอร์ ที่จะอยู่ในรูปโครงสร้าง Record และ Field ซึ่งต่างจากมุมมองของผู้ใช้ที่สนใจข้อมูลในแง่ของความหมายที่เก็บอยู่ในแต่ละ Record และในแต่ละ Field แทน หรือแม้แต่ผู้ใช้ที่อยู่ในกลุ่มเดียวกัน ก็อาจมีมุมมองต่อข้อมูลในระดับนี้ที่แตกต่างกัน สถาปัตยกรรม ANSI/SPARC

13. สถาปัตยกรรมในระดับ Conceptual เป็นระดับของสถาปัตยกรรม ซึ่งเป็นโครงสร้างของข้อมูลในระดับแนวความคิด ซึ่งเป็นภาพของข้อมูลที่ใช้แทนโครงสร้างทางกายภาพของข้อมูลที่แท้จริงที่เก็บอยู่ในฐานข้อมูล เพื่อง่ายต่อการอธิบายถึงโครงสร้างของข้อมูลต่างๆ ที่เก็บอยู่ในฐานข้อมูล ดังนั้น ภาพของ Record ที่เห็นในสถาปัตยกรรมในระดับนี้ จึงเป็นภาพของ Record ในระดับแนวความคิด ซึ่งไม่จำเป็นที่ต้องมีโครงสร้างเช่นเดียวกับโครงสร้างข้อมูลของ External Record และโครงสร้างทางกายภาพของ Record ที่เก็บอยู่จริง หรือเรียกอีกอย่างหนึ่งว่า View สถาปัตยกรรม ANSI/SPARC

14. ตัวอย่าง View Table Employee ในฐานข้อมูลที่เก็บอยู่จริง สถาปัตยกรรม ANSI/SPARC

15. ตัวอย่าง View View พนักงานบุคคล สามารถแก้ไขและลบข้อมูลเกี่ยวกับพนักงานได้ สถาปัตยกรรม ANSI/SPARC

16. ตัวอย่าง View View พนักงานบัญชี สามารถแก้ไขข้อมูลเกี่ยวกับเงินเดือนได้แต่ไม่สามารถลบข้อมูลพนักงานได้ สถาปัตยกรรม ANSI/SPARC

17. ในสถาปัตยกรรม ANSI/SPARC มุมมองที่มีต่อข้อมูลในสถาปัตยกรรมในระดับที่สูงกว่า สามารถถ่ายทอดมุมมองนั้นไปยังสถาปัตยกรรมในระดับที่ต่ำกว่าได้ เช่น การถ่ายทอดมุมมองที่มีต่อข้อมูลจากสถาปัตยกรรมในระดับ Conceptual ไปยังสถาปัตยกรรมในระดับ Internal เพื่อนำโครงสร้างของข้อมูลในระดับ Conceptual Schema แปลงไปเป็นโครงสร้างของข้อมูลในระดับกายภาพเพื่อใช้ในการจัดเก็บข้อมูล เป็นต้น สำหรับการถ่ายทอดมุมมองจากสถาปัตยกรรมในระดับที่สูงกว่าไปยังระดับที่ต่ำกว่า เรียกว่า Mapping Mapping

18. การทำ Mapping ตามสถาปัตยกรรม แบ่งเป็น 2 ลักษณะ คือ • Conceptual / Internal Mapping เป็นการถ่ายทอดมุมมองที่มีต่อข้อมูลจากสถาปัตยกรรมในระดับ Conceptual ไปยังสถาปัตยกรรมในระดับ Internal เพื่อนำโครงสร้างข้อมูลต่าง ๆ ในระดับ Conceptual มากำหนดโครงสร้าง Record และ Field ที่จะนำไปใช้ในการจัดเก็บข้อมูล Mapping

19. External / Conceptual Mapping เป็นการถ่ายทอดมุมมองที่มีต่อข้อมูลจากสถาปัตยกรรมในระดับ External ไปยังสถาปัตยกรรมในระดับConceptual เพื่อกำหนดโครงสร้างของ Record และ Field ให้สามารถครอบคลุมความต้องการหรือมุมมองต่างๆ ของผู้ใช้ Mapping

20. External / Conceptual Mapping การกำหนดหรือเปลี่ยนแปลงโครงสร้างให้กับข้อมูลของระบบฐานข้อมูล โดยทั่วไปมักจะยอมให้เกิดขึ้นในสถาปัตยกรรมระดับ External มากกว่าสถาปัตยกรรมในระดับ Conceptual เนื่องจากสถาปัตยกรรมในระดับ External ผู้ใช้จะมีมุมมองต่อโครงสร้างของข้อมูลในระดับกายภาพน้อยกว่าสถาปัตยกรรมในระดับ Conceptual จึงง่ายต่อการกำหนดหรือเปลี่ยนแปลงโครงสร้างให้กับข้อมูลของระบบฐานข้อมูล สำหรับหน้าที่ในการทำ Mapping ทั้ง 2 ลักษณะนี้เป็นหน้าที่ของ DBA Mapping

21. Database Administrator (DBA)เป็นบุคคลที่มีหน้าที่ในการกำหนด ควบคุมการเข้าใช้งานข้อมูลภายในฐานข้อมูล รวมทั้งจัดหาเทคนิคที่จำเป็นต่อกลยุทธ์กำหนดขึ้น ดังนั้น DBA จึงมีความเกี่ยวข้องกับสถาปัตยกรรมของระบบฐานข้อมูลดังนี้ 1. เป็นผู้กำหนดโครงสร้างข้อมูลของสถาปัตยกรรมในระดับ Conceptual เช่น กำหนดว่าข้อมูลใดบ้างที่ควรจัดเก็บไว้ในฐานข้อมูล และโครงสร้างเป็นอย่างไร สถาปัตยกรรมของระบบฐานข้อมูลกับ Database Administrator

22. 2. เป็นผู้กำหนดโครงสร้างข้อมูลของสถาปัตยกรรมในระดับ Internal ซึ่งได้แก่ โครงสร้างทางกายภาพของข้อมูลที่ใช้ในการจัดเก็บ เช่น ขนาดของแต่ละ Field และประเภทของข้อมูล 3. เป็นผู้ทำหน้าที่ตรวจสอบโครงสร้างข้อมูลที่กำหนดขึ้นว่าสามารถรองรับต่อมุมมองหรือความต้องการในการใช้ข้อมูลของผู้ใช้ในสถาปัตยกรรมในระดับ External เป็นต้น สถาปัตยกรรมของระบบฐานข้อมูลกับ Database Administrator

23. 4. เป็นผู้กำหนดการรักษาความปลอดภัย และกฎที่ใช้ในการควบคุมความถูกต้องให้กับข้อมูล ซึ่งเป็นส่วนหนึ่งของการกำหนดโครงสร้างของข้อมูลในสถาปัตยกรรมในระดับ Conceptual 5. เป็นผู้กำหนดวิธีในการสำรองข้อมูล (Data Backup) และการกู้ข้อมูลที่เสียหายกลับมาใช้งาน (Data Recovery) 6. เป็นผู้ควบคุมให้ระบบฐานข้อมูลมีประสิทธิภาพ และทันสมัยตามความต้องการที่เปลี่ยนไป สถาปัตยกรรมของระบบฐานข้อมูลกับ Database Administrator

24. Database Model แบ่งออกได้เป็น 2 ประเภท คือ • Conceptual Model เป็นแบบจำลองซึ่งถูกนำไปใช้ในขั้นตอนการออกแบบฐานข้อมูล เพื่อให้เห็นว่าภายในฐานข้อมูลต้องประกอบด้วยข้อมูลอะไรบ้าง และแต่ละข้อมูลมีความสัมพันธ์กันอย่างไร ดังนั้นแบบจำลองในกลุ่ม มักจะมีสัญลักษณ์ที่ใช้แทนข้อมูล คุณสมบัติของข้อมูลและความสัมพันธ์ระหว่างข้อมูล ตัวอย่างเช่น Entity-Relationship Model (E-R Model) และ Object-Oriented Model Database Model

25. Database Model แบ่งออกได้เป็น 2 ประเภท คือ • Implementation Model เป็นแบบจำลองซึ่งถูกนำไปใช้ในขั้นตอนการสร้างฐานข้อมูล ของฐานข้อมูลแต่ละประเภท เช่น Hierarchical , Network , Relation และ Object-Oriented Database Model Database Model

26. เนื่องจากการออกแบบฐานข้อมูล เป็นเรื่องที่มีความสลับซับซ้อนเป็นอย่างมาก จึงได้มีการพัฒนาแบบจำลอง ซึ่งเรียกว่า Database Model เพื่ออธิบายโครงสร้างและความสัมพันธ์ระหว่างฐานข้อมูล เพื่อช่วยให้สามารถสร้างฐานข้อมูลได้ง่ายขึ้น โดยทั่วไป Database Model ประกอบด้วยส่วนประกอบหลัก 3 ส่วน Database Model

27. Database Model ประกอบด้วยส่วนประกอบหลัก 3 ส่วน • สัญลักษณ์ซึ่งใช้แทนข้อมูล • สัญลักษณ์ซึ่งใช้แทนกฎและระเบียบต่าง ๆ เพื่อใช้ควบคุมความถูกต้องของข้อมูล • สัญลักษณ์ซึ่งใช้แทนการกระทำการ(Operator) ต่างๆ กับตัวข้อมูล Database Model

28. สัญลักษณ์ซึ่งใช้แทนข้อมูล • สัญลักษณ์ซึ่งใช้แทนกฎและระเบียบต่าง ๆ เพื่อใช้ควบคุมความถูกต้องของข้อมูล One-to-one One-to-many • สัญลักษณ์ซึ่งใช้แทนการกระทำการ(Operator) ต่างๆ กับตัวข้อมูล Database Model

29. Relationship ในระบบฐานข้อมูล ข้อมูลแต่ละส่วนจะมีความสัมพันธ์เกี่ยวข้องกัน ทฤษฏีระบบฐานข้อมูลได้แบ่งความสัมพันธ์ของข้อมูลออกเป็น 3 แบบ คือ one-to-one , one-to-many , many-to-manyrelationship Database Model

30. Relationship • One-to-One Relationship (1:1) ความสัมพันธ์แบบ 1: 1 เป็นความสัมพันธ์ที่ข้อมูลชุด A แต่ละรายการ มีความสัมพันธ์กับข้อมูลชุด B เพียงรายการเดียว ตัวอย่าง ผู้ว่าราชการจังหวัด กับ จังหวัด Database Model

31. ปกครอง ผู้ว่าราชการฯ จังหวัด ตัวอย่างผู้ว่าราชการจังหวัดกับจังหวัด • ผู้ว่าราชการจังหวัดแต่ละคน ปกครอง จังหวัดได้เพียง 1 จังหวัด • จังหวัดแต่ละจังหวัดมีผู้ว่าราชการจัดหวัดปกครองได้เพียงคนเดียว Relationship

32. วาด จิตรกร ภาพ • One-to-Many Relationship (1:M) ความสัมพันธ์แบบ 1: M เป็นความสัมพันธ์ที่ข้อมูลชุด A แต่ละรายการ มีความสัมพันธ์กับข้อมูลชุด B มากกว่า 1 รายการ ตัวอย่าง จิตรกรกับภาพวาด เป็นความสัมพันธ์แบบ 1: M เพราะ • จิตรกรแต่ละคนสามารถวาดภาพได้หลายภาพ • ภาพแต่ละภาพถูกวาดโดยจิตรกรเพียงหนึ่งคนเท่านั้น Relationship

33. Relationship

34. Many-to-Many Relationship (M:N) ความสัมพันธ์แบบ M: N เป็นความสัมพันธ์ที่ข้อมูลชุด A แต่ละรายการ มีความสัมพันธ์กับข้อมูลชุด B มากกว่า 1 รายการ ในขณะเดียวกัน ข้อมูลชุด B แต่ละรายการมีความสัมพันธ์กับข้อมูลชุด A ได้หลายรายการเช่นกัน ตัวอย่างนักศึกษากับวิชาที่ลงทะเบียนเรียน เป็นความสัมพันธ์แบบ 1: M • นักศึกษาแต่ละคนสามารถลงทะเบียนเรียนได้หลายวิชา • วิชาแต่ละวิชามีนักศึกษาลงทะเบียนเรียนได้หลายคน Relationship

35. 1 M M 1 ลงทะเบียน นักศึกษา รายวิชา ตัวอย่างนักศึกษากับวิชาที่ลงทะเบียนเรียน เป็นความสัมพันธ์แบบ 1: M • นักศึกษาแต่ละคนสามารถลงทะเบียนเรียนได้หลายวิชา • วิชาแต่ละวิชามีนักศึกษาลงทะเบียนเรียนได้หลายคน M N ลงทะเบียน นักศึกษา รายวิชา Relationship

36. Relationship

37. โครงสร้างของ Hierarchical Database Model มีลักษณะเป็น Tree สี่เหลี่ยมแต่ละตัวเป็นองค์ประกอบเรียกว่า Segment เทียบได้กับ Record หนึ่ง ๆ ในระบบ File System ตัว Segment ระดับบนสุด เรียกว่า Root ซึ่งเป็น Parent ของระดับถัดลงมา segment ระดับที่ต่ำกว่าเป็น Child (หรือ Children) ของระดับที่เหนือกว่า ดังรูปแสดง เช่น segment A ซึ่งเป็น root เป็น parent ของ segment B และ C ในทำนองเดียวกัน C เป็น parent F, G และ H หรือ I และ J เป็น Children ของ E เป็นต้น Hierarchical Database Model

38. A B C G D E H F I J Root segment Level 1 segments (Root Children) Hierarchical Database Model Level 2 segments (level 1 Children) Level 3 segments (level 2 Children)

39. แต่ละ Segment จะถูกจัดเก็บไว้ในอุปกรณ์จัดเก็บข้อมูล ซึ่งมีตำแหน่งที่จัดเก็บชัดเจน ดังนั้นในการเรียกข้อมูลมาใช้งาน ต้องกำหนดเส้นทาง (Hierarchical Path) ของ Segment ให้ถูกต้อง โดยการกำหนดเส้นทาง ใช้หลักการที่เรียกว่า Preorder Traversal นั้นคือบอกว่า path จากบนลงล่าง และซ้ายไปขวา เช่น • path ของ J เป็น ABDEIJ Hierarchical Database Model

40. หมายเหตุ ความสัมพันธ์ของ Hierarchical Database Model เป็นแบบ 1:M นั้นคือ Parent แต่ละตัวมี Children ได้หลายตัว แต่ Children มี parent ได้เพียงตัวเดียว ตัวอย่างเช่น บริษัทหนึ่ง ๆ มีหลายแผนก แต่ละแผนกเป็นของบริษัทเดียว หรือ แผนกหนึ่งมีลูกจ้างได้หลายคน แต่ลูกจ้างทำงานสังกัดเพียงหนึ่งแผนกเท่านั้น เป็นต้น Hierarchical Database Model

41. สามารถกำหนดกฎเกณฑ์ที่ใช้ควบคุมความถูกต้องให้กับข้อมูล (Data Integrity) ภายในฐานข้อมูลได้ง่าย เนื่องจากกฎเกณฑ์ที่กำหนดให้กับ segment ที่ทำหน้าที่เป็น Parent Segment สามารถถ่ายทอดไปยัง Segment ที่ทำหน้าที่เป็น Child Segment ภายใต้ Segment นั้นได้ ข้อดีของ Hierarchical Database Model

42. มีโครงสร้างที่เหมาะกับข้อมูลที่มีความสัมพันธ์ในแบบ One-to-many เช่น ข้อมูลการฝากถอนเงินของลูกค้าธนาคารแต่ละคน ซึ่งในแต่ละวันสามารถเกิดขึ้นได้มากกว่า 1 รายการ หรือในกรณีที่ลูกค้ามีบัญชีเงินฝากธนาคารมากกว่า 1 บัญชี เป็นต้น • มีโครงสร้างที่เหมาะสมกับระบบคอมพิวเตอร์ที่มีขนาดใหญ่ เช่น Mainframe ข้อดีของ Hierarchical Database Model

43. Hierarchical Database Model เป็นแบบจำลองแรก ที่พยายามแก้ปัญหาที่เกิดขึ้นจาก File System ซึ่งยังมีข้อผิดพลาดหลายประการ คือ • designer และ programmer จำเป็นต้องมีความรู้เกี่ยวกับ Physical structure ของข้อมูล จึงจะสามารถจัดการกับข้อมูลได้อย่างมีประสิทธิภาพ การเปลี่ยนแปลงโครงสร้างของข้อมูล เช่น การเปลี่ยนตำแหน่งของ segment ส่งผลให้ต้องมีการเปลี่ยนแปลง Application ต่าง ๆ ที่ใช้ segment นั้น ข้อเสียของ Hierarchical Database Model

44. Hierarchical database model รองรับเฉพาะความสัมพันธ์ที่เป็น 1:M ทั้ง ๆ ที่ในความเป็นจริง ยังมีข้อมูลอีกมากที่มีความสัมพันธ์แบบ M:N เช่น นักศึกษากับวิชาเรียน ซึ่งไม่สามารถจัดการได้ง่ายนักบนระบบนี้ ข้อเสียของ Hierarchical Database Model

45. บางกรณีที่ Child ตัวหนึ่งอาจมี parent มากกว่า 1 ตัว เช่น ผลการเรียนของนักศึกษาขึ้นอยู่กับทั้งนักศึกษา และวิชาที่เรียน • เป็นระบบที่ขาดความยืดหยุ่น เพราะการจัดการมีความยุ่งยาก และซับซ้อนแม้กระทั่งงานพื้นฐาน เช่น การเพิ่มหรือลบ segment นอกจากนี้หากไม่ระมัดระวัง หากลบ segment ที่เป็น parent จะส่งผลให้ลบ Children ของ segment นั้นออกไปด้วย ข้อเสียของ Hierarchical Database Model

46. การสร้างโปรแกรมสำหรับ Application มีความยุ่งยาก และใช้เวลานาน เพราะ Programmer ต้องรู้ตำแหน่งของแต่ละ segment และเรียกใช้ Path ให้ถูกต้อง นอกจากนี้หาก Path มีการเปลี่ยนแปลงต้องเข้ามาเปลี่ยนในตัวโปรแกรมด้วย ข้อเสียของ Hierarchical Database Model

47. Hierarchical database model รองรับเฉพาะความสัมพันธ์ที่เป็น 1:M ทั้ง ๆ ที่ในความเป็นจริง ยังมีข้อมูลอีกมากที่มีความสัมพันธ์แบบ M:N เช่นนักศึกษากับวิชาเรียน ซึ่งไม่สามารถจัดการได้ง่ายบนระบบนี้ A ข้อเสียของ Hierarchical Database Model C B D Many Parents Child

48. ถูกพัฒนาขึ้นเพื่อแก้ปัญหาที่เกิดจาก Hierarchical Database Model นอกจากจะรองรับความสัมพันธ์แบบ 1:M แล้วยังยอมให้ segment ที่เป็น Child มีหลาย Parent ได้ อีกทั้งเป็นความพยายามที่จะพัฒนามาตรฐานสำหรับ database ทั้งนี้เพื่อเพิ่มความสามารถในการโอนถ่ายข้อมูลระหว่าง DBMS Network Database Model

49. โครงสร้างพื้นฐาน ในระบบของ Network database model ความสัมพันธ์หนึ่ง ๆ เรียกว่า set ประกอบด้วย Owner และ member โดย Owner มีค่าเท่ากับ Parent และ member มีค่าเท่ากับ Child ใน Hierarchical Database Model ความแตกต่างระหว่างสองโมเดล นี้อยู่ที่ว่า member สามารถอยู่ได้ในหลาย ๆ set ซึ่งก็หมายความว่า member หนึ่ง ๆ มีหลาย Owner ได้นั้นเอง Network Database Model

50. Member ตัวอย่าง Network model สำหรับ Customer (ลูกค้า) Salesrep (พนักงานขาย) Invoice (ใบสั่งซื้อสินค้า) Invoice_Detail (รายละเอียดใบสั่งซื้อ) Product (สินค้า) Payment (การชำระเงิน) Owner 1 Network Database Model M รูปแสดงโครงสร้าง แบบ Set