DFD​ ​คือ​อะไร​:​ ​Data​ ​Flow​ ​Diagram​,​ ​Context​ ​Diagram​ ​และ​ตัวอย่าง

DFD ย่อมาจาก Data Flow Diagram หรือแผนภาพกระแสข้อมูล ใช้แสดงว่าข้อมูลมาจากที่ใด ผ่านกระบวนการใด จัดเก็บที่ไหน และส่งไปยังใคร จุดสนใจอยู่ที่ข้อมูลและการแปลงข้อมูล มิใช่รูปลักษณ์หน้าจอหรือลำดับคำสั่งในโปรแกรม IBM อธิบายองค์ประกอบหลักของ DFD ไว้สี่ประเภท ได้แก่ External Entity, Process, Data Store และ Data Flow [1]

สำหรับรายงานโครงงาน DFD ช่วยตรวจว่ากระบวนการมีข้อมูลเพียงพอสำหรับสร้างผลลัพธ์หรือไม่ ตัวอย่างเช่น ระบบไม่ควรสร้างผลพิจารณาคำขอยืมขึ้นมาเองโดยไม่มีข้อมูลคำขอและข้อมูลผลพิจารณาจากเจ้าหน้าที่ หากแผนภาพแสดงเฉพาะกล่องหน้าจอเชื่อมต่อกัน ยังไม่เพียงพอที่จะอธิบายความสัมพันธ์ของข้อมูลในระบบ

องค์ประกอบและสัญลักษณ์ DFD

External Entity: ผู้ให้ข้อมูลหรือผู้รับข้อมูลภายนอกขอบเขต

External Entity คือบุคคล หน่วยงาน หรือระบบที่อยู่นอกขอบเขตที่กำลังศึกษาและแลกเปลี่ยนข้อมูลกับระบบ เช่น นักศึกษาที่ส่งคำขอยืมและเจ้าหน้าที่ที่รับรายการรอพิจารณา “ภายนอก” ไม่จำเป็นต้องหมายถึงนอกองค์กร แต่หมายถึงนอกระบบหรือส่วนงานที่เลือกสร้างแบบจำลอง [1]

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

Process: กระบวนการที่จัดการหรือแปลงข้อมูล

Process แสดงกิจกรรมที่รับข้อมูลแล้วสร้างผลลัพธ์ที่สัมพันธ์กับข้อมูลนั้น ควรตั้งชื่อด้วยคำกริยาและสิ่งที่จัดการ เช่น “รับคำขอ” และ “พิจารณาคำขอ” แทนชื่อกว้าง ๆ เช่น “ระบบ” หรือชื่อหน้าจอ เช่น “หน้าอนุมัติ” หมายเลขกระบวนการใช้ระบุและอ้างอิง ไม่ได้บอกลำดับเวลาการทำงาน [2]

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

Data Store: แหล่งเก็บข้อมูลที่นำกลับมาใช้ได้

Data Store แสดงข้อมูลที่เก็บไว้ เช่น “คำขอยืม” หรือ “รายการอุปกรณ์” ใน Logical DFD ยังไม่จำเป็นต้องระบุว่าใช้ฐานข้อมูลยี่ห้อใดหรือชื่อไฟล์ใด ชื่อควรสื่อถึงข้อมูล ไม่ใช่กิจกรรม เช่น ใช้ “คำขอยืม” แทน “บันทึกคำขอ” เพราะการบันทึกเป็นงานของ Process [1]

Data Store หนึ่งแห่งไม่จำเป็นต้องเท่ากับตารางฐานข้อมูลหนึ่งตาราง การแยกตารางและกำหนดคีย์เป็นงานออกแบบข้อมูลที่ต้องวิเคราะห์เพิ่มเติม เช่น ข้อมูลคำขอหนึ่งชุดอาจจัดเก็บแยกหัวรายการและรายการอุปกรณ์ย่อยในขั้นออกแบบฐานข้อมูล

Data Flow: ข้อมูลที่เดินทางระหว่างองค์ประกอบ

Data Flow แสดงด้วยลูกศรและชื่อข้อมูล เช่น “คำขอยืม” “ผลพิจารณา” หรือ “สถานะคำขอ” หัวลูกศรระบุทิศทางการส่งข้อมูล ชื่อควรอธิบายว่ามีข้อมูลอะไร ไม่ใช่คำสั่งควบคุมอย่าง “ทำต่อ” หรือ “ถ้าอนุมัติ” หากมีข้อมูลส่งไปและกลับ ควรแยกลูกศรพร้อมชื่อของแต่ละทิศให้ชัด [2]

