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

สัปดาห์ที่ 1: พื้นฐานคลังข้อมูลและ
แพลตฟอร์มข้อมูลองค์กร

Enterprise Data Platforms and Production-Grade Agentic AI Workflows

โครงการประจำหลักสูตร

Project: Agentic E-Commerce Intelligence Platform

"เปลี่ยนข้อมูลดิบให้กลายเป็นปัญญาประดิษฐ์ที่ช่วยตัดสินใจเชิงกลยุทธ์"

ส่วนที่ 1: ภารกิจและนิยามของคลังข้อมูล

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

1
อธิบาย ภารกิจ (Mission) และนิยามของคลังข้อมูลได้อย่างถูกต้องตามหลักการของ Inmon
2
เปรียบเทียบความแตกต่างระหว่างระบบ Operational (OLTP) และระบบ Informational (DW/DSS) ได้
3
วิเคราะห์วิกฤตข้อมูล (Information Crisis) และความต้องการ Subject Area ในธุรกิจอีคอมเมิร์ซ
4
ระบุแนวโน้มของคลังข้อมูลสมัยใหม่ที่ขับเคลื่อนด้วย Cloud และ Agentic AI

"คลังข้อมูลคืออะไร?"

"คลังข้อมูล คือ กลุ่มข้อมูลที่ถูกจัดระเบียบตาม หัวเรื่อง (Subject-Oriented), มีการ บูรณาการ (Integrated), มีความเป็น ประวัติศาสตร์ (Time-Variant) และ คงสภาพ (Non-Volatile) เพื่อสนับสนุนการตัดสินใจ"

— Bill Inmon, บิดาแห่งคลังข้อมูล
แหล่งอ้างอิง: Bill Inmon and the Definition of Data Warehouse

ภารกิจของคลังข้อมูล

"To Publish Data Assets"

ภารกิจหลักคือการ "จัดพิมพ์" ทรัพยากรข้อมูลขององค์กร เพื่อให้ผู้ใช้สามารถนำไปประกอบการตัดสินใจได้อย่างมีประสิทธิภาพสูงสุด ความสำเร็จวัดจาก การใช้งานจริงของ User ไม่ใช่แค่ขนาดของฐานข้อมูล

เข้าถึงง่าย (Accessible)
น่าเชื่อถือ (Credible)
ทันเวลา (Timely)
อ่านเพิ่มเติม: The Data Warehouse ETL Toolkit (Ralph Kimball)

ระบบปฏิบัติการ vs. ระบบข้อมูล

Operational (OLTP)

"Making the wheels of business turn"

  • • เป้าหมาย: บันทึกรายการประจำวัน (Transaction)
  • • ข้อมูล ปัจจุบัน, มีรายละเอียดสูง
  • • การใช้งาน อ่าน/เขียน ตลอดเวลา
  • • ตัวอย่าง การกดสั่งซื้อสินค้าในแอปฯ

Informational (DW/DSS)

"Watching the wheels of business turn"

  • • เป้าหมาย สนับสนุนการตัดสินใจ/วิเคราะห์
  • • ข้อมูล ประวัติศาสตร์, สรุปผลแล้ว
  • • การใช้งาน อ่านอย่างเดียว (Read-Intensive)
  • • ตัวอย่าง รายงานยอดขายแยกตามภูมิภาครายปี
กิจกรรมกลุ่ม: วิกฤตข้อมูล (20 นาที)

ทำไมข้อมูลมหาศาลถึงตอบคำถามง่ายๆ ไม่ได้?

"CEO ถามว่า: 'ทำไมกำไรสุทธิของเราในภาคใต้ลดลง 15% ในเดือนที่ผ่านมา ทั้งที่ยอดขายเพิ่มขึ้น?'"

ภารกิจของนักศึกษา:

  1. ระบุ แหล่งข้อมูล (Silos) ที่คุณต้องไปค้นหาเพื่อตอบคำถามนี้
  2. คุณจะพบกับอุปสรรคอะไรบ้างเมื่อพยายามรวมข้อมูลเหล่านี้?
  3. ทำไมฐานข้อมูล OLTP ของฝ่ายขายเพียงอย่างเดียวถึงไม่เพียงพอ?

เฉลยและการวิเคราะห์กิจกรรม

1. แหล่งข้อมูล (Silos)

  • • Sales DB ยอดขายต่อรายการ
  • • Logistics DB ค่าขนส่งที่เพิ่มขึ้น
  • • Marketing DB ค่าโฆษณา/โปรโมชั่น
  • • Inventory DB ต้นทุนการเก็บสินค้า

