Dimension Technique of Data Warehouse

Dimension Technique ต่างๆที่พยายามรวบรวมเนื้อหาและทำความเข้าใจ (รู้เรื่องบ้างไม่รู้เรื่องบ้าง) ก็สรุปออกมาได้ทั้งหมด 12 เทคนิคด้วยกัน (เรียงตามตัวอักษร เพื่อความหาง่าย) เช่น Conformed Dimension, Degenerate dimension, Dimension Outrigger ถ้ามีความผิดพลาดตรงไหน หรือออฟเข้าใจผิดตรงไหนก็บอกกันไ้ด้นะคะ

Audit dimension (unit 15)

– เป็น dimension  ที่ทำให้เรารู้ประสิทธิภาพสูงสุดในการวิเคราะห์ในการโหลดข้อมูลลง fact
– โดยแต่ละแถวของ dimension นี้ จะสามารถบ่งบอกที่มาของข้อมูล , คุณภาพของข้อมูล , เวลาในการ extract ข้อมูล , เวอร์ชั่นของ software ที่ใช้ในการ extract ข้อมูลใหม่

Conformed Dimension (Unit 15)

– เป็นการรวมใช้ dimension เดียวกัน สำหรับต่าง business process
– เมื่อเรากำหนด business process ใหม่เพิ่มขึ้นจากเดิม จึงควรพยายามนำ dimension จาก business process เดิมมาใช้ แต่ยังคงต้องสอดคล้องกับ granularity ของ business process ใหม่นี้ด้วย
– ตัวอย่างเช่น การประกันภัยมีการใช้ dimension ร่วมกันคือ policy holder, coverage, cover item
– ถ้าเกิดมีนิยามของ attribute ต่างกันหรือมีค่าต่างกัน  จะไม่ใช่ Conformed Dimension

Degenerate dimension (Unit 4)

–  Degenerate Dimension คือ Dimension ที่ปรากฏใน Fact Table แต่จะไม่มี Dimension Table เป็นของตัวเอง สร้างขึ้นเพื่อดูค่าอื่นๆที่ไม่ได้เกี่ยวข้องโดยตรง แต่อาจจะเพื่อความสะดวกในการอ้างอิงหรือดู เช่น เลขกำกับภาษี
– ประโยชน์ของ Degenerate dimensions

1. ช่วยให้เรารวมสินค้าที่แยกกันอยู่ เพื่อให้ง่ายในการดูข้อมูล
2. ช่วยให้เราหาจำนวนเฉลี่ยในรายการสั่งซื้อได้
3. ใช้เชื่อมกลับ data warehouseไปยังฐานข้อมูลเดิม

Dimension Outrigger (Unit 6)

– เราจะกล่าวได้ว่า Dimension เป็น Snowflake ก็ต่อเมื่อ คอลัมน์ที่มีค่าซ้ำๆกันใน Dimension นั้นสามารถแยกมาเป็นอีก Dimension และสามารถเชื่อมโยงกลับไปยัง Dimension เดิมของคอลัมน์นั้นๆได้ และเราจะเรียก Dimension ที่อนุญาตให้มี Snowflake ได้นั้นว่า Dimension Outrigger
– ปกติแล้วการสร้างคลังข้อมูลจะพยายามหลีกเลี่ยง Snowflake แต่บางกรณีมีความจำเป็น เช่น ต้องการสร้าง Customer Dimension ที่เก็บข้อมูลส่วนตัวของลูกค้าแต่ละคนเช่น ชื่อ ที่อยู่ รวมถึงข้อมูลทางสถิติของประชากรในประเทศที่ลูกค้าคนนั้นอาศัยอยู่ด้วย ซึ่งหากลูกค้าคนใดอาศัยอยู่ในประเทศเดียวกัน ข้อมูลในส่วนของสถิติประชากรของประเทศก็จะเหมือนกันทั้งหมด จะทำให้ข้อมูลเกิดความซ้ำซ้อนกันขึ้น ในกรณีนี้เราจึงควรแยกข้อมูลสถิติประชากรของประเทศออกมาเป็น Dimension Outrigger

Junk dimension (Unit 5)

