Masterless Data Model

การออกแบบฐานข้อมูลโดยเฉพาะระบบงานคอมพิวเตอร์ที่ใช้ในภาคธุรกิจ มักมีกระบวนท่ามาตรฐาน คือประกอบด้วยส่วนที่เป็น Master กับส่วนที่เป็น Transaction
 
ส่วนที่เป็น Transaction คือ บันทึกเหตุการณ์ที่เกิดขึ้น โดยเชื่อมโยงไปว่าเกี่ยวข้องกับ "ใคร" หรือ "อะไร" บ้าง และที่สำคัญที่สุดต้องระบุว่าเหตุการณ์นั้นเกิดขึ้น "เมื่อไหร่"
 
ส่วนที่เป็น Master ก็คือ ตัวตน (entity) ที่เกี่ยวข้องในเหตุการณ์
 
ทางบัญชีอาจเรียกเหตุการณ์นั้นว่า ธุรกรรม นอกจากระบุว่าเกี่ยวข้องกับ "ใคร" หรือ "อะไร" ก็ยังต้องระบุ "มูลค่า" ของเหตุการณ์นั้นด้วย ธุรกรรมซื้อหรือขาย คือตัวอย่างเหตุการณ์ที่เราพบเจออยู่ทั่วไป
 
เมื่อรวบรวมข้อมูล Transaction อย่างเป็นระบบในรูปแบบของดาต้าเบส ทำให้เราสามารถใช้ประโยชน์เพื่อตอบคำถามในแง่มุมต่างๆ อย่างรวดเร็ว โดยใช้ความสามารถคัดกรองและเรียบเรียงข้อมูลเหล่านั้น เช่น ปีที่แล้วเคยขายสินค้าให้กับลูกค้ารายนี้เป็นมูลค่าเท่าไหร่, ปีที่แล้วมีลูกค้าที่เสนอราคาแต่ไม่ได้ขายกี่ราย
 
มีคำถามหนึ่งที่ผมยังไม่สามารถหาคำตอบที่น่าพอใจ ตอนที่พบว่าขีดความสามารถของดาต้าเบสรุ่นใหม่ที่ประมวลผลข้อมูลได้รวดเร็ว จนสามารถสะกัดส่วนที่เป็น Master มาจาก Transaction ได้
 
เป็นไปได้หรือไม่ ที่เราจะสร้างข้อมูลเสมือน Master ขึ้นมากลางอากาศจาก Transaction นั้นเอง สำหรับดาต้าเบสที่ยังไม่มีขนาดหรือปริมาณใช้งานสูงมากจึงไม่จำเป็นต้อง optimize ด้วยการเก็บทุกอย่างที่ใช้อ้างอิงเป็น Master
 
สุดโต่ง
 
ดาต้าเบสในอุดมคติไม่จำเป็นต้องมีมาสเตอร์ ยกตัวอย่าง ข้อมูลลูกค้า การเก็บชื่อ ที่อยู่ เลขประจำตัวผู้เสีย และรายละเอียดที่จำเป็น ช่วยอำนวยความสะดวกในการทำงานประจำวัน เช่น เสนอราคา, เปิดบิลส่งของ
 
ข้อมูลลูกค้าที่จำเป็นแฝงอยู่ในเหตุการณ์ของกระบวนการขายอยู่แล้ว ทำไมจึงต้องผลักภาระให้ผู้ใช้ต้องทำงานเพิ่ม ตรงข้ามกับการออกแบบ data analytic
 
หากเป็นงานต่อเนื่องที่อยู่ภายในเวิร์กโฟลว์ เราสามารถออกแบบโปรแกรมให้ส่งต่อเนื้อหาระหว่างเอกสาร ช่วยอำนวยความสะดวกได้เหมือนกัน หากเป็นงานเอกสารตั้งต้น หากเป็นลูกค้าเดิมเราสามารถให้โปรแกรมดึงข้อมูลจากประวัติเก่ามาใช้ได้ หากเป็นลูกค้าใหม่แทนที่จะไปบันทึกในมาสเตอร์ ก็บันทึกในเอกสารนั้นแหละ ก็จะกลายเป็นประวัติสำหรับคราวหน้าอัตโนมัติ
 
