แผนการเรียนรู้
/

สัปดาห์ที่ 3: การสร้างแบบจำลองมิติ I
การออกแบบ Star Schema

จากความต้องการทางธุรกิจสู่โครงสร้างฐานข้อมูลเพื่อการวิเคราะห์,

หัวใจสำคัญของสัปดาห์นี้

"การกำหนดระดับรายละเอียด (Grain) คือรากฐานที่สำคัญที่สุดของการทำคลังข้อมูล",

Phase 1: Foundation of Dimensional Design

ผลลัพธ์การเรียนรู้

1
ประยุกต์ใช้กระบวนการออกแบบ 4 ขั้นตอน (4-Step Design Process) ของ Kimball ได้
2
กำหนดและประกาศ Grain ของตารางข้อเท็จจริงได้อย่างแม่นยำ,
3
จำแนกประเภทของ Fact (Additive vs. Semi-additive) ได้อย่างถูกต้อง,
4
อธิบายความจำเป็นของการใช้ **Surrogate Keys** ในตารางมิติได้,

ส่วนที่ 1: รากฐานและ Grain

กระบวนการออกแบบ 4 ขั้นตอน

  1. 1. **เลือกกระบวนการธุรกิจ (Select the Business Process)**
  2. 2. **ประกาศระดับรายละเอียด (Declare the Grain)**
  3. 3. **ระบุมิติ (Identify the Dimensions)**
  4. 4. **ระบุข้อเท็จจริง (Identify the Facts)**

การประกาศ Grain: หัวใจของแบบจำลอง

1. Business Process

คือ กิจกรรมระดับปฏิบัติการ (เช่น การขาย, การรับคืนสินค้า) ที่สร้างตัวเลขเพื่อนำมาวัดผล

2. The Grain

คือ "หนึ่งแถวในตาราง Fact คืออะไร?" ต้องเป็นระดับที่ละเอียดที่สุดที่เป็นไปได้เพื่อให้วิเคราะห์ได้ทุกมุมมอง,

⚠️ คำเตือน: อย่าผสม Grain ที่ต่างกันในตาราง Fact เดียวกัน!
กิจกรรมกลุ่ม (15 นาที)

ภารกิจ: ประกาศ Grain ของอีคอมเมิร์ซ

โจทย์: จากชุดข้อมูล Olist E-Commerce จงระบุ Grain Statement ของตารางการขาย

"หนึ่งแถวในตาราง `Order_Items_Fact` คือ..."

A) หนึ่งคำสั่งซื้อต่อหนึ่งลูกค้า
B) หนึ่งรายการสินค้าในหนึ่งคำสั่งซื้อ

เฉลยขั้นตอนที่ 1: การกำหนด Grain

คำตอบที่ถูกต้องคือ: B

**"One row per individual product item in a transaction."**

**เหตุผล:**

  • ในหนึ่ง Order ลูกค้าอาจซื้อสินค้าหลายชนิด (Product IDs)
  • หากใช้ Grain เป็น "หนึ่งคำสั่งซื้อ" (A) เราจะไม่สามารถวิเคราะห์ยอดขายแยกตามรายสินค้าได้
  • Grain ระดับ "Item Line" ช่วยให้เรา Drill-down ไปหาข้อมูลที่ละเอียดที่สุดได้

ส่วนที่ 2: ตารางข้อเท็จจริง (Fact Tables)

ลักษณะของตาราง Fact,

ประกอบด้วยมาตรวัดที่เป็นตัวเลข (Quantitative Measurements) และ Foreign Keys ที่เชื่อมไปยังตารางมิติ

มาตรวัด (Facts)
คีย์เชื่อมโยง (FKs)

ประเภทของ Facts,

Fully Additive Facts

บวกกันได้ทุกมิติ (สินค้า, เวลา, พื้นที่)

  • • ยอดขาย (Amount)
  • • จำนวนหน่วย (Quantity)
  • • กำไร (Profit)

Semi-additive Facts

บวกกันได้บางมิติ แต่ **ห้ามบวกข้ามเวลา**

  • • ยอดคงเหลือในบัญชี (Account Balance)
  • • จำนวนสินค้าในสต็อก (Inventory Count)
  • • อัตราผลตอบแทน (%)
