ระบบการจัดการฐานข้อมูล บทที่ 3 การวิเคราะห์ (Analysis) V.2507201301 ระบบการจัดการฐานข้อมูล บทที่ 3 การวิเคราะห์ (Analysis) ผู้ช่วยศาสตราจารย์ปริญญา น้อยดอนไพร สาขาวิชาวิทยาการคอมพิวเตอร์ คณะวิทยาศาสตร์และเทคโนโลยี มหาวิทยาลัยราชภัฏสุราษฎร์ธานี

วัตถุประสงค์ นักศึกษาสามารถ อธิบายการวิเคราะห์ระบบได้ เขียนแผนภาพที่เกี่ยวข้องกับการวิเคราะห์ระบบได้

ความสำคัญของการวิเคราะห์ เพื่อให้ทราบถึงความเป็นไปและเป็นมาของระบบ และขั้นตอนในการปฏิบัติงานของระบบ ก่อนการสร้างบ้าน ผู้สร้างย่อมมีความต้องการทราบรายละเอียดถึงตัวอาคารที่จะจัดสร้าง เพื่อให้ตรงตามความต้องการของผู้อยู่อาศัย เช่นเดียวกันกับระบบ ก่อนจะมีการสร้างระบบ ผู้สร้างระบบก็ย่อมต้องการทราบความเป็นไปและเป็นมาของระบบ เพื่อการออกแบบระบบใหม่ที่ตรงตามความต้องการของผู้ใช้ให้มากที่สุด

ความสำคัญของการวิเคราะห์ (ต่อ) อุปกรณ์ที่มักนำเอามาพิจารณาและวิเคราะห์ระบบ (แบบแปลนระบบ) แผนภาพบริบท (Context Diagram) แผนภาพกระแสข้อมูล (Data Flow Diagram) E-R Diagram System Flow Chart / Flow Chart etc. ความผิดพลาดของโปรแกรมเมอร์มากมายที่ออกแบบระบบโดยไม่ผ่านการวิเคราะห์ ก่อให้เกิดผลเสียมากมาย เช่น เวลา, ค่าใช้จ่าย

แผนภาพกระแสข้อมูล (Data Flow Diagram) DFD คือ แผนภาพกระแสข้อมูลที่มีการวิเคราะห์แบบในเชิงโครงสร้าง (Structure) ซึ่งเป็นแผนภาพที่บอกถึงรายละเอียดของระบบ โดยเฉพาะข้อมูล และผังการไหลของข้อมูล สิ่งที่ได้จาก DFD ประกอบด้วย ข้อมูลมาจากไหน ข้อมูลไปที่ใด ข้อมูลเก็บที่ใด เกิดเหตุการณ์ใดกับข้อมูลบ้าง

DFD (ต่อ) ขั้นตอนของการวิเคราะห์เพื่อสร้าง DFD 1. ศึกษารูปแบบการทำงานในลักษณะ Physical ระบบงานเดิม 2. ดำเนินการวิเคราะห์เพื่อให้ได้แบบจำลอง Logical ระบบงานเดิม 3. เพิ่มเติมการทำงานใหม่ภายในแบบจำลอง Logical ระบบงานเดิม 4. พัฒนาระบบงานใหม่ในรูปแบบของ Physical

DFD (ต่อ)

ดังนั้น DFD จึงมีความสำคัญมากต่อการพัฒนาระบบ เป็นแผนภาพสรุปรวมข้อมูลทั้งหมดที่ได้จากการวิเคราะห์ เป็นข้อตกลงร่วมกันระหว่าง SA และ User เป็นแผนภาพที่ใช้ในการพัฒนาต่อในขั้นตอนออกแบบ เป็นแผนภาพที่ใช้ในการอ้างอิง หรือเพื่อใช้พัฒนาต่อ ทราบที่ไปที่มาของกระบวนการต่าง ๆ ดังนั้น DFD จึงมีความสำคัญมากต่อการพัฒนาระบบ ซึ่ง SA หรือ Programmer ไม่สามารถมองข้ามได้

