1 / 104

ส่วนที่ 2 Database Design

DBMS. Database Management System. ส่วนที่ 2 Database Design. บทที่ 4 โมเดลจำลองความสัมพันธ์ระหว่างข้อมูล (ER-Diagram) บทที่ 5 รูปแบบที่เป็นบรรทัดฐาน (Normalization). วงจรชีวิตการพัฒนาฐานข้อมูล Database Life Cycle : DBLC. วิเคราะห์ความต้องการ Initial Study. ออกแบบฐานข้อมูล

phyre
Download Presentation

ส่วนที่ 2 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. DBMS Database Management System ส่วนที่ 2 Database Design บทที่ 4 โมเดลจำลองความสัมพันธ์ระหว่างข้อมูล (ER-Diagram) บทที่ 5 รูปแบบที่เป็นบรรทัดฐาน (Normalization)

  2. วงจรชีวิตการพัฒนาฐานข้อมูล Database Life Cycle : DBLC วิเคราะห์ความต้องการ Initial Study ออกแบบฐานข้อมูล Database Design บำรุงรักษา Maintenance สร้างฐานข้อมูล Implement and Loading ใช้งานจริง Operation ทดสอบระบบฐานข้อมูล Testing and Evaluation Database Management System

  3. Database Life Cycle :DBLC • Database Initial Study :วิเคราะห์ความต้องการของผู้ใช้ • Data Design :ออกแบบฐานข้อมูล (Data Driven, Joint Data and Function-driven) • Implementation and Loading :สร้างเป็นฐานข้อมูล • Testing and Evaluation :ทดสอบฐานข้อมูลที่สร้าง • Operation :ใช้งานฐานข้อมูล • Maintenance and Evaluation :บำรุงรักษาฐานข้อมูล Database Management System

  4. บทที่ 4 โมเดลจำลองความสัมพันธ์ระหว่างข้อมูล  (ER-Diagram)

  5. Outline • ประโยชน์ของการออกแบบฐานข้อมูล • ขั้นตอนในการออกแบบฐานข้อมูล • ER-Diagram • Map ER to Relation Database Management System

  6. การออกแบบฐานข้อมูลมีประโยชน์อย่างไรการออกแบบฐานข้อมูลมีประโยชน์อย่างไร • เป็นการวางแผนว่าจะเก็บข้อมูลต่างๆ ที่จำเป็นต้องใช้ในระบบงานไว้ในตารางใดบ้าง โดยยังคงมีความสัมพันธ์ระหว่างข้อมูลไว้ได้ และสามารถเรียกดูข้อมูลที่เก็บไว้เพื่อมาใช้งานได้ตามปกติ • มองเห็นความสัมพันธ์ระหว่างข้อมูลทั้งหมดที่มีอยู่ โดยข้อมูลบางตัวอาจจะเกี่ยวข้องกับข้อมูลอื่นๆหลายตัว อาจทำให้เกิดการเก็บรายละเอียดของข้อมูลนั้นซ้ำซ้อนกันได้ Database Management System

  7. ขั้นตอนในการออกแบบฐานข้อมูลขั้นตอนในการออกแบบฐานข้อมูล 1. Requirement Analysis Database Designer (ER-Diagram) 2. Conceptual Design 3. Logical Design (Normalization) 4. Schema Refinement DBA 5. Physical Design 6. Security Design 7. Maintenance Database Management System

  8. 1. สำรวจความต้องการใช้งาน(Requirement Analysis) • เป็นขั้นตอนแรกที่สำคัญมากต่อระบบฐานข้อมูล • จะรู้ความต้องการของผู้ใช้งานและระบบได้อย่างไร Database Management System

  9. จะรู้ความต้องการของผู้ใช้งานได้อย่างไรจะรู้ความต้องการของผู้ใช้งานได้อย่างไร • ศึกษาเอกสารที่ใช้ในระบบงานนั้นๆ • การใช้แบบสอบถาม • การพูดคุยกับผู้ใช้โดยตรง • ข้อมูลที่เราจำเป็นต้องเก็บรวบรวมเพื่อนำไปใช้ในการออกแบบระบบฐานข้อมูล ประกอบด้วย • ข้อมูลแต่ละตัวที่จำเป็นต้องใช้ในระบบงาน(Entity) • รายละเอียดของข้อมูลนั้น(Attribute) • ความสัมพันธ์ระหว่างข้อมูลทั้งหมด(Relationship) Database Management System

  10. ตั้งคำถาม ถามระบบ • วิธีที่จะตรวจสอบว่าความต้องการที่สำรวจได้เพียงพอที่จะใช้งานจริงแล้วหรือไม่ คือ ลองตั้งคำถามที่ต้องการดูว่าข้อมูลที่จะเก็บในฐานข้อมูลสามารถนำมาใช้ตอบคำถามนั้นๆได้ทั้งหมดหรือไม่ • ถ้าตอบได้ ก็แสดงว่าเราไม่ได้ลืมเก็บข้อมูลที่จำเป็นต้องใช้ตัวอื่นอีก Database Management System

  11. 2. ออกแบบฐานข้อมูลระดับแนวคิด(Conceptual Design) • หลังจากได้ความต้องการแล้ว ก็จะทำการออกแบบเชิงแนวคิด(conceptual design) • โดยใช้ตัวแบบข้อมูลเชิงแนวคิด (conceptual data model) เช่น ER-Model ในการออกแบบเค้าร่างเชิงแนวคิด • ผู้ออกแบบฐานข้อมูลจะต้อง • กำหนดเอนติติ้และแอตทริบิวต์ • กำหนดคอนสเตรนต์ • กำหนดความสัมพันธ์ • หลังจากได้เค้าร่างเชิงแนวคิดแล้ว ผู้วิเคราะห์ระบบจะนำเค้าร่างเชิงแนวคิดไปยืนยันกับผู้ใช้ถึงความต้องการทั้งหมด เพื่อให้แน่ใจว่าไม่ได้หลงลืมความต้องการหรือข้อมูลบางส่วนไป Database Management System

  12. 3. ออกแบบฐานข้อมูลระดับตรรกะ(Logical Design) • เมื่อได้ออกแบบเค้าร่างเชิงแนวคิดที่ได้รับการยืนยันจากผู้ใช้แล้ว ก็จะจัดทำการออกแบบเชิงตรรกะ (logical design) เพื่อออกแบบเค้าร่างเชิงตรรกะ(logical schema) ให้เป็นไปตามตัวแบบข้อมูลของระบบการจัดการฐานข้อมูล • เป็นขั้นตอนการแปลง ER-Diagram ไปเป็นตารางตาม Relational data Model Database Management System

  13. 4. ปรับโครงสร้างข้อมูล(Schema Refinement) • ตารางที่ได้จากการออกแบบฐานข้อมูลในระดับ Logical ยังไม่ใช่ตารางที่เหมาะสำหรับนำไปเก็บข้อมูลจริง เนื่องจากอาจทำให้เกิดความซ้ำซ้อนของข้อมูล และปัญหาต่างๆ เช่น ปัญหาการเพิ่มข้อมูล(Insert Anomaly) • ขั้นตอนนี้ เป็นการปรับโครงสร้างตาราง โดยการทำ Normalization ซึ่งจะทำให้ได้จำนวนตารางมากขึ้นกว่าเดิมแต่ปัญหาต่างๆจะถูกกำจัดออกไป Database Management System

  14. 5. ออกแบบฐานข้อมูลระดับกายภาพ(Physical Design) • เป็นหน้าที่ DBA เพื่อให้ระบบฐานข้อมูลเกิดประสิทธิภาพมากที่สุด • การออกแบบในระดับนี้ เกี่ยวข้องกับการสร้างอินเด็กซ์ (Index)และการเลือกโครงสร้างข้อมูลระดับภายใน (Internal View) เพื่อให้สอดคล้องกับลักษณะการใช้งานข้อมูลที่เกิดขึ้นบ่อยๆ เช่น สร้างอินเด็กซ์ที่คอลัมน์ซึ่งมักถูกใช้กำหนดเป็นเงื่อนไขในการดึงข้อมูล Database Management System

  15. 6. ควบคุมการนำไปใช้(Security Design) • เป็นการกำหนดสิทธิในการใช้งานข้อมูลที่ DBA จะกำหนดขึ้นตามความเหมาะสมและความต้องการของผู้ใช้งาน Database Management System

  16. 7. การบำรุงรักษาระบบ(Maintenance Database System) • เป็นขั้นตอนที่มีความสำคัญกับระบบมาก • เมื่อระบบทำงานช้าลง ต้องตรวจสอบ • เมื่อพบข้อผิดพลาดจากข้อมูลที่เก็บ • เมื่อความต้องการของระบบหรือผู้ใช้เปลี่ยนไป • เมื่อนโยบายขององค์กรเปลี่ยนไป • การสำรองข้อมูล เมื่อไร backup / การกู้คืนข้อมูล • การป้องกันไวรัสทุกชนิด โจรกรรมข้อมูล Database Management System

  17. การออกแบบฐานข้อมูล • เป็นเรื่องที่สำคัญมาก เพราะมีผลต่อประสิทธิภาพในการใช้งาน • ควรออกแบบอย่างรอบคอบ • โดยต้องทำความเข้าใจในระบบงานก่อน • เพื่อให้การออกแบบถูกต้องและครอบคลุมงานของระบบทั้งหมด ป้องกันการแก้ไขภายหลังหรือป้องกันความซ้ำซ้อนของงานที่ออกแบบ Database Management System

  18. Entity Relationship Data Model • โดย ดร.ปีเตอร์ เชนน์ ราวปี ค.ศ. 1976 • ER data model จัดเป็น conceptual data model ที่ใช้ออกแบบฐานข้อมูลได้อย่างอิสระ ไม่ต้องคำนึงถึงว่าจะใช้ DBMS ชนิดไหน ยี่ห้ออะไร ด้วยคุณสมบัติเด่นนี้ทำให้ ER-model เป็นที่นิยมใข้งานกันมากในการวิเคราะห์และออกแบบฐานข้อมูล • ผลการออกแบบด้วย ER-model สามารถแสดงด้วยรูปภาพ หรือ ER-Diagram • นักวิเคราะห์และออกแบบสามารถใช้ ER-Diagram เสมือนเป็นเครื่องมือในการอธิบายองค์ประกอบ(Basic Structure) และ ข้อกำหนดเงื่อนไข(Integrity constraint) ของฐานข้อมูล Database Management System

  19. Entity Relationship Data Model(ต่อ) • นำ ER-Diagram ไปใช้ทบทวนยืนยันความเข้าใจที่ถูกต้องกับ user ของระบบงานได้ เพราะ ER-Diagram ประกอบด้วยสัญลักษณ์ที่สื่อความหมายเข้าใจได้ง่าย • เมื่อได้ ER-Diagram ที่ถูกต้องเหมาะสมกับระบบงานแล้วและทราบแล้วว่าจะใช้ DBMS ชนิดใด จึงจะทำการแปลง (Mapping) ให้ได้เป็น Logical schema ที่ตรงกับ DBMS Database Management System

  20. Basic Structure • องค์ประกอบของโครงสร้างข้อมูล โดย ER-model ประกอบด้วยโครงสร้างดังนี้ • Entity • Relationship • Attribute • Primary Key Database Management System

  21. Entity • เอนติตี้(Entity) • สิ่งที่มีอยู่ในขอบเขตของระบบที่เราสนใจ อาจเป็น สิ่งของ คน สถานที การกระทำ เหตุการณ์ โดยแต่ละเอนติตี้จะเก็บเรื่องเดียวกัน • เช่น นักศึกษา , รถยนต์, หนังสือ, การทำผิด, เพลง, การเช่า ,ประวัติการทำงาน, การประมูล, การสัมมนา, น้ำตก , บ้านเช่า เป็นต้น Database Management System

  22. Attribute • ลักษณะหรือคุณสมบัติที่นำมาใช้อธิบายสิ่งต่างๆ(Entity) และความสัมพันธ์ต่างๆ(Relationship) ในระบบงาน • เช่น attribute ที่นำมาอธิบาย Entity ของ ลูกค้า ในระบบงานขายสินค้า • ชื่อ สกุล ที่อยู่ รายได้ สถานภาพ อาชีพ • เช่น attribute ที่นำมาอธิบาย Entity ของ การลดราคา ในระบบงานแสดงสินค้า • ครั้งที่ วันที่เริ่มต้น วันสุดท้าย ชื่อสถานที่จัดงาน • เช่น attribute ที่นำมาอธิบาย Relationship ของซื้อสินค้า ในระบบงานขายสินค้า • วันที่ซื้อ วันที่ต้องการส่งสินค้า จำนวนที่ซื้อสินค้า Database Management System

  23. Relationship • ความสัมพันธ์ระหว่าง entity ต่างๆ ซึ่งเปรียบเทียบได้กับกริยาโครงสร้างของ 1 ประโยค โดยทั่วไปประกอบด้วย ประธาน กริยา กรรม • ประธาน และ กรรม เป็นคำนาม เปรียบเป็น Entity • กริยาแสดงความสัมพันธ์ระหว่างประธานกับกรรม เปรียบเป็น Relationship • เช่น นักศึกษา 1 คน เรียนได้หลายๆวิชาใน 1เทอม Database Management System

  24. Degree of Relationship • Degree ของชนิดความสัมพันธ์ คือ จำนวนของชนิดของ entity ที่มีส่วนร่วมในความสัมพันธ์นั้น • Unary (Recursive) Relationship • ความสัมพันธ์ภายใน entity เดียวกัน • Binary Relationship • ความสัมพันธ์ระหว่าง 2 entities • Ternary Relationship • ความสัมพันธ์ระหว่าง 3 entities Database Management System

  25. ตัวอย่าง ของ Degree of Relationship Unary นักศึกษา m พนักงาน หัวหน้างาน M ลงทะเบียน 1 M วิชาเรียน อาจารย์ Ternary M Binary สอน วิชาเรียน หนังสือ M M Database Management System

  26. Cardinality of Relationships • จำนวน entity ต่อ entity ในความสัมพันธ์ • One to One relationship (1 to 1) • One to Many relationship (1 to M) • Many to Many relationship (M to M) Database Management System

  27. Mapping Cardinalities One to one One to many Database Management System

  28. Mapping Cardinalities Many to one Many to many Database Management System

  29. เป็นคณบดี One to One Relationship • ความสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติตี้แรก สามารถจับคู่กับข้อมูลในเอนติตี้ที่สองได้เพียงแถวเดียวเท่านั้น • เช่น ระบบข้อมูลมหาวิทยาลัย • อาจารย์ 1 คน เป็นคณบดีได้เพียง 1 คณะ และ • แต่ละคณะมีอาจารย์ที่เป็นคณบดีได้คนเดียวเท่านั้น 1 1 อาจารย์ คณะ Database Management System

  30. สั่งซื้อ One to Many • ความสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติตี้แรก สามารถจับคู่กับข้อมูลในเอนติตี้ที่สองได้มากกว่าหนึ่งแถว • เช่น ระบบสั่งซื้อสินค้าของลูกค้า • ลูกค้า1 คนสั่งซื้อใบสั่งซื้อได้หลายใบ และ • ใบสั่งซื้อแต่ละใบถูกสั่งซื้อจากลูกค้าเพียงคนเดียว 1 M ลูกค้า ใบสั่งซื่อ Database Management System

  31. ถูกสั่งซื้อ Many to Many • ความสัมพันธ์ที่แต่ละแถวของข้อมูลในเอนติตี้แรก สามารถจับคู่กับข้อมูลในเอนติตี้ที่สองได้มากกว่าหนึ่งแถว และในทางกลับกันข้อมูลแต่ละแถวของฝั่งเอนติตี้ที่สองก็สามารถจับคู่กับข้อมูลในเอนติตี้แรกได้มากกว่าหนึ่งแถว • เช่น ระบบสั่งซื้อสินค้าของลูกค้า • สินค้า 1 อย่าง ถูกสั่งซื้อตามใบสั่งซื้อได้หลายใบ และ • ใบสั่งซื้อ 1 ใบสั่งซื้อสินค้าได้หลายอย่าง M M ใบสั่งซื้อ สินค้า Database Management System

  32. Primary Key • Attribute หรือ กลุ่มของ attribute ที่แสดงเอกลักษณ์ของสิ่งใดสิ่งหนึ่งได้ ดังนั้นสิ่งต่างๆ จะมีค่า primary key ไม่ซ้ำกันเสมอ Database Management System

  33. E2 E1 R E2 E1 R

  34. สัญลักษณ์ของ ER Model ER-Model ตามแบบของ Peter Pin Shan Chen Database Management System

  35. สัญลักษณ์ของ ER model(ต่อ) Database Management System

  36. สัญลักษณ์ของ ER Model(ต่อ) Database Management System

  37. สัญลักษณ์ของ ER model(ต่อ) E2 E1 R Database Management System

  38. สัญลักษณ์ของ ER model(ต่อ) E2 E1 R Database Management System

  39. Participation Constraint • เงื่อนไขการมีส่วนร่วม คือ จำนวนต่ำสุดของentity ที่อีก entityหนึ่งมีความสัมพันธ์ด้วย มี 2 แบบคือ • Total Participation • การที่ entity หนึ่งentity จะต้องมีความสัมพันธ์กับentity อื่นอย่างน้อยหนี่ง entity เช่น อาจารย์ทุกคนต้องสังกัดอย่างน้อยใน หนี่งคณะ เป็นต้น การมีส่วนร่วมทั้งหมดจะแสดงด้วยเส้นคู่ทางด้านชนิดของentityที่ทุกentity ในชนิดนั้นต้องเข้าร่วมในความสัมพันธ์ อาจารย์ สังกัด M 1 คณะ Database Management System

  40. Participation Constraint(ต่อ) • Partial Participation • การที่entity หนึ่งentity มีความสัมพันธ์กับentity อื่นอย่างน้อยศูนย์entity คือในชนิดของentity เดียวกันอาจมีบางentity ที่มีส่วนร่วมในความสัมพันธ์นั้น ในขณะที่บางentity ที่ไม่มีส่วนร่วมในความสัมพันธ์นั้นเลย เช่น แผนกบางแผนกไม่มีพนักงานสังกัดเลย และบางแผนกอาจมีพนักงานสังกัดหลายคน • การมีส่วนร่วมบางส่วนจะแสดงโดยใช้เส้นเดียวด้านชนิดของentity ที่บางentityในชนิดนั้นมีส่วนร่วมในความสัมพันธ์ เช่น เส้นเดียวจากentity แผนก อาจารย์ สังกัด M 1 แผนก Database Management System

  41. ประเภทของ attribute • Simple Attribute คือ แอตทริบิวที่เก็บค่าได้เพียงค่าเดียวเท่านั้น เช่น รหัสลูกค้า ลูกค้า 1 คนมีรหัสลูกค้าได้หมายเลขเดียว • Multi-valued attribute คือ แอตทริบิวต์ที่เก็บค่าได้ตั้งแต่ 1 ค่าขึ้นไป เช่น เบอร์โทรศัพท์ ของลูกค้า มีทั้งเบอร์บ้าน เบอร์มือถือ เป็นต้น ลูกค้า เบอร์โทรศัพท์ Database Management System

  42. ประเภทของแอตทริบิวต์(ต่อ)ประเภทของแอตทริบิวต์(ต่อ) • Composite attribute คือแอตทริบิวต์ที่ประกอบด้วยแอตทริบิวต์หลายตัวมารวมกันจึงให้ความหมายที่ชัดเจน จังหวัด ชื่อ สกุล ถนน อำเภอ ชื่อ-สกุล ที่อยู่ ลูกค้า Database Management System

  43. ประเภทของแอตทริบิวต์(ต่อ)ประเภทของแอตทริบิวต์(ต่อ) • Derived attribute คือ แอตทริบิวต์ที่เก็บผลการคำนวณหรือแปลงค่ามาจากแอตทริบิวต์อื่นๆ เช่น จำนวนเงิน(ราคา*จำนวน) จำนวนพนักงาน แผนก รหัสแผนก Database Management System

  44. Weak Entity • Weak entity ต้องมีคุณสมบัติ 2 ข้อ คือ 1. ไม่มี Primary Key มีเพียง partial key (ซึ่งเป็นค่าที่ซ้ำกันได้) ดังนั้นนำเอา partial key ไปรวมกับ Primary key ของ Strong Entity ก็จะเป็นค่าที่ไม่ซ้ำได้ 2. Weak entity ต้องมีความสัมพันธ์กับ Strong Entity อย่างน้อย 1 entity คือ ลักษณะของการขึ้นต่อกัน คือ การที่เอนติตี้หนึ่งจะเกิดขึ้นได้นั้น ขึ้นกับอีกเอนติตี้หนึ่งว่าปรากฏอยู่หรือไม่ Database Management System

  45. ลำดับที่ มี ญาติ 1 M พนักงาน Weak Entity (ต่อ) • ตัวอย่าง เอนติตี้พนักงานและเอนติตี้ญาติ ถ้าไม่มีเอนติตี้พนักงาน เอนติตี้ญาติก็จะไม่เกิดขึ้น • เอนติตี้ญาติ เป็น Weak Entity • เอนติตี้พนักงาน เป็น Entity รหัสพนักงาน -ญาติ เป็น weak entity ที่ไม่มี primary key โดยคุณสมบัติ ลำดับที่ มีค่าซ้ำกันในรีเลชั่น ญาติ เพราะคุณสมบัติ ลำดับที่ มีค่าซ้ำๆ กันได้ในหลายญาติ เช่น ลำดับที่ 1 เป็นญาติ นายขาว และลำดับที่ 1 เป็นญาติ นายแดง -ฝั่งชนิดของentity ญาติ เป็นแบบ Total Participation Database Management System

  46. Weak Entities(ต่อ) รหัสวิชา วิชา ชื่อวิชา(รหัสวิชา, ชื่อวิชา) วิชาที่เปิดสอน(รหัสวิชา*, ปี-ภาค, กลุ่ม, เวลาเรียน) ชื่อวิชา 1 ปี-ภาค เปิดสอน รหัสการเปิดสอน กลุ่ม M เวลาเรียน วิชาที่เปิดสอน

  47. ตัวอย่าง Recursive Relationships • ตัวอย่าง การลงทะเบียนบางวิชา จะต้องเรียนวิชาอื่นมา 1 วิชา (one to one) วิชาที่ลงทะเบียน 1 Course Precond. วิชาที่ต้องผ่านก่อน 1 Course(CourseID, CourseName, Unit, PrecondCourseID*) Database Management System

  48. Recursive Relationships(ต่อ) 4123601 Database Management System

  49. ตัวอย่าง Recursive Relationships • ตัวอย่าง การลงทะเบียนบางวิชา จะต้องเรียนวิชาอื่นมา 1 วิชาหรือหลายๆวิชา (many to many) วิชาที่ลงทะเบียน m Course Precond. วิชาที่ต้องผ่านก่อน m Precondition(CourseID, PrecondCourseID) Course(CourseID , CourseName, Unit)

  50. Recursive Relationships(ต่อ) Course Precondition

More Related