ความสุดโต่งนี้ใช้ไม่ได้กับผู้ใช้ที่เคยมีระบบโปรแกรมอื่นมาก่อน เมื่อถูกถามว่าจะโอนฐานข้อมูลที่มีอยู่มาเข้าระบบใหม่อย่างไร กลายเป็นเหมือนคำแก้ตัวของความไม่สมบูรณ์ในความรู้สึกผู้ใช้ ภายหลังจึงต้องปรับเปลี่ยนให้เป็นทางเลือก แล้วโปรแกรมก็กลับไปใช้ระบบข้อมูลที่อ้างอิงจากมาสเตอร์ แทนที่จะเสียเวลาอธิบายให้ผู้ใช้ยอมรับ
 
ขณะเดียวกัน ด้วยคุณสมบัติพื้นฐานของระบบข้อมูลเอกสารในโปรแกรมซึ่งเป็นข้อมูล Transaction ทีมวางระบบได้คิดค้นวิธีเก็บข้อมูลพิเศษบางอย่างให้ผู้ใช้บางแห่ง ซึ่งผมพบว่าเป็นการออกแบบที่น่าสนใจ
 
ทรัพย์สิน
 
การวางระบบข้อมูลเอกสารของโปรแกรม เริ่มจากกำหนดหมวดหรือเล่มเอกสารที่ต้องการใช้ จะมีกี่หมวดก็ได้ไม่จำกัด
 
หลังจากนั้นสามารถกำหนด Next Flow บอกว่าเอกสารหมวดนี้ใช้ส่งต่อไปให้หมวดไหน กลไกเช่นนี้เหมาะกับการทำงานแบบหนึ่งต่อหนึ่ง คัดลอกรายละเอียดตามไปด้วย เช่น จากใบเสนอราคา ส่งต่อเป็นใบยืนยันขาย, ใบเบิกสินค้า และใบส่งสินค้า ตามลำดับ
 
นอกจากนี้ยังมีกลไก Ref Flow ใช้สำหรับย้อนไปดึงเอกสารมาคราวละหลายใบได้ เหมาะกับการใช้งานวางบิล หรือรับชำระ ที่ต้องสรุปเอกสารค้างชำระเป็นงวด
 
ทีมวางระบบตั้งหมวดเอกสารขึ้นมา ใช้บันทึกข้อมูลทรัพย์สินถาวร เลขที่บิลใช้เป็นเลขทะเบียนทรัพย์สินนั้นเอง วันที่ในบิลเป็นวันที่ลงบัญชีทรัพย์สิน มูลค่าในบิลก็เป็นมูลค่าทรัพย์สิน
 
นอกจากนี้ยังมีหมวดบิลอีกหมวด สำหรับบันทึกค่าเสื่อม และปรับปรุงมูลค่าทรัพย์สิน

พาเลท
 
การออกแบบงานบริหารคลังสินค้าแห่งหนึ่ง ผู้ใช้ต้องการทราบว่าสินค้าที่ต้องการเก็บอยู่ที่ไหน ระบบเอกสารจึงถูกใช้บันทึกข้อมูลพาเลทที่วางสินค้า โดยออกแบบให้เลขที่บิลเป็นเลขพาเลท วันที่ในบิลคือวันที่วางพาเลทนั้น รายการในบิลก็คือรายการสินค้าบนพาเลทนั่นเอง
 
เลขที่พาเลทจึงเป็นเลขใหม่ทุกครั้งที่วางใหม่ไม่มีการใช้ซ้ำ ฟอร์มบิลถูกออกแบบให้กลายเป็นป้ายปิดที่พาเลท มี QR Code สำหรับผู้ตรวจคลังสินค้า เมื่อวางพาเลทไปแล้วสามารถอัพเดทตำแหน่ง (location) ที่วางพาเลทนั้นได้ เมื่อยกพาเลทออกมาก็เอาป้ายปิดนั้นมาบันทึกเบิกสินค้าออกจากพาเลท
 
ยังมีหมวดบิลอื่นๆ ที่เชื่อมโยงกับพาเลท เพื่อบันทึกการรับเข้า, เบิกออก ไปจนถึงการวางแผนขนส่ง ที่ผมไม่เข้าใจดีนัก รู้แต่ว่าทั้งหมดนี้ใช้กลไกพื้นฐานของระบบเอกสาร
 