ตัวอย่าง DFD

สัญลักษณ์ที่ใช้ในแผนภาพกระแสข้อมูล

DFD Format (เปรียบเทียบ)

กฎเกณฑ์การเขียนแผนภาพกระแสข้อมูล สัญลักษณ์ของแผนภาพไม่สามารถเชื่อมต่อกันได้โดยตรง ซึ่งต้องมี Flow บอกทิศทางของกระแส (Flow ระบุข้อมูล) และการ Flow ทุกครั้งจะต้องผ่าน Process ก่อนทุกครั้ง (ไม่ผ่านไม่ได้) Process = กิริยา Flow = ข้อมูล Boundaries, Entity = องค์กร, หน่วยงาน, ผู้ใช้งานระบบ

กฎเกณฑ์ (ต่อ)

กฎเกณฑ์ (ต่อ)

ขั้นตอนการเขียน DFD 1. วิเคราะห์ให้ได้ว่าระบบประกอบไปด้วย Boundaries ใดบ้างที่เกี่ยวข้อง 2. ดำเนินการออกแบบระบบในระดับหลักการ หรือ Context Diagram (บ้างก็เรียกว่าแผนภาพบริบท) 3. วิเคราะห์ข้อมูลในระบบว่าควรมีข้อมูลใดบ้าง 4. วิเคราะห์กระบวนการหรือ Process ในระบบว่า ควรมี Process หลักใด และประกอบไปด้วย Process ย่อยใดบ้าง (ควรสร้างแบบมีหลักการของระบบ) 5. ดำเนินการเขียนแผนภาพกระแสข้อมูลในระดับต่าง ๆ 6. ทำการตรวจสอบ Balancing และปรับแก้ Redraw จนได้แผนภาพที่สมบูรณ์ 7. อาจใช้ CASE Tools ช่อยในการเขียนแผนภาพ

การวิเคราะห์ข้อมูลก่อนการออกแบบแผนภาพ ก่อนที่จะมีการเขียน Context Diagram ควรจะเขียน List ต่าง ๆออกมาเพื่อทำให้ทราบลักษณะการทำงานของระบบโดยภาพรวม ซึ่งจำเป็นต้องมี List ต่าง ๆ ดังนี้ 1. List of Boundaries วิเคราะห์ว่ามีใครหรือว่าหน่วยงานใดเกี่ยวข้องกับระบบบ้าง 2. List of Data วิเคราะห์ว่าในระบบมีข้อมูลใดเกิดขึ้นมาบ้าง 3. List of Process วิเคราะห์ว่าระบบมีกระบวนการทำงานใดบ้าง เมื่อทำการวิเคราะห์สิ่งต่าง ๆ ออกมาแล้วก็นำมาเขียน ตัวอย่างดัง Slide ถัดไป

List of Object List of Object in DFD

Boundaries สามารถเป็นได้ทั้ง บุคคล, องค์กร, หน่วยงาน ซึ่งในการพิจารณาเพื่อระบุลงไปใน DFD จะพิจารณาถึงส่วนที่ระบบไม่สามารถควบคุมได้ แต่มีส่วนเกี่ยวข้องกับระบบ

Data Store คือแหล่งเก็บข้อมูล เช่น ข้อมูลนักศึกษา, ข้อมูลบุคลากร โดยภายในสัญลักษณ์สามารถที่จะมีเลขประจำข้อมูลระบุได้ ลูกศรจาก Data Store หมายถึง Input ลูกศร Process ไปยัง Data Store หมายถึง Output ลูกศรสองทาง หมายถึง Input/Output

