"เปลี่ยนข้อมูลดิบให้เป็นปัญญาประดิษฐ์ที่ช่วยตัดสินใจทางธุรกิจ"
"คลังข้อมูล คือ กลุ่มของข้อมูลที่ถูกจัดระเบียบตาม หัวเรื่อง (Subject-Oriented), บูรณาการเข้าด้วยกัน (Integrated), คงสภาพไว้ (Non-volatile) และ แปรผันตามกาลเวลา (Time-variant) เพื่อสนับสนุนการตัดสินใจของผู้บริหาร"
"บริษัทของคุณมีฐานข้อมูลแยกกัน (Silos) เช่น ระบบขายหน้าเว็บ, ระบบคลังสินค้า, ระบบการตลาด และระบบขนส่ง... CEO ถามคุณว่า 'ทำไมกำไรสุทธิของเราในภาคใต้ถึงลดลง 15% ในเดือนที่ผ่านมา ทั้งที่ยอดขายเพิ่มขึ้น?'"
คำสั่ง:
ข้อมูลปัจจุบันขาดความ บูรณาการ (Integrated) ทำให้เห็นภาพรวมทั้งบริษัทไม่ได้ และขาด บริบททางเวลา (Time-variant) ทำให้เปรียบเทียบแนวโน้มอดีตกับปัจจุบันไม่ได้
| มิติ: เวลา (Time) | มิติ: สถานที่ (Location) | มิติ: สินค้า (Product) |
|---|---|---|
| ปี (Year) | ภูมิภาค (Region) | หมวดหมู่ (Category) |
| ไตรมาส (Quarter) | จังหวัด (State) | ยี่ห้อ (Brand) |
| เดือน (Month) | เมือง/เขต (City) | ชื่อสินค้า (Name) |
| ตัวเลขที่ใช้วัด (Facts): ยอดขายจริง, ยอดพยากรณ์, กำไรเบื้องต้น, จำนวนหน่วยที่ขาย | ||
*ตารางนี้จะเป็นรากฐานในการออกแบบ Star Schema ในสัปดาห์ที่ 3 ต่อไป*
DW ไม่ใช่แค่ฐานข้อมูล แต่เป็น สภาพแวดล้อม (Environment) เพื่อการวิเคราะห์
ภารกิจของ DW คือการ "จัดพิมพ์ (Publish)" ข้อมูลให้ผู้ใช้ตัดสินใจได้เอง
หัวใจสำคัญคือการเข้าใจ ความต้องการทางธุรกิจ (Business Requirements)
ข้อมูลถูกเก็บในรูปแบบแถว (Rows) และคอลัมน์ (Columns) โดยแต่ละแถวต้องมีความเป็นเอกลักษณ์
**Primary Key:** ระบุตัวตนในตาราง
**Foreign Key:** สร้างความสัมพันธ์ระหว่างตาราง
"ข้อมูลทุกอย่างต้องขึ้นตรงกับ **คีย์ (The Key)**, **คีย์ทั้งหมด (The Whole Key)** และ **ไม่มีอะไรนอกจากคีย์ (Nothing but the Key)**"
การมองเห็นความสัมพันธ์ช่วยให้เราออกแบบคลังข้อมูลได้แม่นยำขึ้น
ความสัมพันธ์แบบ One-to-Many: ลูกค้า 1 คน สั่งซื้อได้หลายครั้ง
"ออกแบบโครงสร้างตาราง 3NF สำหรับระบบ **คำสั่งซื้อ (Orders)** ในร้านค้าออนไลน์ โดยให้กำจัดข้อมูลที่ซ้ำซ้อนออกไปให้หมด"
ชุดข้อมูลที่ต้องจัดการ:
เป้าหมาย:
กำจัด Repeating Groups (หนึ่งช่องเก็บข้อมูลได้ค่าเดียว)
ข้อมูลที่ไม่ใช่คีย์ต้องขึ้นกับ Primary Key ทั้งหมด (กำจัด Partial Dependency)
ข้อมูลที่ไม่ใช่คีย์ต้องไม่ขึ้นกับคีย์อื่น (กำจัด Transitive Dependency)
ทำไมต้องออกแบบแบบนี้?
✅ **3NF** เหมาะมากสำหรับระบบเก็บข้อมูล (Data Capture) เพราะความถูกต้องแม่นยำ
❌ แต่ **3NF** อาจช้าเกินไปสำหรับระบบวิเคราะห์ (Data Analytics) ระดับ Petabytes
เตรียมพบกับ ส่วนที่ 3:
เพิ่มหรือลดกำลังประมวลผลได้อิสระจากขนาดข้อมูล ช่วยลดค่าใช้จ่ายมหาศาล
รองรับข้อมูลระดับ Petabytes และผู้ใช้พร้อมกันจำนวนมากโดยประสิทธิภาพไม่ตก
การจัดการข้อมูลให้สะอาดและพร้อมใช้ด้วยโครงสร้าง 3 เลเยอร์
Raw / Immutable
เก็บข้อมูลดิบทุกอย่างที่ได้รับจากแหล่งต้นทาง ห้ามเปลี่ยนแปลง
Cleaned / Conformed
ลบข้อมูลซ้ำ ทำความสะอาด และจัดรูปแบบตามเอนทิตีธุรกิจ (เช่น Customer)
Curated / Business
ข้อมูลที่ถูกสรุปผล (Aggregated) และพร้อมส่งต่อให้ BI หรือ AI เอเจนต์
ในแพลตฟอร์มข้อมูลยุคใหม่ AI ไม่ได้เป็นแค่เครื่องมือถาม-ตอบ แต่ทำหน้าที่เป็น **"เอเจนต์"** ที่ทำงานแทนเราได้:
จงระบุว่างานต่อไปนี้ควรอยู่ในเลเยอร์ใดของ Medallion Architecture:
**Gold:** การสรุปยอดขายรายเดือน (Aggregation เพื่อรายงานผล)
**Bronze:** รับไฟล์ JSON ดิบ (Ingestion พื้นที่พักข้อมูลดิบ)
**Silver:** แก้ไขการสะกดชื่อและตรวจสอบความถูกต้อง (Cleaning/Validation)
"จำไว้ว่า: Silver คือจุดที่ข้อมูลเริ่มมี 'คุณภาพ' ส่วน Gold คือจุดที่ข้อมูลมี 'มูลค่าทางธุรกิจ'"
แนะนำชุดข้อมูลเริ่มต้น:
Brazilian E-Commerce Public Dataset by Olist1. คลังข้อมูลคือสภาพแวดล้อมเพื่อการตัดสินใจเชิงกลยุทธ์ (DSS)
2. 3NF ดีสำหรับระบบปฏิบัติการ แต่ 'แพ็กเกจข้อมูล' สำคัญกว่าในการวิเคราะห์
3. อนาคตคือ Cloud Lakehouse และ AI ที่ช่วยจัดการข้อมูลอัตโนมัติ