การออกแบบโครงสร้างข้อมูล (Star/Snowflake & SCD)

ทฤษฎีและกลไกการทำงาน (How it works): Slowly Changing Dimensions (SCD) คือสัญญารูปแบบการบันทึกเมื่อค่ามิติธุรกิจมีการเปลี่ยนรูป: - **SCD Type 0**: สภาพคงเดิมถาวร ไม่ยอมรับการแก้ไขใดๆ เช่น วันเกิดลูกค้า - **SCD Type 1**: เขียนแก้ไขทับฟิลด์เดิมทันทีโดยไม่บันทึกประวัติเก่า (ไม่มีประวัติย้อนหลัง) - **SCD Type 2**: วิธีการมาตรฐานระดับองค์กร โดยสร้างแถวใหม่ขึ้นมาบันทึกประวัติการแก้ไข และคุมช่วงเวลาใช้งานจริงด้วยคอลัมน์ `valid_from`, `valid_to` และแฟล็กบอกความใหม่ `is_current` - **SCD Type 3**: เพิ่มคอลัมน์ใหม่คู่ขนาน (เช่น `current_city` และ `previous_city`) บันทึกการย้อนอัปเดตย้อนหลังได้เพียง 1 ขั้น - **SCD Type 4**: สร้างตารางประวัติประวัติต่างหากแยกจากตารางมิติหลัก (History Table) เพื่อป้องกันขนาดตารางหลักบวมโต

-- SQL simulation of SCD Type 2 historic row creation
-- 1. Expire current address record row
UPDATE dim_customers 
SET valid_to = CURRENT_DATE, is_current = FALSE 
WHERE customer_key = 101 AND is_current = TRUE;

-- 2. Insert new record row with new address values
INSERT INTO dim_customers (customer_key, name, city, valid_from, valid_to, is_current)
VALUES (101, 'Chawin', 'Bangkok', CURRENT_DATE, '9999-12-31', TRUE);
                    

Use Case ในชีวิตจริง (Real-world Scenario): เมื่อลูกค้าเปลี่ยนที่อยู่อาศัยในการจัดส่งสินค้า การใช้ SCD Type 2 ทำให้เมื่อวิเคราะห์ข้อมูลการขายย้อนหลังของเดือนก่อน ยอดซื้อขายจะถูกจัดประเภทอยู่ในจังหวัดเก่าซึ่งเป็นที่อยู่จริงขณะเกิดรายการได้อย่างถูกต้อง

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ตารางมิติแบบ SCD Type 2 จะเพิ่มจำนวนแถวในฐานข้อมูลอย่างมากตามจำนวนรอบการแก้ไข ส่งผลให้คำสั่ง `JOIN` ทำงานช้าลง แก้ไขโดยใช้ดัชนีคุมบนฟิลด์ `is_current` หรือทำพาร์ทิชันเน้นข้อมูลยุคปัจจุบันออกจากประวัติอดีต

ทฤษฎีและกลไกการทำงาน (How it works): สถาปัตยกรรมคลังข้อมูลเชิงมิติ (Dimensional Modeling) นำเสนอโครงสร้างการจัดกลุ่มข้อมูลออกเป็น 2 บทบาท: - **Fact Tables**: ตารางเก็บค่าตัวเลขที่เกิดขึ้นจากการทำธุรกรรม (เช่น ยอดเงิน, จำนวนชิ้น) มีคีย์หลักเชื่อมไปยังตารางแวดล้อม - **Dimension Tables**: ตารางเก็บคำอธิบายบริบทแวดล้อม (เช่น รายละเอียดลูกค้า, ข้อมูลสินค้า) รูปแบบการจัดแบ่งมี 2 แบบ: - **Star Schema**: ตารางมิติถูกจัดรูปแบบขยาย (Denormalized) ให้แบนราบในตารางเดียว ไม่มีการเชื่อม `JOIN` ซ้อน ช่วยให้อ่านคิวรี่เร็วสุด - **Snowflake Schema**: ตารางมิติถูกแตกรองรับมาตรฐานสกีมาแบบบรรทัดฐาน (Normalized) เพื่อประหยัดพื้นที่จัดเก็บข้อมูล แต่แลกมาด้วยความเร็วคิวรี่ที่ช้าลงจากจ๊อยน์ที่ซับซ้อน

-- Star Schema Query Layout (Simplistic and optimized for analytical scanning)
SELECT d.city, SUM(f.sales_amount) as total_sales
FROM fact_sales f
JOIN dim_customers d ON f.customer_key = d.customer_key
GROUP BY d.city;
                    

Use Case ในชีวิตจริง (Real-world Scenario): คลังข้อมูลธุรกิจค้าปลีกออกแบบด้วย Star Schema เพื่อสนับสนุนให้โปรแกรมแดชบอร์ด BI สามารถดึงสรุปประมวลผลยอดขายแยกตามเขตและประเภทสินค้าล้านระเบียนมาแสดงผลได้แบบตอบสนองรวดเร็วทันใจผู้บริหาร

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ใน Star Schema ตารางมิติจะมีข้อมูลที่ซ้ำซ้อนกันจำนวนมาก (เช่น ชื่อจังหวัดซ้ำหลายหมื่นแถว) แก้ไขโดยยอมเสียพื้นที่จัดเก็บ (ซึ่งในปัจจุบันราคา Object Storage ต่ำมาก) แลกคืนมาด้วยความคุ้มค่าของการไม่ต้องรันคำสั่ง Join ขนาดใหญ่ให้เปลืองซีพียูประมวลผล