Process คือ กระบวนการที่ต้องทำในระบบ โดยจะพิจารณาจะกิริยาหรือการกระทำภายในระบบเป็นหลัก ซึ่งภายใน 1 แผนภาพ ไม่ควรมี Process มากเกินไป ในการเขียน Process จะต้องมีหมายเลขกำกับอยู่ด้วย เป็นลำดับชั้นไล่ไปเรื่อย ๆ เพื่อให้ทราบว่า Process ใด มาจาก Process ใด

การเขียนแผนภูมิโครงสร้าง Structure Chart หรือบ้างก็เรียกว่า Process Hierarchy Chart แบ่งตามลักษณะของกิจกรรม หรือแบ่งงานใหญ่ออกเป็นโมดูลย่อยๆ เรียกว่าการออกแบบจากบนลงล่าง (Top-Down Design) ช่วยให้เห็นภาพรวมโครงสร้างทั้งหมดของระบบ ทำให้ง่ายในการออกแบบ แผนภาพกระแสข้อมูล (DFD) ในระดับต่างๆ ข้อควรระวัง !! ไม่ควรนำเอารายละเอียดที่ต่างความสำคัญมาไว้ในชั้นเดียวกัน (ความสัมพันธ์ต่างระดับ เพราะจะทำให้เกิดความสับสน ในการออกแบบหรือเขียน DFD ในระดับอื่น ๆ)

ตัวอย่าง Structure Chart หรือ Process Hierarchy Chart 1.0 2.0 3.0 4.0 5.0 ปิด/เปิด ภาคการศึกษา

แผนภาพกระแสข้อมูล (DFD : Data Flow Diagram) แผนภาพบริบท (Context Diagram) เป็นแผนภาพที่แสดงภาพรวมสูงสุดของระบบ ซึ่งจะแสดงถึงสิ่งแวดล้อมของระบบและองค์ประกอบหลัก ๆ เท่านั้น โดยที่จะมีเพียง 1 Process ซึ่งเป็นชื่อของระบบ (0) และไม่มี Data Store ปรากฏอยู่ใน Context Diagram โดยเด็ดขาด แสดงภาพรวมการทำงานของระบบที่สัมพันธ์กับสภาพแวดล้อมภายนอกระบบ กำหนดขอบเขตของระบบที่จะพัฒนาได้

ตัวอย่างที่ 2 แผนภาพบริบท

DFD Level 0 จะนำ Context Diagram มาแตกรายละเอียดภายใน ซึ่งจะแสดงถึง Process หลัก ๆ, ผู้เกี่ยวข้อง, ข้อมูลภายใน ที่มีความละเอียดมากขึ้น (Top down Design) ในระดับนี้จะปรากฏทุก ๆ ชนิดของ Object DFD จะต้องมีการกำกับหมายเลข Process ด้วยเลข 0 หลักการ เขียนในกระดาษแผ่นเดียว ลูกศรไม่ทับกัน โดยนำเอามาเฉพาะ Object ที่จำเป็น ควรจัดการลำดับแผนภาพเป็นลำดับแบบ Process Hierarchy Chart (นำภาพออกมาทีละลำดับขั้น ลดความสับสน)

ตัวอย่าง DFD Level 0

DFD Level 1 เป็นแผนภาพ DFD ในระดับย่อยลงมา ที่แสดงรายละเอียด Data Flow และ Process ย่อยลงมาของ DFD Level 0 เพื่อเพิ่มความละเอียดของกระบวนการมากยิ่งขึ้น แต่ตั้งแต่ Level ที่ 1 ลงไป จะมีแผนภาพนี้ขึ้นตามความจำเป็นเท่านั้น (ซึ่งขึ้นอยู่กับความซับซ้อนของข้อมูล และกิจกรรมที่ต้องการแตกรายละเอียด)

ตัวอย่าง DFD Level 1 (P.1)

ตัวอย่าง DFD Level 1 (P.2)

ตัวอย่าง DFD Level 1 (P.3)

ตัวอย่าง DFD Level 1 (P.4)

ตัวอย่าง DFD Level 1 (P.5)

DFD Level 2 (P 2.2)