อัตราแลกเปลี่ยน
 
ตอนที่ออกแบบระบบเงินตราต่างประเทศ ต้องการใช้เพื่อเป็นใบสั่งซื้อสินค้าและวัตถุดิบจากต่างประเทศ จึงออกแบบให้สามารถระบุสกุลเงินที่ต้องการใช้แสดงในใบสั่งซื้อ ตัดตอนไม่ยุ่งเกี่ยวกับการรับรู้มูลค่าทางบัญชี
 
ล่าสุดเป็นธุรกิจที่เกี่ยวข้องกับเงินตราต่างประเทศตั้งขายและซื้อ และต้องการให้เชื่อมโยงถึงการบันทึกบัญชีด้วย ดังนั้นจึงต้องออกแบบให้สามารถบันทึกข้อมูลอัตราแลกเปลี่ยนประจำวันได้
 
หลังจากที่คิดวิธีการหลายอย่าง ในที่สุดก็ออกแบบให้ใช้เอกสารเก็บอัตราแลกเปลี่ยนประจำวัน
 
แผนการผลิต
 
งานล่าสุดของทีม กำลังออกแบบระบบการผลิตสำหรับโรงงานที่ผลิตสินค้าตามสเปคที่ลูกค้ากำหนด ตั้งหมวดเอกสาร BOM บันทึกขั้นตอนการผลิตพร้อมทั้งรายการวัตถุดิบที่ต้องใช้ โดยโหลดมาจาก worksheet ที่วิศวกรคำนวณไว้
 
รายละเอียดการทำงานต่อจากนี้ยังอยู่ในช่วงออกแบบพัฒนา ยังไม่สามารถบอกได้ชัดเจน เห็นแต่รายชื่อหมวดเอกสารที่เตรียมไว้เช่น เบิกวัตถุดิบ, ตัดสูญเสียจาการผลิต, รับสินค้าจากการประกอบ, ตรวจสอบสินค้าก่อนส่ง ฯลฯ
 
ความน่าสนใจอยู่ตรงที่เป็นครั้งแรกที่ทีมวางระบบแสดงให้เห็นว่า สามารถเอากลไกของระบบเอกสารใช้แทนข้อมูลสินค้าก็ได้
 
ประนีประนอม
 
ตัวอย่างงานออกแบบของทีมวางระบบ ช่วยเติมเต็มความบกพร่องของการทดลองข้อมูลไม่ต้องมีมาสเตอร์ที่นำเสนอไปครั้งแรก
 
ประการแรก จากงานออกแบบข้างต้น ดูเหมือนความคิดเรื่องใช้ Transaction ในรูปแบบเอกสารแทน Master นั้นเป็นไปได้
 
ประการที่สอง ความคิดเรื่องใช้ Transaction ในลักษณะของประวัติตัวเองเป็น Master ตามไอเดียแรกมีข้อจำกัด นำไปสู่การไม่ยอมรับจากผู้ใช้ เพราะอาจก่อให้เกิดความรู้สึกสับสน มีโอกาสที่ข้อมูลผิดพลาดหรือไม่พึงประสงค์หลุดรอดมาได้ ไม่สามารถควบคุมความถูกต้องของข้อมูลได้
 
การกำหนดขอบเขตภายใน Transaction ที่สามารถควบคุมความถูกต้อง โดยแยกหมวดเอกสารที่เก็บข้อมูลเชื่อถือได้ กับหมวดเอกสารที่ใช้ทั่วไป ซึ่งไม่จำเป็นต้องเป็นหมวดเดียวกัน ทำให้ข้อมูลเฉพาะในเอกสารหมวดนั้นทำหน้าที่เสมือน Master
 
ขณะเดียวกันผู้ใช้ยังรู้สึกเสมือนยังมีข้อมูลระดับ Master ที่จับต้องได้ โดยทางเทคนิคเราใช้ข้อมูล Transaction คือระบบเอกสารที่มีอยู่แล้ว โดยไม่ต้องเพิ่มข้อมูล Master ชนิดใหม่