เวิร์กชอป (20 นาที)

การระบุ Facts สำหรับโครงการ

จากรายการต่อไปนี้ จงเลือก Facts ที่ควรอยู่ใน `Order_Fact` ของเรา:

1. รหัสสั่งซื้อ (Order_ID)
2. ราคาสินค้า (Price)
3. ค่าขนส่ง (Freight_Value)
4. วันที่สั่งซื้อ (Order_Date)
5. ชื่อลูกค้า (Customer_Name)
6. จำนวนที่ซื้อ (Quantity)

เฉลยขั้นตอนที่ 2: การคัดเลือก Facts

Facts ที่ถูกต้อง (ตัวเลขที่วัดผลได้):

  • ✅ **Price:** มาตรวัดพื้นฐาน (Fully Additive)
  • ✅ **Freight_Value:** มาตรวัดต้นทุน (Fully Additive)
  • ✅ **Quantity:** จำนวนนับ (Fully Additive)

ทำไมข้ออื่นถึงไม่ใช่?

Order_ID และ Date เป็นมิติ (Dimension), Customer_Name เป็นคุณสมบัติ (Attribute) ไม่ใช่ตัวเลขที่ใช้วัดผลโดยตรงในตาราง Fact,

ส่วนที่ 3: ตารางมิติและคีย์ตัวแทน

ลักษณะของมิติ (Dimension),

คือ ตารางที่เก็บคำอธิบาย (Context) เพื่อตอบคำถามว่า ใคร (Who), อะไร (What), ที่ไหน (Where), เมื่อไหร่ (When)

"Dimension Tables must use Surrogate Keys!",

ทำไมต้องใช้ Surrogate Keys?

Natural Key (ID จากต้นทาง)

"เสี่ยงต่อการเปลี่ยนแปลงและซ้ำซ้อน"

  • • ขึ้นอยู่กับระบบ ERP/CRM ต้นทาง
  • • หากระบบต้นทางลบหรือเปลี่ยน ID ประวัติใน DW จะเสีย
  • • มักเป็นตัวอักษรทำให้ Query ช้า

Surrogate Key (คีย์ตัวแทน)

"สร้างความอิสระและติดตามประวัติได้"

  • • เป็นตัวเลข (Integer) ที่ DW สร้างเอง
  • • ช่วยในการจัดการ **Slowly Changing Dimensions (SCD)**
  • • เพิ่มประสิทธิภาพในการ Join ข้อมูล
กิจกรรมสุดท้าย (30 นาที)

ออกแบบ Star Schema ครั้งแรก

ภารกิจ Phase 1 Project:

จงวางโครงสร้าง **Star Schema** สำหรับ "Sales Analysis" โดยระบุ:

1. Fact Table Name & Facts
2. Dimension Tables (อย่างน้อย 4 มิติ)
3. กำหนด Primary Key และ Foreign Keys

เฉลยขั้นตอนที่ 3: โครงสร้าง Star Schema สมบูรณ์,

Dim_Product

PK: Product_Key (SK)

Product_ID (NK)

Category, Brand

Dim_Customer

PK: Customer_Key (SK)

Customer_ID (NK)

City, State

Sales_Fact

FK: Product_Key

FK: Customer_Key

FK: Date_Key

FK: Store_Key

Facts:

• Sales_Amount

• Quantity

• Freight_Value

Dim_Date

PK: Date_Key (SK)

Full_Date, Year

Quarter, Month

Dim_Store

PK: Store_Key (SK)

Store_ID (NK)

Region, Manager

บทสรุปสัปดาห์ที่ 3

1. การออกแบบเริ่มจากการเลือก **Business Process** และระบุ **Grain**
2. **Fact Table** ต้องเป็นตัวเลขที่บวกกันได้ (Fully Additive) เพื่อการ Drill-down,
3. **Surrogate Keys** สำคัญมากในการปกป้อง DW จากการเปลี่ยนแปลงของระบบต้นทาง,
Next Week: Slowly Changing Dimensions (SCDs)