Chapter 2  Retail Sales

Four-Step Dimensional Design Process

Step 1. Select the Business Process
– process เป็นกิจกรรมพื้นฐานทางธุรกิจในองค์กร ซึ่งโดยพื้นฐานแล้วจะได้รับการสนับสนุนจากระบบ source data-collection
– การรับฟังผู้ใช้เป็นส่วนสำคัญในการเลือกกระบวณการทางธุรกิจ
– การวัดประสิทธิภาพที่ได้ทำการวิเคราะห์ในคลังข้อมูล เป็นผลมาจากการกระบวณการวัดผลทางธุรกิจ
– เราไม่ได้อ้างถึงส่วนของธุรกิจหรือฟังก์ชั่นเมื่อเราพูดถึงเรื่อง business process
– ถ้าเราสร้างขอบเขตของ dimensional models เราจะไม่สามารถหลีกเลี่ยงการซ้ำกันของข้อมูลที่มี labels และ terminology ต่างกันได้เลย

Step 2. Declare the Grain of the business process
–  Declaring the grain หมายถึง การระบุได้อย่างแน่นอนว่าแต่ละ fact table row เป็นตัวแทนของอะไร
– grain จะแสดงถึง ระดับของรายละเอียดที่เกีี่ยวข้อกับการวัดของ fact table โดยมันจะช่วยตอบคำถาม “คุณจะอธิบายถึง single row ใน fact table ได้อย่างไร”
– การประกาศ grain อย่างไม่เหมาะสมจะไปรบกวน  data warehouse implementation

Step 3. Choose the Dimensions
– เลือก dimension ที่นำมาใช้กับแต่ละ fact table row
– เราต้องการที่จะตกแต่ง fact table ด้วยการ robust เซตของตัวแทน dimension คำอธิบายที่เป็นไปได้ทั้งหมดที่ทำบนค่าหนึ่งๆในการวัดแต่ละครั้ง
– ด้วยตัวเลือกของแต่ละ dimension เราจะทำการลิสต์แต่ละส่วนออกจากกันทั้งหมด, textlike
attributes ที่จะทำให้แต่ละ dimension table สมบูรณ์มากขึ้น

Step 4. Identify the Facts
– เป็นขั้นตอนของการระบุ numeric facts ที่อยู่ในแต่ละ fact table row
– candidate facts ทั้งหมดในการออกแบบจะต้องเป็นจริงในการนิยาม grain ในขั้นตอนที่ 2

Retail Case Study

– individual products are called  stock keeping units (SKUs), bar codes are called
universal product codes (UPCs)

Step 1. Select the Business Process
– ขั้นตอนแรกในการออกแบบคือการตัดสินใจเกี่ยวกับกระบวณการทางธุรกิจโดยมีการ รวมความเข้าใจของความต้องการของธุรกิจกับความเข้าใจของการเข้าถึงข้อมูล
–  Dimension model แรกที่จะสร้างขึ้นควรจะเป็นตัวที่ส่งผลกระทบมากสุด โดยมันควรจะตอบคำถามทางธุรกิจที่เร่งด่วนที่สุดและสามารถเข้าถึงสำหรับการ ดึงข้อมูลอย่างรวดเร็ว
– สำหรับ Retail Case Study ผู้จัดการต้องการเข้าใจการใช้จ่ายของลูกค้าดีขึ้นเหมือนกับที่ ระบบ POS ดังนั้นกระบวณการทางธุรกิจที่เรากำลังจะทำการจำลองคือ  POS retail sales ข้อมูลนี้จะอนุญาตให้เราวิเคราะห์ว่าสินค้าใดที่กำลังขายในร้านค้าใด ในวันที่เท่าไหร่ และในช่วงโปรโมชั่นใด

Step 2. Declare the Grain
– โดยเฉพาะอย่างยิ่งคุณควรจะพัฒนา dimension model สำหรับข้อมูลที่เล็กที่สุดที่ถูกจับโดยกระบวณการทางธุรกิจ ข้อมูลส่วนย่่อยนี้จะเป็นข้อมูลที่มีรายละเอียดมากสุดที่เก็บได้
– the most granular data is an individual line item on a POS transaction.
– เราเน้นไปที่ข้อมูลของ POS แต่แทนที่จะแสดง รายละเอียดของ ransaction line itemใน dimension model เราเลือกที่จะหาข้อมูลการขายที่มาพร้อมกับสินค้าและโปรโมชั่นในร้านค้าในวัน นึง ซึ่งในช่วงเวลานั้นสินค้าที่ขายรายวันทั้งหมดแทนสถานะสำหรับผลรวมของฐาน ข้อมูลการขาย
– A data warehouse almost always demands data expressed at the lowest possible grain of each dimension not because queries want to see individual low-level rows, but because queries need to cut through the details in very precise ways.

Step 3. Choose the Dimensions
– A careful grain statement determines the primary dimensionality of the fact table. It is then often possible to add more dimensions to the basic grain of the fact table, where these additional dimensions naturally take on only one value under each combination of the primary dimensions. If the additional dimension violates the grain by causing additional fact rows to be generated, then the grain statement must be revised to accommodate this dimension.
– ในกรณีนี้ เราเลือกตามคำอธิบายของ dimension : วันที่, สินค้า, ร้านค้า และโปรโมชั่น นอกจากนี้เรายังรวม เลขของตั่ว POS transaction เป็น dimension พิเศษด้วย

