Data Warehouse Final : Other Technique

หลังจากรวบรวม Dimension Technique และ Fact Technique ก็มาปิดท้ายกันด้วยเทคนิคที่เหลือจากเรื่องราวต่างๆของการจัดการคลังข้อมูล หรือ Data warehouse กันนะคะ เอนทรี่นี้ก็รวบรวมเทคนิคต่างของแต่ละบท ที่มีความแตกต่างกันไปในแต่ละ business process

Combining multiple sources (unit 6)

– การที่ต้องรวบรวมข้อมูลจากหลายแหล่งหรือหลายระบบ อาจทำให้มีคีย์หรือสิ่งที่บ่งชี้ถึงลูกค้าคนหนึ่งมากกว่า 1 ตัว ซึ่งควรจะทำการกำจัดตัวบ่งชี้ที่ไม่จำเป็นออกซะ
– การสร้างสิ่งบ่งชี้ขึ้นมาและกําจัดตัวที่ไม่จําเป็นนั้นทําได้ยาก  และทําให้ข้อมูลมีความซับซ้อนขึ้น  โดยการใช้วิธีการต่างๆ  เช่น  addressparsing  algorithm  ซึ่งกระบวนการเหล่านี้มีค่าใช้จ่ายที่สูงมาก  แต่อย่างไรก็ ตามผลลัพธ์ที่ได้มาก็คุ้มค่ากับการลงทุน
– ประสิทธิภาพของการรวมข้อมูลนี้จะมากหรือน้อยก็ขึ้นอยู่กับความถูกต้องของการ เก็บข้อมูลจากแต่ละแหล่งและเครื่องมือในการจัดระเบียบและรวมข้อมูลเหล่านั้น

Customer Behavior Study Groups (unit 6)

– Behavior study group  คือกลุ่มของลูกค้าที่เราต้องการวิเคราะห์โดยลูกค้าในกลุ่มจะมีพฤติกรรมคล้าย คลึงกัน  เช่น  ซื้อของชนิดเดียวบ่อยที่สุด 100 คนแรก  โดยจะวิเคราะห์พฤติกรรมของคนกลุ่มนี้เพื่อใช้ในการคิดโปรโมชั่นเพื่อสร้าง รายได้ของบริษัทให้เพิ่มขึ้น
– การจะสร้าง  Behavior study group  นั้น เราจะรันคิวรี่เพื่อให้ได้ set ของลูกค้าที่เราต้องการศึกษาพฤติกรรมแล้วเอาเฉพาะ  Natural Key  มาสร้างตาราง behavior study group dimension table  แล้วก็ใช้ตารางนี้ในการวิเคราะห์ซึ่งจะง่ายกว่าการวิเคราะห์  customer  ทั้งหมดจากตาราง  customer dimension

Customer Hierarchy (unit 6)

– การวิเคราะห์โครงสร้างภายในองค์กรของลูกค้าเป็นสิ่งสำคัญ ทำให้เราสามารถวิเคราะห์ได้หลายอย่าง เช่น ผลรวมรายได้ของสำนักงานใหญ่, แต่ละสาขา ซึ่งโครงสร้างขององค์กรลูกค้าอาจจะมีการเปลี่ยนแปลงค่อนข้างบ่อย เช่น เปลี่ยนภูมิลำเนา, เปลี่ยนสาขาใหญ่
– วิธีการจัดกา่รลำดับชั้นขององค์กร

1. Fixed-Depth Hierarchies : คือลำดับชั้นขององค์กรมีความลึกของลำดับชั้นตายตัวแน่นอน ซึ่งเกิดขึ้นจริงได้น้อยมาก เพราะความจริงจะมีการย้ายเข้า-ออกของพนักงานเพื่อเลื่อนตำแหน่งอยู่เสมอ แต่วิธีการนี้จะง่ายในการคำนวนและรวมผลลัพธ์
2. Variable-Depth Hierarchies : คือลำดับชั้นที่ไม่รู้ความลึกแน่นอนของลำดับชั้น
   – ในการรวมรายได้ต้องมี recursive pointer เพื่อบอกว่าเป็นลูกค้าของสาขาไหน แต่ syntax GROUP BY ใช้ไม่ได้
   – วิธีที่มาแทนคือ การเพิ่มตาราง bridge table (helper, assosiative table) เข้าไประหว่าง fact table และ dimension ของลูกค้า
   – bridge  table นี้จะประกอบไป ด้วย 5 attribute ดังนี้
   Parent Customer Key : customer key ของโหนดที่เป็น parent
   Subsidiary Customer Key  : customer key ของโหนดที่เป็นลูก
   #Levels from Parent  : ระยะห่างระหว่าง Parent Customer Key  และ Subsidiary Customer Key
   Bottom Flag  : จะเป็น True เมื่อ Subsidiary Customer Key เป็น leaf node
   Top Flag : จะเป็น True เมื่อ Subsidiary Customer Key เป็น  root node

