Normalization: ออกแบบฐานข้อมูลไม่ให้ข้อมูลซ้ำและเพี้ยน
เก็บชื่อลูกค้าซ้ำในหลายที่ พอแก้ที่เดียวลืมที่อื่น ข้อมูลก็ขัดกันเอง Normalization คือการออกแบบให้ข้อมูลแต่ละอย่างอยู่ที่เดียว เข้าใจว่ามันช่วยอะไร และเมื่อไรที่ยอมซ้ำได้บ้าง
ปัญหาข้อมูลที่พบบ่อยในระบบที่ออกแบบไม่ดี คือข้อมูลเดียวกันถูกเก็บซ้ำในหลายที่ เช่น ชื่อและที่อยู่ลูกค้าถูกก็อปปี้ไว้ในทุกใบสั่งซื้อ พอลูกค้าย้ายบ้านแล้วแก้ที่เดียว ที่อื่นก็ยังเป็นข้อมูลเก่า ทำให้ข้อมูลขัดแย้งกันเองและไม่รู้ว่าอันไหนถูก Normalization คือหลักการออกแบบฐานข้อมูลให้ข้อมูลแต่ละอย่างอยู่ที่เดียวเป็นแหล่งความจริงเดียว แล้วอ้างอิงถึงมันจากที่อื่น แทนการก็อปปี้ซ้ำ
ข้อดีของการไม่เก็บซ้ำ
เมื่อข้อมูลแต่ละอย่างอยู่ที่เดียว การแก้ก็ทำที่เดียวแล้วถูกต้องทุกที่ที่อ้างอิง ลดความขัดแย้งของข้อมูลและความผิดพลาดจากการลืมแก้บางจุด นี่คือรากฐานที่ทำให้ข้อมูลเชื่อถือได้ อย่างไรก็ตาม ในบางกรณี โดยเฉพาะระบบที่เน้นการอ่านและรายงานจำนวนมาก การยอมเก็บข้อมูลซ้ำบางส่วน (denormalization) อย่างตั้งใจ ก็ช่วยให้เร็วขึ้นได้ สิ่งสำคัญคือรู้ว่ากำลังแลกอะไรกับอะไร ไม่ใช่เก็บซ้ำโดยไม่ตั้งใจ
- ให้ข้อมูลแต่ละอย่างมีแหล่งความจริงเดียว แล้วอ้างอิงถึงมัน
- แก้ที่เดียว ถูกต้องทุกที่ ลดข้อมูลขัดแย้งกันเอง
- การเก็บซ้ำเพื่อความเร็วทำได้ แต่ต้องตั้งใจและรู้ว่าแลกอะไร
Normalization เป็นพื้นฐานการออกแบบข้อมูลที่กระทบความน่าเชื่อถือของทั้งระบบ ผู้บริหารไม่ต้องออกแบบเอง แต่การรู้ว่าข้อมูลที่ซ้ำซ้อนคือต้นเหตุของตัวเลขที่ขัดกัน ช่วยให้เข้าใจว่าทำไมบางระบบถึงมีข้อมูลไม่ตรงกันบ่อย และเห็นคุณค่าของการลงทุนออกแบบข้อมูลให้ดีตั้งแต่ต้น ซึ่งถูกกว่าการตามแก้ข้อมูลที่เพี้ยนไปทีหลังมาก
บริการที่เกี่ยวข้อง
รับพัฒนาเว็บแอปพลิเคชัน
สร้างเว็บแอปที่รองรับการเติบโตและเชื่อมกับระบบอื่นได้
WhaleScope
ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope
รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล
อ่านต่อ
สูตรในไฟล์ผิดมาสามเดือนแล้วไม่มีใครรู้ — สี่แบบของข้อผิดพลาดที่มองไม่เห็น
ข้อผิดพลาดในสเปรดชีตที่อันตรายที่สุดไม่ใช่แบบที่ขึ้นข้อความแดง แต่คือแบบที่ให้ตัวเลขซึ่งดูสมเหตุสมผล บทความนี้อธิบายสี่รูปแบบที่เกิดซ้ำที่สุด และการควบคุมที่จับได้ก่อนตัวเลขไปถึงที่ประชุม
Data Observability: เฝ้าดูสุขภาพของข้อมูล ก่อนรายงานจะผิด
ระบบพังเรามีการเฝ้าระวัง แต่ข้อมูลพังเงียบ ๆ มักไม่มีใครรู้จนตัดสินใจผิดไปแล้ว Data Observability คือการเฝ้าดูสุขภาพของข้อมูล เช่น ครบไหม มาตรงเวลาไหม ค่าผิดปกติหรือเปล่า
Data Contract: ข้อตกลงที่กันข้อมูลพังเงียบระหว่างทีม
เมื่อทีมหนึ่งเปลี่ยนโครงสร้างข้อมูลโดยไม่บอก รายงานและระบบปลายทางพังเงียบ ๆ Data Contract คือข้อตกลงชัดเจนว่าข้อมูลจะมีหน้าตาอย่างไร เพื่อให้เปลี่ยนแปลงได้โดยไม่ทำของคนอื่นพัง
Medallion Architecture: จัดชั้นข้อมูลจากดิบ สู่สะอาด สู่พร้อมใช้
ถ้าแก้ข้อมูลดิบให้สะอาดทับลงไปเลย วันที่พบว่าสูตรแปลงผิด ก็ย้อนกลับไม่ได้แล้ว Medallion Architecture เก็บข้อมูลเป็นสามชั้น ดิบ สะอาด และพร้อมใช้ ให้ตรวจย้อนและแก้ใหม่ได้เสมอ