สัญลักษณ์มีหลายแนวทาง เช่น Gane–Sarson ใช้กระบวนการเป็นสี่เหลี่ยมมุมมน และ Yourdon–Coad มักใช้วงกลม ส่วนรูปแหล่งเก็บข้อมูลต่างกันตามชุดสัญลักษณ์ [1] ควรระบุและใช้ชุดเดียวกันในรายงาน พร้อมอธิบายความหมาย ไม่เปลี่ยนรูปร่างจนผู้อ่านแยก Process กับ Data Store ไม่ได้

Context Diagram ต่างจาก DFD Level 1 อย่างไร

Context Diagram แสดงระบบที่ศึกษาทั้งหมดเป็นกระบวนการเดียว พร้อมหน่วยงานภายนอกและข้อมูลที่ข้ามขอบเขต โดยยังไม่แสดงกระบวนการหรือแหล่งเก็บข้อมูลภายใน ใช้เพื่อให้ทุกฝ่ายเห็นขอบเขตร่วมกันก่อนลงรายละเอียด [2]

บทความนี้ใช้ชื่อ Context Diagram หรือ Level 0 สำหรับภาพรวมที่มีกระบวนการหมายเลข 0 และใช้ DFD Level 1 สำหรับภาพที่แยกกระบวนการภายในครั้งแรก สอดคล้องกับการเรียกระดับในบทความ IBM [1] ตัวอย่างจะแยกเป็น 1.0 รับคำขอ และ 2.0 พิจารณาคำขอ

อย่างไรก็ตาม ชื่อระดับไม่ได้ใช้ตรงกันทุกตำรา บางเล่มแยก Context Diagram ออกจาก Level 0 แล้วใช้ Level 0 เรียกภาพที่แยกกระบวนการครั้งแรก เช่น สารบัญ Systems Analysis and Design ฉบับที่ 8 แยกหัวข้อ Creating the Context Diagram กับ Creating the Level 0 Data Flow Diagram ไว้ต่างกัน [3] จึงควรระบุข้อตกลงการเรียกชื่อไว้ในรายงานและใช้ให้สม่ำเสมอ ไม่สรุปจากเลขระดับเพียงอย่างเดียวว่าภาพใดผิด

ตัวอย่าง DFD ระบบยืมคืนอุปกรณ์

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

ภาพที่ 1: ผู้เขียนจัดทำแผนภาพเชิงแนวคิดของส่วนยื่นและพิจารณาคำขอยืม แสดง Context Diagram และการแยกเป็น Level 1 โดยคงข้อมูลข้ามขอบเขตเดิม ไม่ใช่แบบจำลองครบทั้งระบบยืมคืนอุปกรณ์

ข้อมูลข้ามขอบเขตใน Context Diagram

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

การกำหนดความหมายของ “สถานะคำขอ” ให้ชัดมีผลต่อความครบถ้วนของภาพ หากโครงงานต้องแสดงเลขรับคำขอทันทีหลังยื่นด้วย ต้องเพิ่มข้อมูลผลรับคำขอในทั้ง Context Diagram และภาพรายละเอียดให้สอดคล้องกัน ไม่ควรซ่อนความต้องการใหม่นี้ไว้ในคำอธิบายหน้าจอเท่านั้น

กระบวนการและแหล่งเก็บข้อมูลใน Level 1

1.0 รับคำขอ รับข้อมูลคำขอยืมจากนักศึกษา จัดข้อมูลที่จำเป็น แล้วส่งข้อมูลคำขอไปเก็บที่ D1 คำขอยืม กระบวนการนี้ยังไม่ได้สร้างรายการยืมที่ยืนยันการรับอุปกรณ์จริง

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

D1 คำขอยืม เก็บข้อมูลคำขอและสถานะในขอบเขตตัวอย่าง รายละเอียดของฟิลด์ควรมีคำอธิบายแยกต่างหากใน Data Dictionary หากโครงงานขยายไปถึงข้อมูลรายการยืมและคืน ต้องเพิ่มกระบวนการและแหล่งเก็บข้อมูลที่เกี่ยวข้องให้ครบ ไม่ถือว่า D1 ในภาพนี้ครอบคลุมข้อมูลธุรกรรมทุกชนิดโดยอัตโนมัติ

Balancing คืออะไร และตรวจอย่างไร