Destructively Update (unit 13)

– Destructively Update เป็นลักษณะของการที่ได้ข้อมูลล่าช้าทำให้ต้องค้นหาข้อมูลเดิมแล้วทำการ เปลี่ยนแปลง โดยมีการใช้ Slowly changing type 2 ช่วย ซึ่งจำเป็นที่จะต้องเก็บ stamped date และ dimension ที่เก็บ late arriving row  เอาไว้ด้วยเพราะว่าต้องใช้ในการค้นหา

Heterogeneous Product (Unit 9, 15)

– Heterogeneous Product เป็นลักษณะของการที่มีหลาย line-of- business ที่สนใจ และแต่ละอันมีข้อมูลรายละเอียดที่ต่างกัน
– ยกตัวอย่างเช่น รายละเอียดของการประกันภัยบ้าน ย่อมแตกต่างจากการประกันรถยนต์  แตกต่างจากการประกันชีวิต ถึงแม้ว่ารายละเอียดเหล่านี้สามารถที่จะเก็บเป็นโครงสร้างเดียวกันได้ แต่ว่าก็จะมีบาง attribute หรือ measure ที่การประกันแต่ละชนิดจะมีรายละเอียดที่ต่างกัน
– ถ้ามองในภาพรวมเราต้องการเพียง Fact Table เดียวเท่านั้น เรียกว่า Core Fact Table ที่จะเชื่อมกับทุกๆ line of business แต่อย่างไรก็ตาม Core fact สามารถที่จะแสดงได้แค่ fact จำนวนจำกัดเท่านั้น  โดยที่ fact ทุกอันนั้นจะต้องสามารถลงข้อมูลได้สำหรับทุกๆ line of business เพราะฉะนั้นเราจึงไม่สามารถรวม fact ที่ไม่เกี่ยวกันของแต่ละ line of business นั้นไว้ใน core fact table ได้
– มุมมองที่สองของลูกค้าคือการมองแบบ specific line of business ที่ต้องการเจาะลึกถึงรายละอียดใน line of business นั้นๆ  เช่น ต้องการวิเคราะห์ ประเภทบัญชีกระแสงรายวัน ซึ่งมีรายละเอียด ทั้ง fact และ attributes จำนวนมาก  จากที่กล่าวไว้แล้ว fact ของแต่ละ line of business นั้นไม่สามารถนำไปรวมใน core ตาราง fact ได้ ถ้าหากนำมารวมกัน ก็จะได้ facts จำนวนมาก ที่จะมีค่าเป็น null ในแถวของ line of business อื่นๆ  ในทำนองเดียวกัน ถ้าใส่ attribute ใน product dimension หลักแล้ว attribute จำนวนมากเหล่านั้น จะกลายเป็น null ไปทุกๆ แถวอีก  และในสุดท้าย ตารางก็จะกลายเป็น Swiss Chesse  ซึ่งหมายถึง ตารางเหล่านั้นจะเต็มไปด้วยรู (null) ดังนั้น เราจึงจำเป็นต้องแก้ไขกรณีนี้ด้วยการสร้าง custom shema สำหรับ checking line of business
– การใช้ เทคนิค heterogeneous product schemas จะเหมาะสมกับการใช้ fact tables ที่ในแต่ละแถวจะประกอบไปด้วย facts เฉพาะ product ต่างๆ อยู่ด้านใน  ดังนั้น Snapshot facts ต่างๆ จะใช้เทคนิคนี้

Multiple currency (unit 5)

