ER​ ​Diagram​ ​คือ​อะไร​:​ ​ออกแบบ​ ​Database​ ​ก่อน​สร้าง​ ​Table​ ​อย่างไร

ER Diagram (Entity Relationship Diagram) เป็นภาพของข้อมูลที่ธุรกิจต้องเก็บและความสัมพันธ์ระหว่างข้อมูล ก่อนสร้าง Table จริง ช่วยให้ทีมตอบว่า “ข้อมูลใดเป็นสิ่งเดียวกัน” “รายการหนึ่งเกี่ยวข้องกับอีกชนิดกี่รายการ” และ “ข้อมูลใดควรมีรหัสอ้างอิง”

เริ่มจากคำศัพท์ในงานจริง

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

ภาพที่ 1: การระบุจำนวนความสัมพันธ์ช่วยตรวจว่าข้อมูลควรแยกเป็น Entity ใดก่อนสร้าง Table

คีย์ช่วยรักษาความสัมพันธ์อย่างไร

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

ตัวอย่างสมมติ: ระบบจองคิว

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

ใช้ในรายงาน

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

อ่าน Primary Key และ Foreign Key และ Database Normalization หรือดู บริการระบบหลังบ้าน

วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน

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

หลักฐานที่ควรแสดงคือ Entity, Primary Key, Foreign Key และความสัมพันธ์ 1:N ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ

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

แหล่งข้อมูลประกอบ

• PostgreSQL: Constraints — Primary Key และ Foreign Key ในฐานข้อมูลจริง
• Oracle Database Development Guide — งานออกแบบเชิงตรรกะและความสัมพันธ์ของข้อมูล