Primary Key, Foreign Key และ Relationship คืออะไร
เข้าใจรหัสหลัก รหัสอ้างอิง และความสัมพันธ์หนึ่งต่อหลายผ่านตัวอย่างลูกค้าและคำสั่งซื้อ

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

ภาพที่ 1: คีย์หลักระบุรายการ ส่วนคีย์อ้างอิงช่วยรักษาความถูกต้องของความสัมพันธ์
ความสัมพันธ์แบบอื่น
หนึ่งต่อหนึ่งพบในข้อมูลที่แยกเพราะขอบเขตหรือวงจรชีวิตต่างกัน หลายต่อหลาย เช่น คำสั่งซื้อมีหลายสินค้าและสินค้าปรากฏในหลายคำสั่งซื้อ มักใช้ตารางเชื่อม order_items ที่เก็บจำนวนและราคา ณ เวลาขายด้วย การวาด Cardinality ต้องตรวจกรณี “ไม่มีเลย” ด้วย เพราะบางความสัมพันธ์เป็นทางเลือก ไม่ใช่บังคับทุกแถว
ข้อควรระวัง
Foreign Key ช่วยกันข้อมูลอ้างอิงที่ไม่มีอยู่ แต่ไม่แทนกฎทั้งหมด เช่น ห้ามลบลูกค้าที่มีคำสั่งซื้อสำเร็จหรือเก็บประวัติเมื่อชื่อเปลี่ยน การเลือกว่าจะลบ กีดกัน หรือคงข้อมูลต้องสอดคล้องกับกฎธุรกิจและการเก็บข้อมูล ไม่ตั้ง Cascade Delete เพราะสะดวกโดยไม่ประเมินผล
สำหรับรายงาน
ทำ ER Diagram พร้อมตัวอย่างแถวที่ถูกต้องและแถวที่ควรถูกปฏิเสธ ระบุ Primary Key, Foreign Key, Cardinality และกฎเมื่อลบหรือแก้ข้อมูล การยก SQL ตัวอย่างช่วยอธิบายได้ แต่ต้องแยกแบบที่เสนอจาก Schema ที่สร้างจริง
อ่าน ER Diagram และ Database Normalization หรือดู บริการระบบหลังบ้าน
วิเคราะห์กรณีศึกษาเพื่อนำไปเขียนรายงาน
ลองกำหนดกรณีศึกษาเป็น Customer หนึ่งคนมีหลาย Order แต่ Order หนึ่งรายการมีเจ้าของเดียว และเขียนขอบเขตให้ชัดว่ามีผู้ใช้กลุ่มใด ข้อมูลใดเข้าสู่ระบบ และต้องการผลลัพธ์อะไร เริ่มจากสภาพก่อนพัฒนา แล้วอธิบายการตัดสินใจที่บทความนี้เกี่ยวข้องโดยใช้ตัวอย่างข้อมูลหรือเหตุการณ์ที่สมมติขึ้นอย่างระบุว่าเป็นตัวอย่าง การกำหนดขอบเขตเช่นนี้ช่วยให้ผู้อ่านแยกหลักการทั่วไปออกจากข้อเท็จจริงของโครงการได้
หลักฐานที่ควรแสดงคือ โครงตารางพร้อม PK, FK และตัวอย่างข้อมูลที่ผิดความสัมพันธ์ ควรอธิบายสัญลักษณ์ คำย่อ หรือเงื่อนไขในหลักฐานนั้นให้ผู้อ่านที่ไม่อยู่ในทีมเข้าใจ และบอกว่ามันเชื่อมกับ Requirement ข้อใด ถ้ามีหลายทางเลือก ให้ระบุเหตุผลที่เลือกทางหนึ่งและผลกระทบต่อผู้ใช้ ทีมพัฒนา หรือผู้ดูแลระบบ แทนการเขียนเพียงว่าใช้แนวทางที่ “ดีที่สุด” โดยไม่มีเกณฑ์เปรียบเทียบ
เกณฑ์ประเมินตัวอย่างคือ ฐานข้อมูลปฏิเสธ Order ที่อ้าง Customer ที่ไม่มีจริง ส่วนข้อจำกัดที่ต้องระบุคือ การลบหรือแก้ key ต้องกำหนดนโยบาย cascade ให้สอดคล้องธุรกิจ หากยังไม่ได้ทดลองกับผู้ใช้หรือข้อมูลจริง ให้เขียนว่าเป็นข้อเสนอเชิงออกแบบ ไม่สรุปเป็นผลที่พิสูจน์แล้ว การมีทั้งเกณฑ์และข้อจำกัดช่วยให้รายงานตรวจสอบเหตุผลได้ และเปิดทางให้ผู้อื่นนำกรณีเดียวกันไปทดสอบซ้ำในบริบทของตน
แหล่งข้อมูลประกอบ
- PostgreSQL: Constraints — นิยาม Primary Key และ Foreign Key