Balancing คือการรักษาความสอดคล้องของข้อมูลเข้าและข้อมูลออกระหว่างกระบวนการระดับบนกับภาพที่แยกกระบวนการนั้นเป็นระดับย่อย เมื่อขยายรายละเอียด ต้องยังอธิบายข้อมูลที่ข้ามขอบเขตเดิมได้ครบ ไม่เพิ่มหรือตัดข้อมูลภายนอกอย่างเงียบ ๆ หลักการนี้อธิบายไว้ในหัวข้อ Balancing ของเอกสาร University of Cape Town [2]

สำหรับตัวอย่างนี้ตรวจได้ด้วยการเทียบข้อมูลสี่รายการ: คำขอยืมจากนักศึกษา คำขอรอพิจารณาสู่เจ้าหน้าที่ ผลพิจารณาจากเจ้าหน้าที่ และสถานะคำขอสู่ผู้ยื่น ทั้งสี่รายการต้องปรากฏใน Level 1 แม้ต้นทางหรือปลายทางภายในเปลี่ยนจากกระบวนการรวมหมายเลข 0 มาเป็น 1.0 หรือ 2.0

ลูกศรระหว่าง 1.0, 2.0 และ D1 เป็นการเปิดเผยรายละเอียดภายใน จึงไม่จำเป็นต้องปรากฏใน Context Diagram แต่ถ้าเพิ่ม “ผลตรวจสิทธิ์จากระบบทะเบียน” โดยให้ระบบทะเบียนเป็นแหล่งข้อมูลใหม่ จะเป็นการเพิ่มข้อมูลข้ามขอบเขต ต้องทบทวน Context Diagram และขอบเขตระบบด้วย

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

กฎและข้อผิดพลาดที่ควรตรวจ

การไหลระหว่าง External Entity กับ Data Store ต้องผ่าน Process และไม่ควรลากข้อมูลจาก Data Store หนึ่งไปอีกแห่งโดยตรง เพราะยังไม่มีองค์ประกอบอธิบายการจัดการข้อมูลระหว่างแหล่งเก็บ ทั้งสองข้อเป็นกฎที่ระบุในเอกสารองค์ประกอบ DFD ของ University of Cape Town [2]

ตัวอย่างที่ผิดคือ นักศึกษา → D1 คำขอยืม เพราะข้ามกระบวนการรับข้อมูล ควรเป็น นักศึกษา → 1.0 รับคำขอ → D1 ส่วนการทำสำเนาข้อมูลจากแหล่งหนึ่งสู่อีกแหล่ง หากจำเป็นต่อขอบเขต ต้องมี Process ที่อธิบายการส่งหรือจัดเตรียมข้อมูลนั้น มิใช่เส้นเชื่อมระหว่างแหล่งเก็บอย่างเดียว

สำหรับแต่ละ Process ให้ตรวจว่าผลลัพธ์มีที่มาจากข้อมูลเข้าอย่างสมเหตุสมผล เช่น ถ้า 2.0 ส่ง “สถานะอนุมัติ” แต่ไม่มีข้อมูลผลพิจารณาหรือกฎที่ใช้ตัดสินใจ แบบจำลองยังอธิบายที่มาของสถานะไม่ได้ ถ้า 1.0 รับคำขอแล้วไม่มีทั้งข้อมูลออกและการจัดเก็บ ก็ต้องทบทวนว่าข้อมูลหายไปไหน

อีกข้อผิดพลาดคือใช้คำว่า “ใช่” และ “ไม่ใช่” เป็นชื่อลูกศรเพื่อแตกแขนงเงื่อนไขแบบ Flowchart ใน DFD ควรระบุข้อมูล เช่น “ผลพิจารณา” แล้วอธิบายว่าข้อมูลนั้นมีค่าอนุมัติหรือไม่อนุมัติได้อย่างไรในข้อกำหนดกระบวนการ

DFD ต่างจาก Flowchart และ Use Case Diagram อย่างไร

DFD ตอบว่าข้อมูลเดินทางและเปลี่ยนรูปอย่างไร Flowchart ตอบว่ากิจกรรมและทางเลือกเกิดตามขั้นตอนใด ส่วน Use Case Diagram ตอบว่าบทบาทใดมีปฏิสัมพันธ์กับกรณีใช้งานใด การใช้ทั้งสามชนิดในโครงงานเดียวกันมีเหตุผลเมื่อแต่ละภาพตอบคำถามต่างกัน

