October 8th, 2009Reference Data Restatement
ลักษณะการ restatement แบบที่สองจะเป็นการเปลี่ยนแปลงที่เกี่ยวข้องกับข้อมูลอ้างอิง (reference data หรือ master data) โดยเฉพาะ
การเปลี่ยนแปลงในลักษณะนี้จะแตกต่างจาก Transaction Data Restatement ตรงที่ ข้อมูลธุรกรรมที่เกิดขึ้นในอดีตไม่ได้มีการเปลี่ยนแปลงไป การเปลี่ยนแปลงนั้นเกิดจากข้อมูลอ้างอิงโดยเฉพาะ ซึ่งอาจเกิดได้ในสองลักษณะคือการเปลี่ยนแปลงโครงสร้างลำดับชั้น และการเปลี่ยนคุณสมบัติบางประการที่ใช้ในการคำนวณค่าข้อมูลชนิดใหม่
ถึงแม้ว่าตัวข้อมูลธุรกรรมไม่มีการเปลี่ยนแปลง แต่การเปลี่ยนข้อมูลอ้างอิง ก็สามารถส่งผลให้ “เสมือน” ว่าข้อมูลในอดีตมีการเปลี่ยนแปลงไปได้เช่นกัน
- Hierarchy Change
Hierarchy หรือโครงสร้างลำดับขั้น เป็นหนึ่งในลักษณะที่สำคัญของข้อมูลอ้างอิง มีความสำคัญมากต่อการสรุปยอดข้อมูล หรือ aggregation โดยการกำหนดการจัดหมวดหมู่ของข้อมูลให้สอดคล้องกับ ความต้องการใช้งานในกลุ่มผู้ใช้แต่ละกลุ่ม ตัวอย่างเช่น ถ้าบริษัทของคุณมีลูกค้าซัก 1000 ราย และจัดแบ่งหมวดหมู่ตามโครงสร้างการบริหารของฝ่ายขาย ทีนี้สมมติบริษัทคุณแบ่งเขตการขายตามพื้นที่ที่อยู่ของลูกค้า คุณอาจจะมีผู้จัดการฝ่ายขาย 4 คน ประจำภาคเหนือ ใต้ กลาง และอีสาน แต่ละคนก็ดูแลลูกค้าที่มีที่อยู่อยู่ในภาคนั้นๆ ดังนั้น ระบบ business intelligence ที่ใช้รายงานยอดขาย ก็จะรวมยอดขายของลูกค้าแต่ละราย ตามเขตพื้นที่ที่ผู้จัดการฝ่ายขายแต่ละคนดูแลอยู่
ถ้าบริษัทมีการเปลี่ยนแปลงโครงสร้างการดูแลลูกค้า แทนที่จะเป็นตามเขตพื้นที่ แต่แบ่งเป็นตามลักษณะของลูกค้า เช่น ลูกค้าแบบองค์กร ลูกค้ารายย่อย และลูกค้าออนไลน์ โดยมีการจัดสรรผู้จัดการฝ่ายขายใหม่ ตามลักษณะการแบ่งกลุ่มลูกค้า คุณยังคงมีลูกค้า 1000 รายเท่าเดิม ธุรกรรมเดิมที่เคยทำกับลูกค้าเหล่านั้น ก็ไม่ได้มีการเปลี่ยนแปลงไปแต่อย่างใด สิ่งที่เปลี่ยนไป คือการจัดกลุ่มที่แตกต่างออกไป
โดยทั่วไปแล้ว เรามักจะต้องการมองข้อมูลในอดีต ผ่านโครงสร้างปัจจุบัน เช่น ลูกค้าแบบองค์กร ปีนี้ยอดขายเทียบกับปีที่แล้วเป็นอย่างไร ถึงแม้ว่าเมื่อปีที่แล้วกลุ่มลูกค้าเหล่านั้น ยังไม่ได้ถูกเรียกว่าลูกค้าแบบองค์กรก็ตาม ความสามารถแบบนี้เป็นความสามารถโดยทั่วไปของระบบฐานข้อมูลที่ถูก normalized มาแล้วระดับหนึ่ง แต่ในบางกรณี ก็มีความจำเป็นที่จะต้องรายงานและวิเคราะห์ข้อมูล ผ่าน hierarchy ในอดีตด้วยเช่นกัน ประมาณว่า ถ้าเราไม่ได้เปลี่ยนโครงสร้างการจัดหมวดหมู่ลูกค้า ยอดขายของกลุ่มลูกค้าในภาคเหนือจะเป็นอย่างไรในปีนี้ ซึ่งมักจะมีความต้องการในลักษณะนี้มาบ้าง แต่ก็ไม่บ่อยนัก
ระบบ data warehouse หรือ business intelligence ที่ออกแบบมาเพื่อรองรับลักษณะการใช้งานเหล่านี้ จะมีการเก็บประวัติการเปลี่ยนแปลงของ hierarchy ไว้ (หรือถ้าเอาให้ง่ายกว่านั้นหน่อย ก็ใช้วิธีสร้าง hierarchy ใหม่ไปเสียเลย) อาจจะย้อนหลังไปซัก 2-3 เวอร์ชั่น เพื่อให้สามารถตอบสนองการวิเคราะห์ข้อมูลแบบพิเศษนี้ได้
- Attribute Change
คุณลักษณะหรือ attribute ของข้อมูลอ้างอิง บ่อยครั้งอยู่เหมือนกันที่ส่งผลต่อการเปลี่ยนแปลงข้อมูลในอดีต โดยเฉพาะอย่างยิ่ง ข้อมูลที่ derived หรือผ่านการคำนวณมาแล้ว ตัวอย่างที่เห็นอยู่บ่อยๆ ก็คือ การใช้อัตราแลกเปลี่ยนเงิน มาคำนวณยอดขาย ในกรณีของบริษัทที่ใช้สกุลเงินมากกว่าหนึ่งสกุล หรือมีสาขาอยู่ในหลายประเทศ ข้อมูลธุรกรรมที่เกิดขึ้น มักจะถูกบันทึกตามสกุลเงินที่เกิดขึ้นจริงในท้องถิ่น ซึ่งก็เพียงพอต่อการใช้งานในประเทศ แต่เมื่อต้องส่งรายงานสรุปขึ้นไปให้บริษัทแม่ที่อยู่ต่างประเทศ ก็ต้องเลือกใช้เป็นสกุลเงินอื่น และต้องพิจารณาอัตราแลกเปลี่ยนที่เหมาะสมด้วย
ยอดขาย 100 ล้านบาทเท่ากัน อาจแสดงผลในรายงานแตกต่างกันในแต่ละปีได้ ถ้าใช้อัตราแลกเปลี่ยนที่แตกต่างกันของแต่ละปี
Reference data restatement ถือเป็นเรื่องปกติ และเป็นหนึ่งในข้อที่ควรพิจารณาเป็นอย่างยิ่งในการออกแบบคลังข้อมูลหรือระบบ business intelligence ใดๆ ข้อควรพิจารณาประกอบด้วย
- ถึงแม้จะเป็นเรื่องปกติที่มีการเปลี่ยนแปลง แต่ก็ควรทำการกำหนดให้ชัดเจนไปเลยว่า การเปลี่ยนแปลงข้อมูลอ้างอิงแต่ละแบบ จะมีขั้นตอนอย่างไรบ้าง ใครเริ่ม ใครอนุมัติ เปลี่ยนได้บ่อยแค่ไหน และสื่อสารข้อตกลงเหล่านี้ให้ผู้ใช้ระบบทราบ
- การอบรมผู้ใช้ก็มีความสำคัญมาก การจัดการกับการเปลี่ยนแปลงข้อมูลอ้างอิง และผลกระทบที่มีต่อรายงานหรือข้อมูลแต่ละชิ้น ควรจะเป็นหนึ่งในหัวข้อการฝึกอบรมพื้นฐานก่อนเริ่มใช้งานระบบ ผู้ใช้จะต้องรู้ว่าพวกเขากำลังมองข้อมูลแบบไหนอยู่
- ความซับซ้อนของการเปลี่ยนแปลงจะเพิ่มมากขึ้น เมื่อพิจารณารวมทั้งระบบ อย่าลืมคำนึงถึง “เวลา” ที่ใช้ในการประมวลผลเพื่อ restatement ด้วย เพราะในคลังข้อมูลขนาดใหญ่ ที่มีข้อมูลปริมาณมากๆ การประมวลผลข้อมูลใหม่ทั้งหมด ไม่ใช่เรื่องสนุก แต่ละครั้งอาจจะต้องใช้เวลาหลายชั่วโมง หรือเป็นวัน