1 / 55

Chapter 3 การออกแบบฐานข้อมูล (Database Design)

Chapter 3 การออกแบบฐานข้อมูล (Database Design). โดยอาจารย์ เกศแก้ว ประดิษฐ์ สาขาวิชาการจัดการเทคโนโลยีสารสนเทศ Kate_psu08@hotmail.com. เนื้อหาที่เรียนในบทนี้ วงจรการพัฒนาระบบสารสนเทศ ( System Development Life Cycle ) วงจรการพัฒนาระบบฐานข้อมูล ( Database Life Cycle )

landis
Télécharger la présentation

Chapter 3 การออกแบบฐานข้อมูล (Database Design)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Chapter 3การออกแบบฐานข้อมูล (Database Design) โดยอาจารย์ เกศแก้ว ประดิษฐ์ สาขาวิชาการจัดการเทคโนโลยีสารสนเทศ Kate_psu08@hotmail.com

  2. เนื้อหาที่เรียนในบทนี้ • วงจรการพัฒนาระบบสารสนเทศ (System Development Life Cycle) • วงจรการพัฒนาระบบฐานข้อมูล ( Database Life Cycle) • ขั้นตอนการออกแบบฐานข้อมูล • Entity Relationship model • Normalization Database Design

  3. การพัฒนาระบบสารสนเทศ โดยทั่วไปจะดำเนินตามขั้นตอนที่กำหนดไว้ใน System Development Life Cycle (SDLC) • ศึกษาความเป็นไปได้ (Feasibility study) เป็นขั้นตอนที่เกี่ยวข้องกับการประเมินต้นทุนของทางเลือกต่างๆ ของการพัฒนาระบบงานสารสนเทศ เพื่อพิจารณาเลือกทางเลือกในการพัฒนาระบบสารสนเทศที่คุ้มค่าที่สุด วงจรชีวิตของการพัฒนาระบบงานสารสนเทศ

  4. การพัฒนาระบบสารสนเทศ โดยทั่วไปจะดำเนินตามขั้นตอนที่กำหนดไว้ใน System Development Life Cycle (SDLC) • รวบรวมความต้องการและวิเคราะห์ข้อมูล (Requirement Collection and Analysis) เป็นขั้นตอนในการจัดเก็บรวบรวมความต้องการต่างๆ จากผู้ใช้ User Requirement) มาวิเคราะห์ เพื่อจำแนกถึงปัญหา และความต้องการออกเป็นกลุ่ม เพื่อกำหนดขอบเขตให้กับระบบสารสนเทศที่จะพัฒนางานอื่น ๆ วงจรชีวิตของการพัฒนาระบบงานสารสนเทศ

  5. การพัฒนาระบบสารสนเทศ โดยทั่วไปจะดำเนินตามขั้นตอนที่กำหนดไว้ใน System Development Life Cycle (SDLC) • ออกแบบ (Design) เป็นขั้นตอนที่นำมาปัญหาและความต้องการด้านต่างๆ ที่จำแนกไว้ในขั้นตอนรวมรวมความต้องการมาใช้ในการออกแบบ • สร้างต้นแบบ (Prototype) เป็นขั้นตอนที่นำเอาส่วนต่างๆ ที่ได้ออกแบบไว้ในขั้นตอนที่ 3 มาพัฒนาเป็นต้นแบบของระบบงาน เพื่อนำไปทดลองหาข้อผิดพลาดของระบบงานก่อนนำไปใช้งานจริง ในกรณีที่มีข้อผิดพลาดเกิดขึ้นรายละเอียดของข้อผิดพลาดต่างๆ จะนำไปเป็นข้อมูลในการรวบรวมความต้องการใหม่ วงจรชีวิตของการพัฒนาระบบงานสารสนเทศ

  6. การพัฒนาระบบสารสนเทศ โดยทั่วไปจะดำเนินตามขั้นตอนที่กำหนดไว้ใน System Development Life Cycle (SDLC) • ติดตั้ง (Implementation) เป็นขั้นตอนที่นำเอาระบบงานสารสนเทศที่พัฒนาเสร็จเรียบร้อยไปทดลองใช้งาน • ตรวจสอบความถูกต้องและทดสอบโปรแกรม (Validation and Testing) เป็นขั้นตอนการตรวจสอบความถูกต้องของระบบงานสารสนเทศที่พัฒนาขึ้น • นำไปใช้งาน (Operation) เป็นขั้นตอนสุดท้าย ที่มั่นใจว่าสามารถทำงานได้อย่างถูกต้องก่อนใช้งานจริง วงจรชีวิตของการพัฒนาระบบงานสารสนเทศ

  7. วงจรชีวิตของการพัฒนาระบบงานสารสนเทศวงจรชีวิตของการพัฒนาระบบงานสารสนเทศ

  8. วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle : DBLC) • Database Initial study เป็นขั้นตอนแรกของการพัฒนาระบบฐานข้อมูล ต้องวิเคราะห์ความต้องการ เพื่อกำหนดจุดมุ่งหมาย ปัญหา ขอบเขต และกฎระเบียบต่างๆ ของระบบฐานข้อมูล • Database Design เป็นขั้นตอนที่นำเอารายละเอียดต่างๆ ที่ได้จากการวิเคราะห์นำมากำหนดเป็นแนวทางในการออกแบบฐานข้อมูล แบ่งเป็น 3 ระดับ Conceptual Logical และ Physical วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle)

  9. วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle : DBLC) • Implementation and Evaluation เป็นขั้นตอนที่นำเอาโครงสร้างต่างๆ ของระบบฐานข้อมูลที่ได้จากการออกแบบในขั้นตอน Database Design มาสร้างเป็นฐานข้อมูลที่ใช้เก็บข้อมูลจริง รวมทั้งแปลงข้อมูลของระบบงานเดิมให้สามารถนำมาใช้งานในระบบฐานข้อมูลที่พัฒนาขึ้นใหม่ วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle)

  10. วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle : DBLC) • Testing and Evaluation เป็นขั้นตอนการทดสอบระบบฐานข้อมูลที่พัฒนา เพื่อหาข้อผิดพลาดต่างๆ รวมทั้งทำการประเมินความสามารถของระบบฐานข้อมูล เพื่อนำไปใช้เป็นแนวทางในการปรับปรุงระบบฐานข้อมูลตามต้องการ วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle)

  11. วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle : DBLC) • Operation เป็นขั้นตอนที่นำเอาระบบฐานข้อมูลที่พัฒนาเสร็จเรียบร้อยแล้วไปใช้งานจริง • Maintenance and Evolution เป็นขั้นตอนที่เกิดขึ้นระหว่างการใช้งานระบบฐานข้อมูลจริง เพื่อบำรุงรักษาระบบฐานข้อมูลทำงานได้อย่างมีประสิทธิภาพ รวมทั้งเป็นขั้นตอนการแก้ไขและปรับปรุงระบบฐานข้อมูลในกรณีที่มีการเพิ่มหรือเปลี่ยนแปลงความต้องการของผู้ใช้ วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle)

  12. วงจรชีวิตของการพัฒนาระบบฐานข้อมูล (Database Life Cycle)

  13. Planning • ระบบฐานข้อมูลจะรองรับงานอะไร • ทรัพยากรที่จำเป็นต้องใช้ รวมถึงงบประมาณต่าง ๆ • นโยบายด้านความปลอดภัย • ประสิทธิภาพในการทำงาน ขั้นตอนการพัฒนาฐานข้อมูล

  14. Database System Definition • ขอบเขตของฐานข้อมูล • กลุ่มผู้ใช้งาน • การขยายงานในอนาคต • ความสัมพันธ์กับหน่วยงานอื่น ๆ ขั้นตอนการพัฒนาฐานข้อมูล

  15. Database Analysis • การรวบรวมข้อมูล • รายการ Transaction ที่เกิดขึ้น • Data Flow Diagram (DFD) ขั้นตอนการพัฒนาฐานข้อมูล

  16. Database Design • Conceptual Data Model อธิบายโครงสร้างหลักของข้อมูลภายในระบบฐานข้อมูล ซึ่งคือแบบจำลองข้อมูลต่างๆ เช่นE-R Diagram • Logical Data Model นำโครงสร้างหลักของข้อมูลตามแบบจำลอง มาออกแบบฐานข้อมูลให้นำมาใช้งานจริงได้ เช่น Relational Database ขั้นตอนการพัฒนาฐานข้อมูล

  17. Database Design • Physical Data Model คือ การปรับปรุงโครงสร้างของโครงร่างที่ออกแบบขึ้นมา ปรับปรุงโครงสร้างให้เป็นไปตามโครงสร้างของผลิตภัณฑ์ด้านฐานข้อมูลที่นำมาใช้แทน ซึ่งแต่ละผลิตภัณฑ์จะมีโครงสร้างของผลิตภัณฑ์มีโครงสร้างแตกต่างกัน เช่น ประเภทของข้อมูล โครงสร้างในการจัดเก็บ และวิธีการในการเข้าถึงข้อมูล เป็นต้น ผลลัพธ์ที่ได้จากการออกแบบในระดับนี้ โครงสร้างของระบบฐานข้อมูลที่สามารถนำไปใช้งานในการสร้างตัวฐานข้อมูลจริง เช่น RDBMS (MS Access , SQL Server , Oracle) ขั้นตอนการพัฒนาฐานข้อมูล

  18. ขั้นตอนของการออกแบบฐานข้อมูลทั้ง 3 แบบ

  19. Application Design • Transaction Design • User Interface Design • DBMS Selection • งบประมาณ • การสนับสนุนหลังการขาย • ระบบปฏิบัติการ • คุณลักษณะของฮาร์ดแวร์ • Transaction, Recovery and Security ขั้นตอนการพัฒนาฐานข้อมูล

  20. Implemention • Parallel–Replace • Maintenance • Backup • Performance ขั้นตอนการพัฒนาฐานข้อมูล

  21. BusinessRules กฎในการดำเนินธุรกิจใด ๆ เช่น • Businessrulesandpoliciesarenotuniversal. เงื่อนไขการลงทะเบียนรายวิชาเดียวกันแต่ต่างสถาบันจะไม่เหมือนกัน • Businessrulesandpoliciesmaychangeovertime. เงื่อนไขต่าง ๆ โดยส่วนใหญ่จะใช้เวลานานก่อนที่จะมีการเปลี่ยนแปลง ขั้นตอนการพัฒนาฐานข้อมูล

  22. Characteristics of A Good Business Rule–Declarative • อธิบายสิ่งที่ต้องการควบคุมโดยไม่ระบุวิธีการ • Precise • อธิบายความหมายชัดเจน กระชับได้ใจความ • Consistent • ไม่ขัดแย้ง หรือซ้ำซ้อนกับกฎข้ออื่น ๆ • Expressible • ใช้ภาษาที่เจ้าของระบบอ่านแล้วเข้าใจ • Business-oriented • ตรงตามเงื่อนไขของระบบ Business Rule

  23. Entity-Relationship Model คิดค้นโดย Chen ในปีค.ศ.1976 ใชสำหรับสร้าง Conceptual Database Model ในขั้นตอนของ การออกแบบฐานข้อมูล ไมขึ้นอยู่กับรูปแบบของฐานข้อมูลใด ๆ Entities และ Relationship เป็นสิ่งที่ปรากฏอยู่จริง ทำให้ สามารถใช้ในการอธิบายขอบเขตของฐานข้อมูลได้ง่าย Entity-Relationship Model

  24. ดังที่ได้กล่าวมาแล้วว่า Database Model แบ่งออกได้เป็น 2 ประเภทคือ Conceptual model และ Implementation model บทที่แล้ว ได้ศึกษาถึงคุณสมบัติของ Relational Database Model ซึ่งเป็นImplementation model ในบทนี้จะได้เรียนเรื่องการออกแบบฐานข้อมูล คือ การสร้างแบบจำลองที่เป็น Conceptual model ซึ่งจะทำให้สามารถมองเห็นภาพรวมของฐานข้อมูล Entity-Relationship Model ซึ่งเป็น Conceptual Model ที่ได้รับการนิยมอย่างแพร่หลายในปัจจุบัน Entity-Relationship Model

  25. สัญลักษณ์ E-R Model

  26. ตัวอย่าง สัญลักษณ์ E-R Model

  27. องค์ประกอบหลักของ E-R Model คือ Entity , Attribute และ Relationship มีสัญลักษณ์ที่ใช้เป็นตัวแทนขององค์ประกอบเหล่านี้ Entity คือสิ่งต่าง ๆ ที่สามารถระบุได้ในความเป็นจริง ซึ่งอาจเป็นสิ่งที่จับต้องได้เช่น คน สัตว์ สิ่งของ สถานที่และเหตุการณ์ หรือสิ่งที่จับต้องไม่ได้ เช่น จำนวนวันหยุดนักขัตฤกษ์ จำนวนวันลาพักร้องของพนักงาน เป็นต้น ซึ่งเมื่อนำ Entity มารวมกันภายใต้คุณลักษณะใดคุณลักษณะหนึ่งที่เหมือนกันแล้ว Entity เหล่านั้นก็ถูกเรียกว่า Entity Set E-R Model Component

  28. ตัวอย่าง Entity • บุคคล เช่น นักเรียน พนักงาน ผู้ป่วย ฯลฯ • สถานที่ เช่น จังหวัด ประเทศ มหาวิทยาลัย ฯลฯ • วัตถุ เช่น เครื่องจักร โทรศัพท์มือถือ อาคาร ฯลฯ • เหตุการณ์ เช่น การขาย ใบสั่งซื้อ ใบเสร็จรับเงิน ฯลฯ • อื่น ๆ เช่น บัญชี รายวิชา สินค้าคงคลัง E-R Model Component

  29. สัญลักษณ์ E-R

  30. Attribute คือ Entity ที่มีคุณลักษณะที่แตกต่างกันออกไป เช่น • Entity นักเรียน มี Attribute คือ รหัสนักศึกษา ชื่อนักศึกษา เกรดเฉลี่ย รายวิชา วันที่เข้าเรียน ที่อยู่ • Entity เครื่องบิน มี Attribute คือ หมายเลขเครื่อง ชื่อเครื่องบิน วันสุดท้ายของการซ่อมแซม ระยะเวลาการบิน เป็นต้น E-R Model Component

  31. Attribute ใน E-R Model มีความหมายเดียวกันกับ attribute ใน Relational Database Model โดยสามารถเขียนเป็นสัญลักษณ์อย่างง่าย Table_Name (Key_Attribute , Attribute1 , Attribute2 , …) ตัวอย่างเช่น Student(Student_ID , Name ,Address) E-R Model Component

  32. Composit Attribute คือ attribute ที่มีค่าข้อมูลสามารถแบ่งเป็น attribute ย่อย ๆ ได้หากต้องการ เช่น Address แบ่งได้เป็น Street , City , State , Country เป็นต้น หรือ Name อาจแบ่งได้เป็น Title (นาย , นาง , นางสาว) , FirstName , LastName , Middle name Simple Attribute คือ attribute ที่มีค่าข้อมูลที่ไม่สามารถแบ่งย่อยออกไปได้อีกแล้ว เช่น Age , Sex , Marital Status เป็นต้น Composit & Simple Attribute

  33. Composit Attribute

  34. Single-value attribute คือ ค่าของข้อมูล attribute ที่มีเพียงค่าเดียว เช่น ชื่อ (มีชื่อเดียวนามสกุลเดียว) , เพศ , นามสกุล , อาชีพ , เงินเดือน , ฯลฯ Multi-value attribute คือ ค่าของข้อมูล attribute ที่มีหลายค่าใน attribute ตัวเดียว เช่น ทักษะความสามารถ , วุฒิการศึกษา เป็นต้น ดังรูปด้านล่างนี้ Single & Multi-Value Attribute

  35. ตัวอย่าง Attribute Derived Attribute Multi-value attribute

  36. Identifier attribute คือ Attribute ที่มีค่าข้อมูลเป็นเอกลักษณ์เฉพาะของแต่ Entity Identifier Attribute

  37. Composit Identifier

  38. ปกครอง ผู้ว่าราชการจังหวัด จังหวัด Relationship ใน E-R Model แบ่งออกเป็น 3 ประเภท คือ one-to-one , one-to-many และ many-to-many • One-to-One Relationship(1:1) ตัวอย่างเช่น ความสัมพันธ์ระหว่าง Entityผู้ว่าราชการจังหวัด กับ Entity จังหวัด เป็น 1:1 เพราะ • ผู้ว่าราชการจังหวัดแต่ละคนปกครองจังหวัดได้เพียงจังหวัดเดียว • จังหวัดแต่ละจังหวัดปกครองโดยผู้ว่าราชการจังหวัดเพียงคนเดียว Relationship

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

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

  41. จดทะเบียน สมรส ควบคุม บุคคล พนักงาน • Unary Relationship คือ ความสัมพันธ์ที่เกิดขึ้นภายใน Entity เดียวกัน Degree of Relationship

  42. อยู่ใน วาด ประเภทสินค้า จิตรกร สินค้า ภาพ • Binary Relationship คือ ความสัมพันธ์ที่เกิดขึ้นระหว่าง 2 Entity Degree of Relationship

  43. อยู่ใน วาด ประเภทสินค้า จิตรกร สินค้า ภาพ

  44. บริจาค ผู้บริจาคเงิน นักวิจัย กองทุน/มูลนิธิ • Ternary Relationship คือ ความสัมพันธ์ที่เกิดขึ้นระหว่าง 3 Entity Degree of Relationship

  45. ตัวอย่างข้อมูลในตาราง Ternary Relationship ตารางผู้บริจาค (Contributor) ตารางกองทุน (Fund) Degree of Relationship

  46. ตัวอย่างข้อมูลในตาราง Ternary Relationship ตารางนักวิจัย (Recipients) ตารางการบริจาค (CFR) Degree of Relationship

  47. สัญลักษณ์ E-R Model

  48. M N รับผิดชอบ Employee Project • ระดับการมีส่วนร่วมใน Relationship มี 2 ชนิดคือ Optional และ Mandatory • Optional (ไม่จำเป็น) Optional ไม่บังคับว่าจะต้องมีความสัมพันธ์ของสมาชิกใน Entity เช่น Employee อาจรับผิดชอบ Project มากกว่า 1 Project หรือไม่รับผิดชอบเลยก็ได้ แต่ Project แต่ละตัวต้องมี Employee รับผิดชอบอย่างน้อย 1 คน Relationship Cardinality

  49. Mandatory (จำเป็น) Mandatory บังคับว่าจะต้องมีความสัมพันธ์ระหว่างสมาชิกของ Entity Patient 1 คน จะต้องมี Patient History อย่างน้อย 1 ใบ และ Patient History 1 ใบ จะต้องเป็นของ Patient หนึ่งคนเท่านั้น Relationship Cardinality 1 M มี Patient Patient History

More Related