หมายเลข 1.0 และ 2.0 ใน DFD เป็นรหัสอ้างอิง ไม่ได้พิสูจน์ว่ากระบวนการหนึ่งทำงานทันทีหลังอีกกระบวนการหนึ่ง หากต้องอธิบายการรอ การทำซ้ำ หรือเงื่อนไขการอนุมัติ ควรใช้ Flowchart หรือคำอธิบายกระบวนการเพิ่มเติม ไม่ตีความลูกศรข้อมูลเป็นนาฬิกาหรือลำดับคำสั่ง

การนำไปใช้ในรายงานโครงงาน

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

หลังภาพ ให้อธิบายข้อมูลเข้าและออกของแต่ละกระบวนการเชื่อมกับ Data Dictionary แล้วแสดงผลตรวจ Balancing เป็นรายการสั้น ๆ เช่น คำขอยืมและผลพิจารณาใน Context Diagram ตรงกับข้อมูลที่ Process 1.0 และ 2.0 รับใน Level 1 อย่างไร หากมีส่วนที่ยังไม่รวมในภาพ ให้ระบุข้อจำกัดและเหตุผล

เมื่ออ้างทฤษฎี ควรอ่านแหล่งต้นฉบับ [1]–[3] ตามประเด็นที่ใช้ และเลือกคู่มือหรือตำราที่รายวิชากำหนดเป็นหลัก บทความนี้ให้คำอธิบายและตัวอย่างประยุกต์ ไม่ได้แทนผลการวิเคราะห์ความต้องการของโครงงานแต่ละเรื่อง

ตัวอย่างรายการอ้างอิงบทความนี้หลังเผยแพร่: Waihaus Studio. (2026, 2 ตุลาคม). DFD คืออะไร: Data Flow Diagram, Context Diagram และตัวอย่าง. https://www.waihaus.site/blog/data-flow-diagram-guide ควรเปิดตรวจฉบับที่เผยแพร่ก่อนอ้างอิงและปรับรูปแบบตามคู่มือของสถาบัน

คำถามที่พบบ่อย

Context Diagram ต้องมีฐานข้อมูลหรือไม่

ในข้อตกลงที่ใช้ในบทความนี้ ไม่แสดงแหล่งเก็บข้อมูลภายในใน Context Diagram เพราะระบบถูกแทนด้วยกระบวนการเดียว จากนั้นจึงเปิดเผย D1 และกระบวนการภายในใน Level 1

DFD ต้องใช้จำนวนระดับเท่ากันทุกโครงการหรือไม่

ไม่จำเป็น ควรแยกจนรายละเอียดเพียงพอที่จะอธิบายกระบวนการในขอบเขต ไม่แยกเพิ่มเพียงเพื่อให้ภาพมีหลายระดับ และเมื่อแยกต้องตรวจ Balancing กับระดับบนเสมอ

DFD ใช้แทน ER Diagram ได้หรือไม่

ไม่ได้โดยตรง DFD เน้นการไหลและการจัดการข้อมูล ส่วน ER Diagram เน้นโครงสร้างข้อมูลและความสัมพันธ์ การออกแบบฐานข้อมูลต้องพิจารณารายละเอียดและกฎข้อมูลเพิ่มเติม

หากนำผลวิเคราะห์ไปพัฒนาซอฟต์แวร์ สามารถดู แนวทางพัฒนา Web Application โดยใช้แบบจำลองข้อมูลร่วมกับข้อกำหนดผู้ใช้และเกณฑ์ทดสอบของโครงการ

เอกสารอ้างอิง

• [1] IBM. (ม.ป.ป.). What is a data flow diagram (DFD)? IBM Think. บทความ Data Flow Diagram สืบค้น 2 ตุลาคม 2026. ใช้ประกอบนิยาม องค์ประกอบ สัญลักษณ์ และการเรียก Context Diagram ว่า Level 0.
• [2] Computer Science Department, University of Cape Town. (2011). Chapter 6: Data-Flow Diagrams. MSc-IT Study Material, January 2011 Edition. บทที่ 6 โดยเฉพาะ Elements of data-flow diagrams, Context diagrams และ Balancing.
• [3] Dennis, A., Wixom, B., & Roth, R. M. (2022). Systems Analysis and Design (8th ed.). John Wiley & Sons. ข้อมูลหนังสือและสารบัญจากสำนักพิมพ์ บทที่ 4 แสดงหัวข้อ Context Diagram และ Level 0 Data Flow Diagram แยกกัน ใช้ยืนยันความแตกต่างของข้อตกลงการเรียกระดับ.