2. อุปสรรคที่พบ

  • • รหัสสินค้าไม่ตรงกัน ระหว่างระบบคลังกับระบบขาย
  • • ข้อมูลกระจัดกระจาย อยู่บนคลาวด์บ้าง ใน Excel บ้าง
  • • ขาดข้อมูลประวัติ ข้อมูลเก่าถูกทับ (Overwrite) ไปแล้ว

3. บทสรุปของ DW

คลังข้อมูลจะนำข้อมูลเหล่านี้มา Integrated (รวมศูนย์) และ Subject-Oriented (เน้นเรื่องกำไร) เพื่อให้วิเคราะห์สาเหตุ (Root Cause) ได้ในที่เดียวโดยไม่ต้องทำ Manual Join ทุกครั้ง

💡 หัวใจสำคัญ คลังข้อมูลเปลี่ยน "ข้อมูลรายการ" ให้กลายเป็น "ความรู้เชิงกลยุทธ์"

วิวัฒนาการสู่ Agentic AI

คลังข้อมูลยุคใหม่ไม่ใช่แค่ที่เก็บข้อมูล แต่เป็นสมองของ AI เอเจนต์:

🤖
Agentic Views (AV-SQL) AI ที่สามารถแปลงคำถามภาษาธรรมชาติให้เป็น SQL Query ที่ซับซ้อนได้เอง
☁️
Cloud Native แยก Storage ออกจาก Compute (เช่น Snowflake) เพื่อรองรับ Scale ที่ไร้ขีดจำกัด
🔧
Self-Healing ท่อส่งข้อมูลที่ซ่อมแซมตัวเองได้ด้วย ML เมื่อเกิดความผิดพลาดของข้อมูล
งานวิจัยอ้างอิง: AV-SQL: Decomposing Complex Text-to-SQL Queries with Agentic Views
เวิร์กชอป: ออกแบบความต้องการ (25 นาที)

การระบุ "Subject Area" และ "Metrics"

โจทย์: ในฐานะทีม Data Engineer ของโครงการ "E-Commerce Intelligence Platform"

ขั้นตอนที่ 1: กำหนดหัวเรื่อง

ระบุ 3 Subject Areas ที่สำคัญที่สุดสำหรับธุรกิจขายของออนไลน์ (เช่น Sales, Inventory)

ขั้นตอนที่ 2: กำหนดตัวชี้วัด (Metrics)

ภายใต้หัวเรื่อง "Sales" คุณต้องการวัดตัวเลขอะไรบ้าง? (ระบุมา 3 อย่าง)

Dataset แนะนำสำหรับการฝึกฝน: Brazilian E-Commerce Public Dataset by Olist

เฉลย: Information Package (Sales Subject)

Dimensions (มิติการมอง) Hierarchies (ลำดับชั้น) Facts / Metrics (ตัวเลขที่วัด)
Time (เวลา) Year > Quarter > Month > Day - Total Sales Amount
- Quantity Sold
- Gross Profit Margin
- Order Count
Product (สินค้า) Category > Brand > SKU
Location (พื้นที่) Region > State > City

"ตารางนี้จะเป็นรากฐานในการออกแบบ Star Schema ในสัปดาห์ที่ 3 ต่อไป"

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

คลังข้อมูลคือสภาพแวดล้อม ไม่ใช่แค่ซอฟต์แวร์ เพื่อเปลี่ยนข้อมูลเป็นความรู้

ระบบ OLTP เน้นการทำงาน ระบบ Informational เน้นการวิเคราะห์เชิงลึก

Agentic AI ต้องการคลังข้อมูลที่มี Semantic Layer และ Governance ที่แข็งแกร่ง

สัปดาห์หน้า: การปะทะกันของยักษ์ใหญ่ - Kimball vs Inmon!

ส่วนที่ 2:
ระเบียบวิธีออกแบบคลังข้อมูล

"Inmon vs. Kimball: การเลือกสถาปัตยกรรมที่ใช่สำหรับองค์กร"

หัวข้อการเรียนรู้

  • • แนวทาง Top-Down ของ Bill Inmon (Corporate Information Factory)
  • • แนวทาง Bottom-Up ของ Ralph Kimball (Bus Architecture)
  • • การเปรียบเทียบความเร็วในการส่งมอบและบทบาทของผู้ใช้

แนวทางของ Bill Inmon

Corporate Information Factory (CIF)

