สวัสดีครับ ผมเป็นจูเนียร์ในทีมดาต้า และได้รับมอบหมายให้พัฒนาข้อมูลใน Data Warehouse (Redshift)
ตอนนี้ผมนำตารางจากฐานข้อมูล OLTP เข้ามาแล้ว โดยตารางยังมีโครงสร้างเหมือนฐานข้อมูลต้นทาง เท่าที่ศึกษามา ขั้นตอนต่อไปขอกระบวนการ ELT คือ transform ข้อมูลที่โหลดเข้ามาเพื่อสร้าง Data Model สำหรับการวิเคราะห์ แต่ผมยังไม่ค่อยเข้าใจว่าควรออกแบบ Model ฝั่ง Warehouse อย่างไร เพราะตารางต้นทางก็อธิบายความสัมพันธ์ของข้อมูลได้ดีอยู่แล้ว และมี query สำหรับทำรายงานเดิมอยู่แล้ว
สมมติว่ามีตาราง purchase_orders → purchase_order_items → goods_receipts ซึ่งเชื่อมกันด้วย foreign key หากต้องการรายงานสรุปจำนวนสินค้าที่รับเข้าตามใบสั่งซื้อ ผมก็สามารถ join ตารางเหล่านี้แล้ว aggregate ได้
แต่เท่าที่ผมศึกษาแนวทางของ Kimball การออกแบบ Fact Table ควรเริ่มจาก business process และกำหนด grain ให้ชัดเจน ผมจึงมีคำถามว่า
ในตัวอย่างนี้ควรสร้าง Fact Table แยกตามตารางต้นทางทั้ง 3 ตารางหรือไม่?
หรือควรพิจารณาก่อนว่ามีกี่ business process ที่ต้องวิเคราะห์ แล้วจึงกำหนด Fact Table ตามนั้น?
หากรายงานที่ต้องการยังไม่ซับซ้อน การ denormalize ตารางต้นทางสำหรับทำรายงานก็เพียงพอหรือเปล่า ?
ผมจำเป็นต้องทำตามแนวทาง Kimball มากน้อยแค่ไหน และควรใช้หลักอะไรตัดสินใจเลือกรูปแบบ Data Model ครับ?
ปล. ถ้ามี resource ที่ตอบคำถามเรื่องนี้ได้ รบกวนช่วยแนะนำผมด้วยนะครับ ขอบพระคุณครับ
2 Likes
lif
September 21, 2026, 4:32pm
2
ผมคิดว่าอาจจะต้องเริ่มจาก business process ที่ต้องการวิเคราะห์ก่อนว่าคืออะไร แล้วค่อยกำหนดว่า grain ของข้อมูลคืออะไร และมี metrics อะไรบ้างที่เกิดขึ้นใน grain นั้น
ถ้าจะเริ่มแบบง่ายที่สุด ผมว่าอาจเริ่มจากดูว่า ตอนนี้มี business process อะไรบ้างที่เราต้องการตอบคำถาม แล้วดูทีละคำถามว่า ต้องการข้อมูลที่ grain ระดับไหน และใช้ metric อะไรบ้าง คิดว่าจากตรงนี้น่าจะช่วยให้เห็นภาพมากขึ้นครับว่าเราควรออกแบบ Fact Table ยังไง และ Fact แต่ละตัวควรมี grain แบบไหนครับ
1 Like
การจะเลือกใช้ data model จริงๆมีหลายปัจจัยครับ เราลองตั้งคำถามก่อนว่าเราต้องการจะทำงานนี้ไปเพื่ออะไร
ถ้าคำตอบคือ เรา build data model เพื่อที่จะเอาไปทำ report, โยนเข้า BI หรือทำ dashboard ผมจะตอบว่า การนำแนวคิด Kimball มาใช้ก็น่าสนใจ แต่อย่าพึ่งรีบตัดสินใจ เราต้องดูบริบทอื่นๆอีก เช่น
User คือใคร (Data analyst, C-level, Developer)
User เอาข้อมูลไปทำอะไร ถ้าคนที่เอาข้อมูลของเราไปใช้ไม่มีความจำเป็นต้องนำข้อมูลไปหมุนแกนบน BI เพื่อหา Insight แสดงว่าเราไม่จำเป็นต้องใช้ kimball ก็ได้
แต่ลองคิดต่อว่าข้อมูลที่เราใช้เป็นข้อมูลประเภทไหน เป็นข้อมูล transaction ที่เพิ่มขึ้นเรื่อยๆใช่ไหม ถ้าใช่เราอาจจะต้องมองการทำ fact table
เราต้องการความเร็วในการ query หรือต้องการความเร็วในการแสดงบนหน้าจอ กรณีนี้รายงานที่เจ้าของโพสต์บอกเป็นหน้าตาแบบไหน รายงานเนี่ยมีหลายแบบมากเลยนะ เช่น report excel file, report บน web, หรือ report บน dashboard ล่ะ อันนี้ต้องบอกให้ชัดเพื่อที่จะได้ตัดสินใจต่อได้ว่าควรเป็นในรูปแบบไหน เพราะจะได้คำตอบคนละแบบกันเลยครับผม
ถ้าคำตอบคือจะเอา Report บน Dashboard ก็อาจจะมอง kimball เป็นทางเลือกได้
ตอบคำถามสามข้อด้านบน
ในตัวอย่างนี้ควรสร้าง Fact Table แยกตามตารางต้นทางทั้ง 3 ตารางหรือไม่?
คำตอบคือทำได้ครับ แต่ว่าผมไม่มั่นใจว่า purchase_orders → purchase_order_items ต้องแยกกันหรือรวมกันได้ไหม
หรือควรพิจารณาก่อนว่ามีกี่ business process ที่ต้องวิเคราะห์ แล้วจึงกำหนด Fact Table ตามนั้น?
business มี events อะไรเกิดขึ้นบ้างในธุรกิจ เช่น ฝ่ายจัดซื้อออกใบ PR/PO (อันนี้แหละผมเลยสงสัยว่า purchase_orders → purchase_order_itemsมันรวมกันได้ไหมเพราะอันนี้เป็น process เดียวกัน)
data source ข้อมูลมากจากไหนเป็นข้อมูลแบบไหนบ้าง เช่น แบบที่เจ้าของโพสต์บอก เอามาจาก OLTP ข้างในมีแค่ข้อมูล transaction ใช่ไหม แล้วมีอะไรที่เป็น master data ที่เราเอามาทำเป็น dim table ได้ไหม
หากรายงานที่ต้องการยังไม่ซับซ้อน การ denormalize ตารางต้นทางสำหรับทำรายงานก็เพียงพอหรือเปล่า ?
ต้อง tradeoff ครับ ถ้าตาราง denormalize มากไปอาจจะเกิดปัญหาว่าถ้าข้อมูลเปลี่ยนเราจะหาที่มาของมันไม่ได้
แต่ข้อดีก็คือง่าย สะดวก เร็ว ถ้าเป็นผมจะเลือกอะไรที่ make it work ก่อนเลยครับ ค่อยๆเติม practice เข้าไปได้ให้มัน make it right → make it fast มาสุดท้าย
การออกแบบที่ดี ต้องรู้ context ของต้นทางและปลายทางน่ะ
อย่างแรก ควรสอบถามคนใช้ข้อมูลปลายทาง ว่า เขาจะใช้ข้อมูลไปทำอะไรบ้าง
พอรู้แล้วว่าปลายทาง จะใช้ข้อมูลแบบไหน เอาสิ่งนั้นมาตีลังกา ว่า ต้องปั้นข้อมูลแบบไหน ที่ทำให้ปลายทางสามารถนำไปใช้งานได้ง่ายที่สุด โดยที่ไม่ได้ราคาสูงจนเว่อร์สำหรับฝั่ง data warehouse operations
ถ้า users ใช้ง่าย แต่ค่า warehouse พุ่ง อาจจะไม่คุ้ม
