การออกแบบโครงสร้างข้อมูล (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) บนคอลัมน์คีย์นอกตัวที่สองในตารางทางผ่านเสมอ

ทฤษฎีและกลไกการทำงาน (How it works): ในขณะที่ระบบหลักต้องการการทำ Normalization (แยกตารางเพื่อกันข้อมูลซ้ำ) ระบบประมวลผลเชิงวิเคราะห์ (OLAP) จะกลับขั้วโดยทำ **Denormalization** (การหลอมรวมตารางเข้าด้วยกันล่วงหน้า) เพื่อเลี่ยงคำสั่ง Join สถาปัตยกรรมระดับเอนจิ้นจะใช้ **Materialized Views** ซึ่งจะประมวลผลคิวรีล่วงหน้าและเขียนสรุปบันทึกสเตทลงบนแผ่นดิสก์ถาวรเสมือนตารางจริง ทำให้เวลาเรียกอ่านไม่ต้องประมวลผลใหม่ตั้งแต่ต้นสาย

-- Creating Materialized View on analytical query in ClickHouse
CREATE MATERIALIZED VIEW mv_daily_sales
ENGINE = SummingMergeTree()
PRIMARY KEY (sale_date, product_id)
AS SELECT 
    toDate(created_at) as sale_date,
    product_id,
    sum(amount) as daily_revenue
FROM db.sales
GROUP BY sale_date, product_id;
                    

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

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ในระบบ relational ดั้งเดิม ข้อมูลใน Materialized View จะไม่ยอมรับการอัปเดตแบบเรียลไทม์จนกว่าจะรันคำสั่ง `REFRESH MATERIALIZED VIEW` ซึ่งกินพลังคอมพิวต์สูง แก้ไขโดยใช้เอนจิ้น OLAP อย่าง ClickHouse ที่มีระบบ `SummingMergeTree` คอยอัปเดตพาร์ทิชันสรุปผลอัตโนมัติเมื่อมีข้อมูลใหม่ไหลเข้าท่อ

ทฤษฎีและกลไกการทำงาน (How it works): Data Vault 2.0 เป็นเทคนิคการทำโมเดลข้อมูลระดับ Enterprise Data Warehouse ที่ออกแบบมาเพื่อรองรับการดึงข้อมูลจากหลายแหล่งที่มีโครงสร้างเปลี่ยนไปมาบ่อยๆ (Agile Data Warehouse) โดยจะแยกโมเดลออกเป็น 3 ประเภทหลัก: - **Hubs**: เก็บเฉพาะกุญแจทางธุรกิจ (Business Keys) และ Hash Key หลัก ไม่มีการเก็บแอตทริบิวต์อื่น - **Links**: เก็บความสัมพันธ์แบบ N:M ระหว่าง Hubs เพื่อสะท้อนเส้นทางกระบวนการธุรกิจ - **Satellites**: เก็บข้อมูลเชิงบรรยาย (Context/Attributes) และประวัติศาสตร์ที่ผูกกับ Hub หรือ Link ทำให้การเปลี่ยนแปลงข้อมูลไม่กระทบแกนกลาง

-- โครงสร้างพื้นฐานของ Data Vault 2.0
CREATE TABLE hub_customer (
  hk_customer_id CHAR(32) PRIMARY KEY, -- MD5 Hash
  customer_business_key VARCHAR(50) NOT NULL,
  load_date TIMESTAMP NOT NULL,
  record_source VARCHAR(50) NOT NULL
);

CREATE TABLE sat_customer_details (
  hk_customer_id CHAR(32) REFERENCES hub_customer(hk_customer_id),
  load_date TIMESTAMP NOT NULL,
  first_name VARCHAR(100),
  last_name VARCHAR(100),
  hash_diff CHAR(32), -- ใช้เทียบเช็คว่าแถวมีข้อมูลเปลี่ยนไหม
  PRIMARY KEY (hk_customer_id, load_date)
);
                    

Use Case ในชีวิตจริง (Real-world Scenario): การควบรวมกิจการของธนาคารสองแห่ง (Mergers and Acquisitions) ทำให้ต้องดึงข้อมูลลูกค้าจากระบบฐานข้อมูลต่างค่ายมารวมกัน Data Vault จะเปิดให้สร้างระบบกลางที่ปรับขยายได้ง่ายโดยไม่ต้องรื้อสคีมาแบบดั้งเดิมทิ้งทั้งหมด

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): โครงสร้าง Data Vault อาศัยการ Join ข้ามตารางจำนวนมหาศาล (Hub + Link + Satellites) ทำให้ประสิทธิภาพการคิวรีอ่านช้ามาก จึงต้องนำไปสร้าง Information Marts เป็นสคีมาดาว (Star Schema) หรือ View ชั้นบนอีกทีให้ผู้ใช้งานใช้