Step 4. Identify the Facts
– Fact เก็บจาก ระบบ POS รวม จำนวนของการขาย, ราคาขายต่อชิ้น และ  sales dollar amount (sales quantity *the unit price)
– Percentages and ratios, such as gross margin, are nonadditive. The numerator and denominator should be stored in the fact table. The ratio can be calculated in a data access tool for any slice of the fact table by remembering to calculate the ratio of the sums, not the sum of the ratios.

Dimension Table Attributes

Date Dimension

– Date Dimension เป็นหนึ่งใน dimension ที่เกือบจะมีในทุกๆ data mart เพราะว่าในความเป็นจริงทุกๆ data mart เป็น time series
– Date Dimension ใช้อ้างอิงถึง daily-grained dimension tables
– ในแต่ละคอลัมน์ในตาราง Date Dimension จะถูกำหนดโดยวันที่แถวนั้นเป็นตัวแทน
– day-of-week column ประกอบด้วยชื่อของวัน เช่น วันจันทร์
– day number in calendar month column จะเริ่มต้นด้วย 1 และลงท้ายด้วย 28,29,30,31 แล้วแต่เดือน ซึ่งช่วยในการเปรียบเทียบวันของแต่ละเดือน
– ในการที่ต้องระบุตาราง data dimension ให้ชัดเจนเพื่อความสะดวกและรวดเ็ร็วตอนที่ดึงข้อมูล

Product Dimension

– Product Dimension อธิบายถึง ทุกๆ stock keeping units (SKUs) ในร้านขายของชำ
– Product Dimension มักจะเป็นที่เก็บข้อมูลจาก operational product master file
– แต่ละ SKU จะต้องมีการกำหนดลำดับขั้นของการขายอย่างชัดเจน บาง attribute เช่น คำอธิบายของ SKU จะต้องไม่ซ้ำกับอันอื่น
– ตาราง product dimension ควรจะมี attribute ของคำอธิบาย 50 หรือมากกว่า แต่ละ attribute เป็นแหล่งข้อมูลที่สมบูรณ์สำหรับการจำกัดและการสร้าง row headers
– Drilling down in a data mart is nothing more than adding row headers from the dimension tables. Drilling up is removing row headers. We can drill down or up on attributes from more than one explicit hierarchy and with attributes that are part of no hierarchy.
– Product Dimension เป็นหนึ่งใน 2 หรือ 3 dimension หลักในทุกๆ data mart

Store Dimension

– Store Dimension อธิบายทุกๆร้านค้าในgrocery chain ไม่เหมือนกับ product master file ที่จะมีอยู่ในทุกๆ ธุรกิจร้ายขายของขนาดใหญ่ มันอาจจะไม่ได้เป็น comprehensive store master file
– product master file ต้องการถูกโหลดไปแต่ละร้านค้าตลอดเวลาที่มีการเปลี่ยนแปลง แต่อย่างไรก็ตาม แต่ละระบบ POS จะไม่ต้องการ store master
– The store dimension is the primary geographic dimension
– It is not uncommon to represent multiple hierarchies in a dimension table. Ideally, the attribute names and values should be unique across the multiple hierarchies.

Promotion Dimension

– Promotion Dimension เป็น dimension ที่น่าสนใจที่สุดใน schema โดยมันจะอธิบายเงื่อนไขของโปรโมชั่นในสินค้าที่จะูขาย ซึ่งรวมถึง การลดราคาชั่วคราว, end-aisle display, การโฆษณาในหนังสือพิมพ์ และคูปอง
– Promotion Dimension มักจะถูกเรียกว่าเป็น causal dimension เพราะว่ามันอธิบายองค์ประกอบผ่านสาเหตของการเปลี่ยนแปลงในการขายสินค้า
– You must avoid null keys in the fact table. A proper design includes a row in the corresponding dimension table to identify that the dimension is not applicable to the measurement.
– Promotion Coverage Factless Fact Table :
– จะไม่มี  fact table rows ที่มี zero facts สำหรับ SKUs ที่ไม่ได้ขาย เพราะว่ามันจะทำให้ Fact table มีขนาดใหญ่มากๆ
– The promotion coverage fact table keys would be date, product, store, and promotion
– coverage fact table ทำให้เรามองเห็นความสัมพันธ์ระหว่างคีย์ โดยระบุโดยโปรโมชั่น, independent of other events โดยเราจะเรียกมันว่า  factless fact table เพราะว่ามันไม่มีมาตรใน
การวัด
– ถ้าต้องการหาว่าสินค้าใดที่อยู่ในช่วงโปรโมชั่นแต่ไม่ได้ขายมี 2 ขั้นตอนคือ ให้ดึงข้อมูล promotion coverage table เพื่อดูสินค้าทั้งหมดที่อยู่ในโปรโมชั่น จากนั้นให้หาว่าสินค้าใดที่ขายจาก  POS sales fact table

Degenerate Transaction Number Dimension

– ถึงแม้ว่า POS transaction number จะคล้ายกับว่าเป็น dimension key ใน fact table เราจะำนำรายละเอียดทั้งหมดที่อาจจะลดลงใน POS transaction dimension เอาออก เมื่อเราได้ resulting dimension ที่ว่างเปล่าแล้ว เราจะเรียก POS transaction number ว่าเป็น degenerate dimension
– Degenerate dimension จะเกิดขึ้นบ่อยเมื่อ  grain ของ fact table เป็นตัวแทนของ a single transaction หรือ transaction line item เพราะว่า Degenerate dimension เป็นตัวแทนของ unique identifier of the parent
– Operational control numbers such as order numbers, invoice numbers, and bill-of-lading numbers usually give rise to empty dimensions and are represented as degenerate dimensions (that is, dimension keys without corresponding dimension tables) in fact tables where the grain of the table is the document itself or a line item in the document.