– สำหรับบริษัทที่มีขนาดใหญ่ๆ มีสาขาต่างประเทศมากมาย เราอาจจะได้ค่าสกุลเงินหลายค่าตามแต่ละประเทศที่มีสาขาเปิดอยู่ เราไม่อาจจะนำสกุลเงินต่างๆกันไปใส่เป็น Column ในแต่ละตารางได้ เนื่องจากในทางทฤษฎีแล้วเราไม่อาจทราบจำนวนของสกุลเงินได้เนื่องจากสามารถ ที่จะเพิ่มค่าขึ้นเรื่อยๆ
– สิ่งที่เราควรจะต้องเก็บไว้ในตาราง Fact คือคอลัมน์ของสกุลเงินในประเทศนั้นๆ และสกุลเงินที่เป็นมาตรฐานที่ไว้สำหรับเปรียบเทียบเงินได้
– Currency Dimension เพื่อเอาไว้สำหรับชี้ว่าสกุลเงินในประเทศนั้น เป็นสกุลอะไร
– Currency Conversion Fact เพื่อไว้สำหรับเปรียบเทียบสกุลเงินโดยเฉพาะ
– จะต้องมีการเก็บค่าทั้ง Local และ Standard ในตาราง Fact และจะต้องมีทั้ง Currency Dimension และ Currency Conversion Fact

Point in time balance (unit 9)

– การหายอดเงินคงเหลือของแต่ละบัญชี หากต้องการรายละเอียดมากกว่ายอดสรุปวันสุดท้ายของเดือนอาจทำได้โดย สร้าง Transaction Fact Table
ที่ใช้เก็บข้อมูลของ Transaction ที่เกิดขึ้น
– โดยมีชื่อ  Final Flag คือคอลัมน์ที่จะใช้ในการบอกว่า Transaction นั้นๆ เป็น Transaction สุดท้ายของวันหรือไม่ และ Transaction Ending Balance จะในในการระบุยอดเงินคงเหลือของบัญชีนั้นภายหลังที่ Transaction ได้ถูกกระทำ หรือเกิดขึ้นมาแล้ว
– ใน Transaction Fact Table นั้นข้อมูลในแต่ละแถวจะเกิดขึ้นมาก็ต่อเมื่อมีการทำ Transaction เท่านั้น ซึ่งหากไม่ได้มีการทำ Transaction ใดๆ ก็จะมีไม่มีการเพิ่มข้อมูลเข้าไปในตาราง Fact Table
– สำหรับบางธุรกิจที่มีการอัพเดตค่าของยอดเงินหลังจากมี transaction นั้นจะไม่สามารถใช้วิธีนี้ได้ เช่น การซื้อหลักทรัพย์ ค่าที่ได้คำนวณออกมานั้นจะไม่ใช่ค่าที่เชื่อถือได้ เนื่องจากมูลค่าของยอดเงินคงเหลือจะเปลี่ยนแปลงอยู่ตลอดเวลาขึ้นอยู่กับ มูลค่าของหลักทรัพย์ที่เราซื้อไปในขณะนั้น

Snapshot (unit 5)

1. Transaction Snapshot model : เหมาะสมกับการดำเินินการ โดยไม่รู้การเริ่มต้นและการสิ้นสุดที่แน่นอน
   – มุมมองพื้นฐานส่วนใหญ่ของผู้ที่เกี่ยวข้องกับธุรกิจ คือ การมองระดับการซื้อขายหรือเหตุการณ์ที่เกิดขึ้นหรือที่เราเรียกว่า transaction ซึ่งตาราง fact table นี้จะแทนเหตุการณ์ที่เกิดขึ้น ณ เวลาหนึ่งๆ  แถวในตารางสำหรับสินค้าหรือสิ่งที่ให้ลูกค้าจะเกิดขึ้นเมื่อมี transaction เกิดขึ้น ในทางตรงกันข้ามสินค้าหรือสิ่งที่ให้กับลูกค้าหนึ่งๆจะสามารถมีแถวได้หลาย แถว
   – ข้อมูลของ transaction เป็นข้อมูลที่มีระดับต่ำที่สุด ซึ่งเราสามารถวิเคราะห์ถึงพฤติกรรมทางธุรกิจได้อย่างละเอียด  ซึ่งถ้าเกิด transaction ขึ้นแล้ว  ข้อมูลเหล่านั้นไม่สามารถนำไปแก้ไขหรือเปลี่ยนแปลงได้อีก
   – ตัวอย่างเช่น Order Management (บท 5), General Ledger Journal (บท 7), Health Care (บท 13)