ทฤษฎีและกลไกการทำงาน (How it works): **Data Vault 2.0** ออกแบบมาเพื่อคลังข้อมูลระดับยักษ์ (Enterprise Scale) ที่ต้องป้อนข้อมูลเข้าขนานกันจากหลากหลายระบบ โดยมีโครงสร้างแยกออบเจกต์เป็น 3 ประเภทหลัก: - **Hubs**: เก็บเฉพาะคีย์รหัสธุรกิจหลัก (Business Keys) และคีย์แฮชระบุตัวตน ปราศจากรายละเอียดบริบท - **Links**: เก็บความสัมพันธ์และการทำจ๊อยน์เชื่อมโยงระหว่าง Hubs ด้วยค่าแฮช - **Satellites**: เก็บรายละเอียดและประวัติความเปลี่ยนแปลงของ Hub หรือ Link นั้นๆ พร้อมวันเวลาบันทึก สถาปัตยกรรมนี้รองรับการเขียนข้อมูลขนานกันได้เต็มสเกลเพราะไม่มีการล็อกตารางหรือเช็คเงื่อนไขความสัมพันธ์ต่างตาราง (Foreign Keys) ระหว่างนำเข้าข้อมูล

-- Data Vault Hub and Satellite schema design templates
CREATE TABLE hub_customers (
    customer_hash_key CHAR(32) PRIMARY KEY, -- MD5/SHA-256 of customer_id
    customer_id VARCHAR(50) NOT NULL,
    load_timestamp TIMESTAMP NOT NULL,
    record_source VARCHAR(50) NOT NULL
);

CREATE TABLE sat_customer_details (
    customer_hash_key CHAR(32) REFERENCES hub_customers(customer_hash_key),
    hash_diff CHAR(32) NOT NULL, -- Used to quickly detect if attributes changed
    email VARCHAR(100),
    phone VARCHAR(20),
    load_timestamp TIMESTAMP NOT NULL,
    record_source VARCHAR(50) NOT NULL,
    PRIMARY KEY (customer_hash_key, load_timestamp)
);
                    

Use Case ในชีวิตจริง (Real-world Scenario): บริษัทประกันภัยขนาดใหญ่ที่มีระบบไอทีและฐานข้อมูลลูกค้าแยกย่อย 10 ระบบ ดึงข้อมูลเข้ามารวมกันใน Data Vault โดยเชื่อมโยงผ่านเลขบัตรประชาชนเป็น Hub และให้รายละเอียดที่ต่างกันของแต่ละฐานข้อมูลแยกเก็บเป็น Satellites อิสระ

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การคิวรี่หาข้อมูลปัจจุบันจาก Data Vault มีความยุ่งยากสูงมากเพราะต้องรันคำสั่ง Join ข้อมูลข้าม Hub และ Satellite หลายสิบตาราง แก้ไขโดยสร้างตารางสรุปผลกลาง **Information Mart** ที่แปลงรูปแบบ Data Vault ให้กลายเป็นตารางมิติ Star Schema สำหรับเสิร์ฟผู้ใช้งานปลายทาง

ทฤษฎีและกลไกการทำงาน (How it works): การวางความสัมพันธ์ฐานข้อมูลเชิงสัมพันธ์ต้องควบคุมตามหลักการออกแบบ: - **One-to-Many (1:N)**: วางคีย์หลักของตารางแม่ (เช่น `customer_id`) ไปเป็นคีย์นอก (Foreign Key) ในตารางลูก (เช่น `orders`) คอนฟิกเพื่อคุมความถูกต้องข้อมูลเชิงโครงสร้าง - **Many-to-Many (N:M)**: ต้องแก้ไขโดยสร้างตารางทางผ่านตรงกลางเรียกว่า **Junction Table** (หรือ Bridge Table) เพื่อเก็บคู่ความสัมพันธ์ของคีย์จากสองตารางหลัก เพื่อป้องกันตารางข้อมูลบวมและขัดต่อหลักการ Normalization

-- Junction Table implementing Many-to-Many relationship with composite primary keys
CREATE TABLE orders_products (
    order_id UUID REFERENCES orders(order_id),
    product_id UUID REFERENCES products(product_id),
    quantity INTEGER NOT NULL CHECK (quantity > 0),
    PRIMARY KEY (order_id, product_id)
);
-- Compose index on the reverse lookup column to speed up queries
CREATE INDEX idx_products_orders ON orders_products(product_id);
                    

Use Case ในชีวิตจริง (Real-world Scenario): ในฐานข้อมูลการศึกษา คลาสเรียนหนึ่งคลาสมีนักเรียนลงเรียนได้หลายคน และนักเรียนหนึ่งคนก็สามารถลงเรียนได้หลายคลาสเรียน ระบบจึงใช้ตารางทางผ่าน `student_classes` เก็บประวัติความสัมพันธ์เพื่อให้เขียนคิวรีคอร์สเรียนได้ลื่นไหล

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การลืมสร้างดัชนีคุมพิกัดย้อนกลับบน Junction Table ส่งผลให้การ Join ข้อมูลย้อนทางคิวรีทำงานช้าเป็นเต่าคลาน แก้ไขโดยสร้างดัชนีเฉพาะเสริม (Composite Index หรือ Single Index) บนคอลัมน์คีย์นอกตัวที่สองในตารางทางผ่านเสมอ