ทฤษฎีและกลไกการทำงาน (How it works): Anchor Modeling คล้ายกับ Data Vault ขั้นสุดยอด (6NF - Sixth Normal Form) ข้อมูลทั้งหมดจะถูกแบ่งแยกออกถึงระดับรายแอตทริบิวต์ (คอลัมน์) แต่ละคอลัมน์จะมีตารางของตัวเองที่ผูกกับตาราง Anchor (แกนหลัก) ข้อดีคือถ้ามีความต้องการเพิ่มคอลัมน์หรือคุณสมบัติใหม่ๆ ในอนาคต (Schema Evolution) ระบบจะไม่ต้อง Alter Table หลักเลย แค่เพิ่มตารางแอตทริบิวต์ใหม่เข้าไป

-- Anchor Modeling Structure
CREATE TABLE anc_employee (  -- Anchor
  emp_id INT PRIMARY KEY
);

CREATE TABLE att_employee_name ( -- Attribute
  emp_id INT REFERENCES anc_employee(emp_id),
  emp_name VARCHAR(100),
  changed_at TIMESTAMP,
  PRIMARY KEY (emp_id, changed_at)
);

CREATE TABLE att_employee_salary ( -- Attribute
  emp_id INT REFERENCES anc_employee(emp_id),
  salary DECIMAL(10,2),
  changed_at TIMESTAMP,
  PRIMARY KEY (emp_id, changed_at)
);
                    

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

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ซับซ้อนมากเกินไปสำหรับโปรเจกต์ขนาดเล็กถึงกลาง การต้องสกัดข้อมูลเพื่อสร้าง Report 1 หน้า อาจต้องเขียน JOIN กว่า 20 ตาราง ทำให้วิศวกรและนักวิเคราะห์มือใหม่สับสน

ทฤษฎีและกลไกการทำงาน (How it works): การจัดการมิติข้อมูลที่มีการเปลี่ยนแปลงตามกาลเวลา (SCD) ใน Dimensional Modeling มีการแบ่งมาตรฐานระดับสูงกว่า Type 1, 2, 3: - **Type 0**: ข้อมูลคงที่ตลอดกาล ห้ามเปลี่ยน (เช่น วันเกิด) - **Type 4**: แยกตาราง History Table ออกไปเลย เพื่อให้ตารางหลักมีเฉพาะค่าปัจจุบันและมีขนาดเล็ก - **Type 5**: ใช้ Type 4 ร่วมกับ Type 1 คือเก็บคีย์อ้างอิงของอดีตในตารางหลักด้วย - **Type 6**: เป็นการรวมร่าง Hybrid ระหว่าง 1, 2, 3 (1+2+3 = 6) คือ เก็บทั้ง Historical Row (Type 2), Current Attribute (Type 1), และ Historical Attribute (Type 3) ไว้ในแถวเดียวกันหมดเพื่อความครบถ้วนสูงสุด

-- SCD Type 6 Dimension Table Example
CREATE TABLE dim_customer_type6 (
  customer_sk INT PRIMARY KEY, -- Surrogate Key
  customer_id VARCHAR(50),     -- Business Key
  current_state VARCHAR(50),   -- Type 1 (อัปเดตทับทั้งหมดเมื่อมีการเปลี่ยน)
  historical_state VARCHAR(50),-- Type 3 (ค่าก่อนหน้าของ Row นี้)
  valid_from DATE,             -- Type 2
  valid_to DATE,               -- Type 2
  is_current BOOLEAN           -- Type 2
);
                    

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

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): SCD Type 6 ซับซ้อนในเชิงกระบวนการ ETL เป็นอย่างมาก การรันไปป์ไลน์ต้องเขียนคำสั่ง UPDATE และ INSERT สลับไปมาหลายจังหวะ ทำให้เกิดโอกาสข้อมูลหลุดลอสต์ (Data Anomaly) ได้ง่ายหากกระบวนการล้มเหลวกลางทาง