2. Periodic Snapshot : เหมาะสมกับการดูเป็นสถิติ รายวัน/ เดือน/ ปี
   – Periodic snapshots เป็นตารางไว้สำหรับมองประสิทธิภาพแบบสะสมธุรกิจ แต่จะมองเป็นช่วงเวลา. ซึ่งจะต่างกับ Transaction Fact Table ที่จะสนใจในเหตุการณ์ที่เกิดขึ้นในแต่ละครั้ง  เหมือนกับเราถ่ายรูปกิจกรรมที่เกิดขึ้นทั้งหมดในช่วงหมดวัน สัปดาห์หรือเดือน  จากนั้นรูปถ่ายจะถูกถ่ายเรื่อยๆทุกๆช่วงเวลาที่เรากำหนดไว้  ซึ่งจะมีประโยชน์อย่างมากในการดูแนวโน้มของธุรกิจ
   – Periodic  snapshots มีความซับซ้อนมากกว่า transaction เนื่องจาก transaction เป็นเพียงส่วนย่อยๆของรายได้ เราสามารถเปลี่ยนจาก transaction ในแต่ละแถวเป็น snapshot แบบรายวันได้ง่ายๆโดยการเพิ่ม transaction ต่อท้ายไปเรื่อยๆจนครบวัน  หรืออาจะบวกค่ารายได้ที่เกิดขึ้นไปเรื่อยๆ  แต่สำหรับบางธุรกิจ  transaction ที่เกิดขึ้นอาจจะไม่ใช่รายได้ เช่น การใช้บัตรเครดิต  เราจะเก็บชื่อของบริษัทผู้ออกบัตรหรือธนาคารไว้
   – ตัวอย่างเช่น General Ledger Periodic Snapshot (บท7), การดำเนินระยะยาวของ health care (บท 13)
3. Accumulating Snapshot model : เหมาะกับการดำเนินการที่มีขั้นตอนแน่นอน และช่วงเวลาไม่ยาวมากนัก หรือการทำงานลักษณะ pipeline นั่นเอง มีลักษณะ revisited dimension, multiple date role playing in fact
   – Accumulating snapshot ส่วนใหญ่จะเก็บหลายเวลา ซึ่งจะแทนวันเวลาของเหตุการณ์ เช่น วันการรับสินค้า วันการส่งสินค้า  วันการส่งใบสินค้า  ซึ่งวันเวลาเหล่านี้จะเปลี่ยนแปลงเป็นข้อมูลที่ใหม่ที่สุดเสมอ  เมื่อมีข้อมูลแถวแรกถูกโหลดเข้าไปในตาราง fact วันเวลาเหล่านี้จะยังไม่มีค่าใดๆ  เราจะใช้ surrogate date key เป็นตัวจัดการวันเวลา  เมื่อมีการเปลี่ยนแปลงวันเวลาของสินค้า  เราก็จะใส่ surrogate date key ใน column นั้นๆ เพื่อบอกสถานะของสินค้า  ซึ่งจะเพิ่มไปเรื่อยๆ จนกระทั้ง ลูกค้าได้รับสินค้าหรือได้รับใบกำกับภาษี จะถือว่าสิ้นสุด ซึ่งเราจะเรียกว่าครบ life cycle time จากนั้นก็จะทำเช่นนี้กับข้อมูลทุกๆแถวที่ถูกใส่เข้ามาในตาราง accumulating snapshot fact table
   – ความแตกต่างที่เห็นได้ชัดของตารางแบบนี้กับตารางอีก 2 แบบที่ได้กล่าวในข้างต้นคือ ตาราง accumulating snapshot fact table  จะสามารถเปลี่ยนแปลงค่าได้ ทำให้เราสามารถตรวจดูสถานะของสินค้าได้ว่าอยู่ในกระบวนการใด
   – ตัวอย่างเช่น Order fullfillment Pipeline(บท 5)