– เป็นการเอา indicator ที่อยู่ใน Fact มารวมกันแล้วใส่เป็น key อันเดียวแทนเพื่อประหยัดพื้นที่ในการเก็บ
– สาเหตุของการมี Junk dimension

1. เมื่อเราพบข้อมูลพวกเดียวกับ Pay Type Dimension มากๆเราจะพยายามละทิ้งเอาไว้ใน Fact Table ซึ่งเป็นอะไรที่ไม่สมควรนักที่จะทำให้ต้องเก็บข้อมูลจำนวนมากโดยไม่จำเป็น เพราะข้อมูลจะแบ่งเป็นชนิดด้วย ซึ่งจะได้ข้อมูลที่มากขึ้นแน่นอน
2. แยกออกเป็น Dimension ก็จะพบว่าถ้าเราแยกข้อมูลเหล่านี้ออกเป็น Dimension ก็จะทำให้เกิด Dimension มากขึ้นซึ่งก็มีปัญหาอีกเช่นเดียวกัน
3. ถ้าเราจะเอาออกไปเลยก็ทำไม่ได้อีกเช่นกันเพราะมีความสำคัญอยู่ สำหรับบางคำถาม บางข้อมูลที่ต้องการ

– ดังนั้นสิ่งที่เหมาะสมในการจัดการกับข้อมูลจำพวกนี้คือการนำข้อมูลจำพวกนี้ เก็บรวมเอาไว้เป็น Junk Dimension คือเก็บรวมไว้ใน Dimension เดียวกันนั่นเอง เป็นวิธีการที่จะทำให้ไม่เกิดปัญหาข้างต้นดังที่กล่าวมา

Mini-dimension (Unit 6)

– การเปลี่ยนแปลงอย่างรวดเร็วของข้อมูลขนาดใหญ่ในหน่วยล้านแถว การเปลี่ยนแปลงของข้อมูลในลักษณะนี้เราไม่สามารถใช้วิธีการเดียวกับหัวข้อ Slowly Changing Dimensions ได้เนื่องจากข้อมูลมีเป็นจำนวนมาก และการเปลี่ยนแปลงเกิดขึ้นบ่อย
– ดังนั้นเราจะมีวิธีการแก้ปัญหานี้โดยการแยกข้อมูลใน Attribute ที่มักจะถูกนำมาวิเคราะห์หรือมีการเปลี่ยนแปลงบ่อยๆออกมาจาก Dimension เดิมมาสร้างเป็น Dimension ใหม่เรียกว่า Minidimension และค่าของ Attribute นั้นๆจะเป็นค่าที่เรากำหนดไว้ล่วงหน้าและเก็บค่าไว้เป็นช่วงๆ เช่น สำหรับ Customer Dimension ข้อมูลของลูกค้าที่มีการเปลี่ยนแปลงบ่อยๆได้แก่ อายุ เงินเดือน เป็นต้น
– การสร้าง Mini-dimensionนั้นสามารถมีมากกว่า 1 dimension ในกรณีที่

1. Attribute ของ Mini-dimensionมีจำนวนมากเกินไป
2. Attribute ของ Mini-dimensionมีที่มาจากแหล่งข้อมูลต่างกัน

Multivalued dimension (Unit 13,15)

– สำหรับกรณีที่ attribute ใน dimension มีค่าหลายค่า ถ้าหากเก็บข้อมูลทั้งหมดไว้ใน dimension เดียวกันจะทำให้เกิดค่าซ้ำๆในหลาย attribute จึงทำให้ต้องสร้าง dimension ใหม่ขึ้นมา

Role-Playing Dimension (Unit 5)

