Introduction  to Dimensional Modeling : Retail Sales Case Study

*อ่านประกอบกับสไลด์ CPE_step_5_6 ของอาจารย์จะช่วยให้เข้าใจมากขึ้น

Seen Design Concepts

Dimensionality Modeling
– เป็น logical structure อย่างนึงที่มี fact table เป็นหัวใจของคลังข้อมูล โดยจะเก็บข้อมูลเกี่ยวกับ event or fact ต่างๆ จาก operational system ซึ่งการเก็บจะละเอียดแค่ไหนนั้นก็ต้องมาระบุในขั้นตอนที่สอง จะมีการอ้างอิงข้อมูลที่สามารถทำการ denormalized ได้
– Fact  ถูกสร้างโดย event ที่เกิดขึ้นในอดีต โดยส่วนมากแล้วจะไม่ค่อยเปลี่ยน

Fact Table and Measures
– ข้อมูลส่วนใหญ่ที่จะมาเก็บในคลังข้อมูลจะอยู่ใน fact table ซึ่งจะมีจำนวน row ที่ค่อนข้างเยอะมากๆ เมื่อเปรียบเทียบกับ dimension table
– สามารถมีได้หลาย fact table ได้
– ข้อมูลจะอ่านได้อย่างเดียวเท่านั้น และไม่ค่อยเปลี่ยน แต่ถ้าข้อมูลใน operational เปลี่ยน ก็มี defect กลับมาที่คลังข้อมูลด้วยเหมือนกัน แต่ว่าการอัพเดตของคลังข้อมูลส่วนใหญ่จะเป็นการเพิ่มข้อมูลเข้าไป ซึ่งในการเพิ่มข้อมูลเข้าไป อาจมีการเปลี่ยนแปลงภายในของ attribute ก็ต้องมีการเปลี่ยนแปลงตามไปด้วย
– fact table ส่วนมากจะเก็บข้อมูลที่เป็นตัวเลข เพราะว่าเราอยากจะให้มีการบวกสะสมได้ด้วย
– พอเราได้ measure มาแล้ว เราจะมาหา dimension ที่มาอธิบายว่าเราต้องการดูในมุมไหนบ้าง ก็มีใช้ FK ชี้ไป ยัง PK

Dimension  Tables
– Dimension  Tables จะเก็บคอลัมน์เยอะมากๆ โดยมีจำนวน row ที่น้อยกว่า fact table และสามารถทำให้ข้อมูลที่อยู่ในคลังข้อมูลเข้าใจง่ายยิ่งขึ้น
– ช่วยให้เราสามารถใส่ constriant ในแต่ละ attributes
– มี PK ที่อ้างอิงไปยัง FK ของ fact table
– ส่วนใหญ่อยู่ในรูป text

Difference between ER & Dimensional Model
– เวลาเรามี star schema ขึ้นมา input ส่วนใหญ่จะเป็น ER diagram ซึ่ง ER diagram จะมีความสัมพันธ์แบบ many-to-many โดยจะมี numeric และ additive แฝงอยู่แล้วซึ่งสามารถแปลงมาเป็น fact table ได้

Benefits of Dimension Model
– ดูง่ายกว่า ER diagram สำหรับผู้ใช้
– การดึงข้อมูลทำได้เร็วกว่า โดยมีหัวใจข้อมูลอยูที่ fact table และอาจจะมีการ join กันบ้างเล็กน้อย
– ออกรายงานได้อย่างไม่ยุ่งยากซับซ้อน

Six-process  for designing dimensional models

Step1: Select the Business Process
– ไป get requirement มาก่อน
– เลือก business process และพิจารณา่ data source ด้วย
– ทำความเข้าใจกับ ความต้องการทางธุรกิจ
– ในธุรกิจนึงจะประกอบไปด้วยหลาย Business process โดยให้เราเลือกว่าจะทำคลังข้อมูล (พัฒนา data mart )เกี่ยวกับ business process ไหน

Step 2: Declare the Grain
– นิยาม grain  (granularity) หน่วยย่อยที่สุดที่จะเก็บลงในคลังข้อมูล
– ใช้ตอบคำถาม “What exactly is a fact record for this table”
– โดยปกติจะเก็บหน่วยที่ย่อยที่สุด (most atomic information) เช่นเวลาไปซื้อของ ในแต่ละ sale transaction ระดับที่ละเอียดที่สุดคือระดับ line items โดยเจาะไปเลยว่า transaction นั้นซืิ้ออะไรบ้าง อย่างละเท่าไหร่
– โดยพื้นฐานจะมีหลายรูปแบบ เช่น individual transactions, snapshots, line items