Inmon เชื่อในการสร้าง "Atomic Data Warehouse" ที่เก็บข้อมูลในรูปแบบ 3rd Normal Form (3NF) เพื่อเป็นแหล่งความจริงเดียวของทั้งองค์กรก่อน แล้วจึงกระจายข้อมูลไปยัง **Data Marts** ของแต่ละแผนก

✅ ข้อมูลมีความถูกต้องสูงสุด (Data Integrity)
✅ ลดความซ้ำซ้อนของข้อมูลทั้งองค์กร
❌ ใช้เวลาออกแบบนาน (4-9 เดือนเพื่อเริ่มเห็นผล)
❌ ผู้ใช้เข้าถึงข้อมูลได้ยากในระยะแรก
แหล่งข้อมูล: ประวัติและทฤษฎีของ Bill Inmon

แนวทางของ Ralph Kimball

Data Warehouse Bus Architecture

Kimball เน้นการสร้าง Data Marts ตามกระบวนการทางธุรกิจ (เช่น ยอดขาย) โดยใช้ Dimensional Modeling (Star Schema) และเชื่อมโยงกันด้วย Conformed Dimensions

✅ ส่งมอบผลลัพธ์เร็ว (เป้าหมาย 90 วัน)
✅ ผู้ใช้เข้าใจง่าย เข้าถึงข้อมูลได้โดยตรง
❌ เสี่ยงต่อการเกิดข้อมูลไม่ตรงกันหากขาดมาตรฐาน
❌ ต้องมีการจัดการ Conformed Dimensions อย่างเข้มงวด
เทคนิคการสร้างแบบจำลอง: Kimball Dimensional Modeling Techniques

สรุปความแตกต่าง: Inmon vs. Kimball

หัวข้อเปรียบเทียบ Bill Inmon (Top-Down) Ralph Kimball (Bottom-Up)
โมเดลข้อมูลหลัก ERD / 3rd Normal Form (3NF) Dimensional / Star Schema
เป้าหมายหลัก Technical Solution / IT Driven Business Need / User Driven
ระยะเวลาส่งมอบ นาน (เน้นโครงสร้างองค์กร) เร็ว (เน้นกระบวนการธุรกิจ)
บทบาทของผู้ใช้ เป็นผู้รับข้อมูล (Passive) มีส่วนร่วมสูง (Active Participant)

อ้างอิงจาก: Business Intelligence Journal, Winter 2004

กิจกรรมกลุ่ม: วาดเส้นทางข้อมูล (30 นาที)

"The Data Flow Challenge"

โจทย์โครงการ: แพลตฟอร์มอีคอมเมิร์ซอัจฉริยะ

ให้นักศึกษาวาดผังการไหลของข้อมูล (Data Flow) ตั้งแต่ระบบต้นทางไปจนถึงมือผู้ใช้ โดยแบ่งกลุ่มทำ 2 แนวทาง:

กลุ่ม A: แนวทาง Inmon

วาดข้อมูลจาก Ingestion -> 3NF Warehouse -> Data Marts

กลุ่ม B: แนวทาง Kimball

วาดข้อมูลจาก Ingestion -> Bus/Conformed Dimensions -> Data Marts

เฉลยขั้นตอนที่ 1: Inmon's Strategy (CIF)

1
Ingestion ดึงข้อมูลดิบจาก Silos (Web Sales, Inventory, CRM) เข้าสู่ Staging
2
Atomic Warehouse (EDW) ทำ ETL เพื่อจัดเก็บข้อมูลในรูปแบบ 3NF (เน้นความถูกต้องของเอนทิตีธุรกิจ)
3
Departmental Data Marts สร้าง "หน้าต่างข้อมูล" ที่ดึงจาก EDW ไปสรุปผลตามความต้องการของแผนก (เช่น Sales Mart)

ทำไมต้อง Inmon? เพื่อสร้างโครงสร้างข้อมูลที่แข็งแกร่งที่สุดและรองรับการขยายตัวในระยะยาวขององค์กรขนาดใหญ่

เฉลยขั้นตอนที่ 2: Kimball's Strategy (Bus)

1
Requirements Discovery ระบุกระบวนการธุรกิจ (Business Process) ที่เร่งด่วนที่สุด (เช่น ยอดขายรายวัน)
2
Dimensional Design สร้าง Star Schema (Fact + Dimensions) โดยตรงเพื่อความรวดเร็ว
3
Integration via Bus ใช้ Conformed Dimensions (เช่น มิติ 'สินค้า' ที่เหมือนกัน) เชื่อมทุก Mart เข้าด้วยกัน

