Slowly Changing Dimensions: เก็บประวัติข้อมูลให้ย้อนดูอดีตได้ถูกต้อง

ลูกค้าย้ายเขตการขาย ถ้าอัปเดตทับข้อมูลเก่า ยอดขายเดือนก่อนก็จะถูกนับเข้าเขตใหม่ผิด ๆ Slowly Changing Dimensions คือวิธีเก็บประวัติการเปลี่ยนแปลง เพื่อให้รายงานอดีตยังถูกต้อง
ข้อมูลบางอย่างเปลี่ยนช้า ๆ แต่การเปลี่ยนมีผลต่อรายงานย้อนหลัง เช่น ลูกค้าถูกย้ายไปอยู่เขตการขายใหม่ ถ้าเราแค่อัปเดตข้อมูลทับของเก่า เวลาไปดูยอดขายของเดือนก่อน ระบบจะนับยอดเก่าเข้าเขตใหม่ ทำให้ประวัติผิดเพี้ยน Slowly Changing Dimensions หรือ SCD คือวิธีจัดการข้อมูลที่เปลี่ยนช้าเหล่านี้ ให้เก็บประวัติได้ เพื่อให้รายงาน ณ ช่วงเวลาในอดีต ยังสะท้อนความจริงของตอนนั้น
อัปเดตทับ กับ เก็บประวัติ ให้ผลต่างกัน
วิธีที่ง่ายที่สุดคืออัปเดตทับ ซึ่งเหมาะกับข้อมูลที่ไม่สนใจอดีต เช่น เบอร์โทรล่าสุด แต่สำหรับข้อมูลที่ใช้แบ่งกลุ่มในรายงาน เช่น เขตการขาย ประเภทลูกค้า หรือระดับสมาชิก การเก็บประวัติเป็นเวอร์ชัน ทำให้ตอบได้ว่า ณ ตอนนั้นลูกค้าอยู่เขตไหน แล้วยอดขายก็ถูกนับเข้าเขตที่ถูกต้องตามช่วงเวลา การเลือกวิธีจึงขึ้นกับว่ารายงานต้องมองอดีตอย่างถูกต้องหรือไม่
- อัปเดตทับ เมื่อไม่สนใจค่าเดิม เช่น ข้อมูลติดต่อล่าสุด
- เก็บประวัติ เมื่อค่านั้นใช้แบ่งกลุ่มในรายงานย้อนหลัง
- ตัดสินใจตั้งแต่ออกแบบ เพราะแก้ทีหลังเมื่อประวัติหายแล้วยาก
Slowly Changing Dimensions เป็นรายละเอียดการออกแบบข้อมูลที่กระทบความถูกต้องของรายงานย้อนหลังอย่างมาก ผู้บริหารไม่ต้องลงรายละเอียด แต่การรู้ว่ารายงานอดีตอาจผิดเพราะข้อมูลถูกทับ ช่วยให้ตั้งคำถามได้ถูกเมื่อตัวเลขย้อนหลังดูแปลก และเห็นคุณค่าของการออกแบบให้เก็บประวัติในจุดที่จำเป็น ซึ่งเป็นรากฐานของการวิเคราะห์แนวโน้มที่เชื่อถือได้
บริการที่เกี่ยวข้อง
บริการ Data Dashboard & Analytics
ออกแบบแดชบอร์ดและวิเคราะห์ข้อมูล ให้เห็นภาพธุรกิจและตัดสินใจได้ด้วยตัวเลข
WhaleScope
ดูโครงสร้างตลาดของทุกหมวดธุรกิจไทย บน WhaleScope
รายชื่อบริษัท ผู้เล่นรายใหญ่ และอัตราคงอยู่ของแต่ละหมวด — จากข้อมูลจดทะเบียน 2 ล้านนิติบุคคล
อ่านต่อ

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

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

OLAP กับ OLTP: ระบบวิเคราะห์กับระบบธุรกรรม ต่างกันอย่างไร
ระบบที่บันทึกการขายรายวัน กับระบบที่วิเคราะห์ยอดขายย้อนหลัง ต้องการการออกแบบคนละแบบ การใช้ระบบเดียวทำทั้งสองอย่าง มักทำให้ทั้งช้าและรายงานกวนงานหลัก

Lakehouse: จุดบรรจบของ Data Lake ที่เก็บได้ทุกอย่าง กับ Warehouse ที่ตอบได้เร็ว
องค์กรจำนวนมากจ่ายสองเด้ง เก็บข้อมูลดิบใน Data Lake แล้วคัดลอกไปตอบคำถามใน Warehouse พร้อมปัญหาข้อมูลสองที่ไม่ตรงกัน Lakehouse คือสถาปัตยกรรมที่พยายามให้ที่เก็บเดียวทำได้ทั้งสองหน้าที่