Step 3: Choose the Dimensions
– Dimensions ก็คือเป็น set ของ context สำหรับการตอบคำถามเกี่ยวกับ fact ในfact table
– Time dimension must always exist : ถ้าไม่มีก็ผิดไปเลย ^ ^
– dimension ที่น้อยที่สุด ก็จะถูกกำหนดโดย grain และ  dimension อื่นๆ ที่เพิ่มขึ้นมาก็ขึ้นกับ source data ด้วย

Step 4: Identify the Facts
– fact จะต้อง match กับ grain
– ที่เราไม่ควรจะใส่ใน fact เช่น ส่วนที่ไม่ใ่ช่ตัวเลข,
– ถ้าอยู่ใน fact table เดียวกันต้องมี grain เหมือนกัน ถ้าไม่เหมือนกันต้องไปสร้าง fact table เพิ่ม
– Additive Facts : fact มีการบวกสะสมได้ และจะต้องทำได้กับทุกๆ dimension, ใช้ sum ได้
– Semi-additive Facts : fact ที่ sum ไม่ได้ทุก dimension เช่นพวก account balance, อุณหภูมิ โดยอาจจะใช้ Average ช่วย
– non-additive : fact ที่ sum ไม่ได้

เงื่อนไขการมี fact table
– ถ้ามีการใช้ dimension ไม่เท่ากัน ก็อยู่ใน fact table เดียวกันไม่ได้
– ถ้ามี grain อยู่คนละระดับกัน อยู่ใน fact table เดียวกันไม่ได้

Step 5: Store pre-calculations  in the fact table
– pre-calculation : fact ที่เก็บอะไรที่คำนวนไว้แล้ว ซึ่งมันจะช่วยช่วยใน query performance
– summary data (aggregated value) เป็นค่าของผลรวม

Step 6: Defining attributes of the dimension  tables
– หา attributes มาให้ dimension table ต่างๆ โดยใส่ให้เยอะที่สุดซึ่งขึ้นกับ source data
– และ attribute ควรจะเป็นชื่อเต็ม ไม่ควรเป็นตัวย่อ ซึ่งถ้ามีข้อมูลเป็นตัวย่อมาจะถูกแปลงเป็นตัวเต็มตอนที่ ETL

Dimension Table Attributes

Date Dimension
– ต้องมีทุกครั้ง

Product Dimension
– describes every stock keeping unit (SKU) in the grocery store

Store Dimension
– describes every store in our grocery chain

Promotion Dimension
– เราอยากรู้ว่าสินค้าที่ขายด้วยโปรโมชั่นนั้นขายดีไหม, โปรโมชั่นไหนทำให้ขายได้ดีกว่ากัน
– describes the promotion  conditions under which a product was sold
– เก็บข้อมูลเฉพาะสินค้าที่ถูกขายด้วยโปรโมชั่นนั้นๆ แต่ถ้าไม่ได้ขายก็ไ่ม่้เก็บ

Extensibility Design Concept

Factless fact table
– บางครั้งใน fact table ก็ไม่จำเป็นต้องเป็นการวัดก็ได้ โดยจะเรียกว่า Factless ซึ่งจะเก็บ event ที่เกิดขึ้น
– เช่น count  ในตาราง fact ซึ่งจะมีค่าเป็น 1 ตลอด ซึ่งไม่ต้องใส่ก็ได้

Degenerate Dimension
– Degenerate Dimension คือ dimension ที่ ไม่มี dimension table จริงๆ เกิดขึ้น
– operational control number เช่น order numbers, invoice numbers
– ที่ไม่มี dimension table จริงๆ เกิดขึ้นเนื่องจากว่ารายละเอียดต่างๆ ถูกไปเก็บใน dimension อื่นๆ หมดแล้ว
– ซึ่งบางครั้งอาจจะเป็น PK ให้กับ fact table ก็ได้

Role-Playing Dimension
– Role-Playing Dimension เป็น dimension อันเดียวที่มีการอ้างไปถึงหลายครั้ง
– เช่น เมือง, เวลา (arrive time, departure time)