ทำไมต้อง Kimball?

บทสรุปกิจกรรม: คุณจะเลือกแนวทางไหน?

เกณฑ์การตัดสินใจ (Criteria):

เลือกแนวทาง Inmon หาก...

  • • มีงบประมาณและทีมงาน IT ขนาดใหญ่
  • • ต้องการความถูกต้องระดับสูงสุดของข้อมูล 3NF
  • • สามารถรอผลลัพธ์ได้นานกว่า 6 เดือน

เลือกแนวทาง Kimball หาก...

  • • ต้องการความเร็วและผลลัพธ์แบบ Agile
  • • ข้อมูลเน้นที่ Business Metrics และ KPI
  • • ผู้ใช้ต้องการวิเคราะห์ข้อมูลด้วยตัวเอง (Self-Service)
💡 คำแนะนำสมัยใหม่: ใช้แนวทาง Hybrid - สร้างชั้นข้อมูลแบบ Inmon บน Cloud (Bronze/Silver) และส่งมอบแบบ Kimball (Gold/Mart)

บทสรุปส่วนที่ 2 และทรัพยากร

✅ เข้าใจความแตกต่างระหว่างแนวทางข้อมูลศูนย์กลาง (Inmon) และแนวทางกระบวนการธุรกิจ (Kimball)

✅ รู้วิธีเลือกสถาปัตยกรรมให้เหมาะกับ "Project Context" ของโครงการอีคอมเมิร์ซ

Dataset สำหรับโครงการ:

Brazilian E-Commerce Public Dataset

งานวิจัยอ้างอิง:

Spider 2.0: Enterprise Text-to-SQL Workflow
ส่วนต่อไป: การเริ่มออกแบบ Star Schema ครั้งแรกของคุณ!

ส่วนที่ 3:
การตัดสินใจเลือกและเริ่มต้นโครงการ

"เลือกรากฐานที่ถูกต้อง เพื่อสร้างอนาคตที่ยั่งยืนให้ข้อมูลองค์กร"

สิ่งที่เราจะเรียนรู้

🎯 เกณฑ์การเลือก Methodology
🤝 แนวทางผสมผสาน (Hybrid)
🚀 Project Phase 2 Kick-off
🤖 AI-Native Architecture

ปัจจัยในการตัดสินใจเลือกแนวทาง

1. งบประมาณและทักษะ

Inmon ต้องการทีม IT และงบประมาณสูงกว่าเพื่อวางโครงสร้างส่วนกลาง

2. ความเร็ว (Time-to-Value)

Kimball ให้ผลลัพธ์แรกได้ใน 90 วัน เหมาะกับธุรกิจที่ต้องการความไว

3. ความซับซ้อนของข้อมูล

หากแหล่งข้อมูลกระจัดกระจายและไม่ตรงกันอย่างรุนแรง Inmon จะช่วยเรื่อง Integrity ได้ดีกว่า

อ่านเพิ่มเติม: The Data Warehouse Lifecycle Toolkit

แนวทางแบบผสมผสาน (Hybrid Approach)

"Inmon in the Back, Kimball in the Front"

  • 🔹 Backend สร้างชั้นข้อมูลแบบ Inmon (3NF/Data Vault) เพื่อความแม่นยำ
  • 🔹 Frontend ส่งมอบข้อมูลแบบ Kimball (Star Schema) เพื่อให้ User ใช้งานง่าย
  • 🔹 Result ได้ทั้งความเสถียรของระบบและประสิทธิภาพในการวิเคราะห์

"เป็นที่นิยมมากในยุค Cloud Lakehouse เพราะสามารถทำ Medallion Architecture ได้ง่าย"

อนาคต: AI-Native Headless Warehouses

ในปัจจุบัน แนวคิดการออกแบบต้องรองรับ AI Agents ที่เข้าถึงข้อมูลได้โดยตรงผ่าน **Semantic Layer**:

🧠
**Headless Analytics:** แยกตรรกะธุรกิจออกจากเครื่องมือ BI เพื่อให้ AI และมนุษย์เห็นความจริงเดียวกัน
🤖
**Agentic Workflows:** AI ที่ซ่อมแซมท่อส่งข้อมูล (Self-healing) และออกแบบ Schema เบื้องต้นได้เอง
งานวิจัยอ้างอิง: Production-Grade Agentic AI Workflows Guide
กิจกรรมกลุ่ม: METHODOLOGY PITCH (20 นาที)

