Database​ ​Normalization​ ​คือ​อะไร​ ​และ​ทำไม​ไม่​ควร​เก็บ​ทุก​อย่าง​ไว้​ใน​ ​Table​ ​เดียว

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

ปัญหาของตารางเดียว

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

ภาพที่ 1: การแยกข้อมูลตามความหมายช่วยลดการแก้ซ้ำและทำให้ความสัมพันธ์ตรวจได้

วิธีแยกอย่างเป็นเหตุผล

แยก customers, orders, products และ order_items โดยใช้คีย์เชื่อมความสัมพันธ์ ชื่อปัจจุบันของลูกค้าอาจอยู่ที่ลูกค้า แต่ที่อยู่จัดส่ง ณ เวลาสั่งซื้ออาจต้องเก็บเป็น Snapshot ในคำสั่งซื้อเพื่อรักษาประวัติ ดังนั้น “ไม่เก็บข้อมูลซ้ำเลย” ไม่ใช่กฎเด็ดขาด ต้องดูความหมายและเวลาของข้อมูล

Normal Form และข้อแลกเปลี่ยน

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

สำหรับรายงาน

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

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

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

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

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

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

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

• Microsoft Learn: Database normalization basics — เหตุผลเรื่องข้อมูลซ้ำและ dependency
• PostgreSQL: Constraints — คีย์และความสัมพันธ์หลังแยกตาราง