– Role-Playing Dimension เป็น dimension อันเดียวที่มีการอ้างไปถึงหลายครั้ง โดยมีการสร้างตาราง dimension เสมือนขึ้นมาที่มีความเป็นอิสระต่อกัน และทำการเรียกใช้ Role-playing
– ในคลังข้อมูลเกิดขึ้นเมื่อมี dimension ใด dimension หนึ่งปรากฎอยู่ใน ตาราง Fact  ในเวลาเดียวกัน
– ตัวอย่างของ Role-playing เช่นในกรณีของ Time Dimension ซึ่งเป็น Dimension ของวันที่จะถูกพบเห็นในทุก ตาราง fact เพราะว่า เราจะพิจารณาประสิทธิภาพโดยดูจากเวลาเสมอ อาจมีการใช้ Role-playing โดยมีการใช้ตารางของวันหลายแบบ เช่น Request Date (วันที่ลูกค้าต้องการรับสินค้า), Order Date (วันที่สั่งสินค้า), Ship Date (วันที่ส่งสินค้า), Assembly Date(วันที่ประกอบสินค้า), Arrival Date(วันที่ลูกค้าได้รับสินค้าจริงๆ)

Slowly changing dimension (unit 15)

– เป็นเทคนิคที่นำมาใช้กับ dimension ที่ค่อนข้างจะคงที่ หรือกล่าวคือ ทีการเปลี่ยนแปลงเกิดขึ้นอยู่ช้าๆ  และเปลี่ยนแปลงแค่บางจุดเล็กๆ     โดยวิธีในการจัดการ กับการเปลี่ยนแปลงแบบนี้อยู่ 3 วิธี คือ

1. Type 1 :  Overwrite the  value  คือ การเขียนค่าใหม่ทับไปบนค่าเก่า ทำให้ค่าใน  attribute นั้น มีค่าที่เป็นปัจจุบันที่สุดในทันที เกิดข้อดีโดย สามารถทำงานได้ง่ายและรวดเร็ว แต่ ก็ไม่สามารถ เก็บข้อมูล หรือประวัติการเปลี่ยนแปลงเก่าๆได้
   ข้อดี : สามารถทำงานได้ง่ายและรวดเร็ว
   ข้อเสีย : ไม่รองรับการเก็บข้อมูลเก่าๆก่อนการเปลี่ยนแปลง
2. Type 2 : Add a Dimension Row การเปลี่ยนแปลงแบบนี้ จะทำการสร้าง row เพิ่มขึ้นมาใหม่ เพื่อยังคงเก็บข้อมูลเก่าๆ ไว้อยู่ หรือเป็นการประวัติของการเปลี่ยนแปลง ทำให้สามารถนำข้อมูลเก่าๆ มาวิเคราะห์ได้ แต่ก็จะทำให้เกิด row ที่มีค่าอื่นๆที่ไม่ได้เปลี่ยนแปลงซ้ำกัน และยังไม่เหมาะสมกับ dimention ที่มีการเติบโตรวดเร็ว หรือกล่าวได้ว่า row ใหม่ที่เพิ่มขึ้นไปนั้น มีค่าเกิน 1ล้านแถว
   ข้อดี : สามารถวิเคราะห์ข้อมูลเก่าๆได้อย่างถูกต้อง, สามารถ track การเปลี่ยนแปลงที่เกิดขึ้นได้อย่างถูกต้อง, ไม่จำเป็นต้อง rebuild การ aggregation ใหม่หลังจากที่มีการเปลี่ยนแปลง
   ข้อเสีย : ไม่เหมาะสำหรับ dimension ที่มีการเติบโตที่รวดเร็ว, จะสามารถมีการข้อมูลเก่าและใหม่มาใช้งานร่วมกันได้
3. Type 3 : Add a Dimension Column คือ เราจะเพิ่ม column ไปใน dimension  อีกหนึ่ง column เพื่อเก็บค่าใหม่ที่เปลี่ยนแปลง ทำให้เกิดข้อดีโดยเราจะสามารถเปรียบเทียบค่าเก่า และใหม่ ได้ง่าย และรวดร็วกว่า type 2 แต่ข้อมูลนั้นก็ไม่ครอบคลุมเท่ากับ type 2 ด้วยเช่นกัน
   ข้อดี :สามารถใช้งานข้อมูลเก่าและใหม่มาใช้งานร่วมกันได้
   ข้อเสีย : ไม่เหมาะกับงานที่ต้องการ track ข้อมูลเปลี่ยนแปลงบ่อยๆ, นิยมใช้ไม่มากนัก

Super dimension (unit 11)