คุณจะเลือกแนวทางไหน?

สถานการณ์จำลอง (Scenario):

"บริษัท Startup อีคอมเมิร์ซของคุณเพิ่งได้รับเงินทุน และต้องการ **รายงานวิเคราะห์ยอดขายและพฤติกรรมลูกค้า** เพื่อนำเสนอบอร์ดบริหารภายใน **3 เดือน** ทีมงานของคุณมี Data Engineer เพียง 2 คน และทุกคนถนัด SQL เป็นหลัก"

ภารกิจ:

  1. คุณจะแนะนำแนวทาง **Inmon** หรือ **Kimball**? เพราะเหตุใด?
  2. หากคุณเลือกแนวทาง **Hybrid** คุณจะวางโครงสร้างอย่างไรให้ทันเวลา?
  3. ระบุ 1 ประโยชน์ที่ **AI เอเจนต์** จะช่วยในสถานการณ์ที่ทีมงานมีจำกัดเช่นนี้

เฉลยขั้นตอนที่ 1: วิเคราะห์ข้อจำกัด (Constraints)

ข้อจำกัดด้านเวลา (3 เดือน)

เวลาน้อยเกินไปสำหรับแนวทาง **Inmon** แบบดั้งเดิมที่ต้องใช้การออกแบบ 3NF ทั้งองค์กรนานหลายเดือน

ข้อจำกัดด้านบุคลากร (2 คน)

ทีมเล็กต้องเน้นแนวทางที่ **User-facing** และส่งมอบผลลัพธ์ได้เร็วที่สุดเพื่อพิสูจน์มูลค่าโครงการ

💡 คำแนะนำเบื้องต้น: เลือกแนวทาง **Kimball (Bottom-Up)** เป็นหลักเพื่อความเร็ว

เฉลยขั้นตอนที่ 2: วางโครงสร้าง Hybrid (Medallion Style)

**Bronze/Silver:** ใช้แนวคิด Inmon เก็บข้อมูลกึ่งโครงสร้าง (JSON) และทำความสะอาดเบื้องต้นเพื่อความถูกต้อง
**Gold:** ใช้แนวคิด Kimball สร้าง **Star Schema** สำหรับงานวิเคราะห์ที่ User ต้องการทันที
"การใช้ Cloud Warehouse ช่วยให้เราทำ 3NF ในชั้น Silver และ Star Schema ในชั้น Gold ได้พร้อมกันโดยไม่เสียเวลามากเกินไป"

เฉลยขั้นตอนที่ 3: บทบาทของ AI เอเจนต์

ตัวช่วยสำหรับทีมขนาดเล็ก:

1

**Autonomous Error Handling:** AI เอเจนต์สามารถตรวจสอบและซ่อมแซมความผิดพลาดใน Pipeline ของทีมงานที่มีจำกัดได้ (Self-healing)

2

**AV-SQL Interface:** ช่วยให้ CEO สามารถถามคำถามภาษาธรรมชาติและได้ SQL Query กลับมาทันที ลดภาระทีมวิศวกรในการเขียนรายงานรายวัน

เริ่มต้นโครงการ Phase 2

การวิเคราะห์ระบบต้นทาง (Source Systems)

ก่อนจะลงมือสร้างคลังข้อมูล คุณต้องเข้าใจ **"ความจริงในระบบปฏิบัติการ"** ของโครงการก่อน:

✅ ทำ **Source System Tracking Report** ระบุ DBMS และขนาดข้อมูล
✅ ระบุ **System-of-Record** สำหรับข้อมูลแต่ละประเภท (เช่น Customer, Sales)
✅ สำรวจ **Data Quality Issues** เบื้องต้นที่ต้องได้รับการแก้ไข
Dataset ฝึกฝน: Brazilian E-Commerce (Olist)

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

ไม่มีสถาปัตยกรรมใดที่ดีที่สุดแบบเดียว ทุกอย่างขึ้นกับบริบทธุรกิจ (Business Context)
ในยุคคลาวด์ แนวทาง **Hybrid** กลายเป็นมาตรฐานใหม่ที่ให้ทั้งความเร็วและความถูกต้อง
การเตรียมข้อมูลให้พร้อมสำหรับ AI เอเจนต์ต้องการ **Semantic Layer** ที่ชัดเจนตั้งแต่วันแรก

แหล่งข้อมูลแนะนำ:

Cloud DW For Dummies Medallion Architecture Agentic AI Workflows Paper
See you Week 3: Dimensional Modeling I