– Super dimension เป็นการรวม dimension ที่มีความเกี่ยวพันกันให้กลายเป็น dimension เดียว คล้ายกับการสร้าง junk dimension แต่ต่างตรงที่ Super dimension เป็นการรวมที่มองถึงความสัมพันธ์ระหว่าง dimension ด้วย ทําให้สามารถนําไปวิเคราะห์ข้อมูลเพิ่มเติมได้ และออกรายงานได้ดีขึ้น
– ภาพตัวอย่างแสดงตารางที่เกิดจาก Cartesian Product ระหว่าง Class of Service Flown กับ Class of Service Purchased โดยอธิบายความสัมพันธ์ของทั้งสองตารางโดยใช้  Class Group  Class Change Indicator

Time of day as a Dimension or Fact (Unit 11)

– เวลาในแต่ละวันจะให้ เป็น Dimension หรือ Fact ขึ้นอยู่กับธุรกิจว่าเป็นอย่างไร  ต้องการวิเคราะห์อะไร แล้วจึงเลือกให้เหมาะสมว่าจะให้ เป็น Dimension หรือ Fact
– Time of day as a Dimension : จะจัดการเวลาในแต่ละวันให้เป็น Dimension หนึ่งเลย กล่าวคือ เราจะแยก Time-of-day Dimension ออกจาก Date Dimension เพราะถ้าเกิด Date Dimension และ Time Dimension อยู่ใน Dimension เดียวกันแล้ว จํานวนแถวที่อยู่ ใน Dimension นั้นจะมีมากมายมหาศาล ถ้าเราแยก Dimension กัน ก็จะช่วยลดพื้นที่ในการเก็บลงไปได้ จากนั้นรวมกลุ่มของเวลา เช่น เป็นช่วง ๆ ช่วงละ 15 นาที, แต่ละชั่วโมง, ช่วงกลางวันหรือกลางคืน ฯลฯ ซึ่งการที่เรารวมกลุ่มแบบนี้จะทําให้ผู้บริหารสามารถ  roll up หรือ filter ช่วงเวลา ซึ่งแบบนี้จะมีประโยชน์กว่าเพราะจะช่วยในการออกรายงานและ การนําข้อมูลมาวิเคราะห์
– Time of day as a Fact : จะจัดการเวลาในแต่ละวันให้เป็น Fact   ซึ่งการทําแบบนี้จะเกิดขึ่นเมื่อผู้บริหารไม่ต้องการที่จะ roll up หรือ filter ช่วงเวลาในแต่ละวัน จะเป็นการระบุเวลาเป็นตัวเลขลงไปเลยใน Fact เรียกว่า Simple Numeric Fact ซึ่งการ ระบุเวลาลงไปนั้นจะอยู่ในรูปของวินาที หรือนาที โดยที่คํานวณจากเวลาตอนเที่ยงคืนเป็นจุดอ้างอิง

Verbose dimension (Unit 11)

– verbose dimension คือ dimension ที่เก็บข้อมูลในลักษณะฟุ่มเฟือย ใช้พื้นทีในการเก็บข้อมูลในปริมาณมาก
– ตัวอย่างเช่น verbose date dimension ที่มีการเก็บ/แบ่งรายละเอียดของวันเป็นหน่วยย่อยที่สุด (Granularity) คือ วันในสัปดาห์ สัปดาห์ที่  เดือนอะไร โดยอาจจะมีบาง attributes ของ date ที่เก็บข้อมูลที่มีรายละเอียดเพิ่มเติมเฉพาะด้านเช่น เก็บบางช่วงเวลาที่ใช้เฉพาะในการดําเนินกิจกรรมทางด้านการเงิน (อาทิ เวลาปิดงบ การเงิน, วันสิ้นงวดบัญชี เป็นต้น)และอาจจะทําการเก็บข้อมูลวันหยุดทําการของบริษัทนั่นเอง
– เพื่อแก้ปัญหาที่เกิดจาก verbose date dimension จึงมีการนำเทคนิค outrigger มาช่วยในการแก้ปัญหา โดยทำการแยก attributes ที่มีการเปลี่ยนแปลงบ่อยๆ ออกมา