สคีมาแบบดาวและการออกแบบคลังข้อมูล
ตารางข้อเท็จจริงและตารางมิติ ข้อแลกเปลี่ยนของการลดรูปแบบบรรทัดฐาน และการสร้างแบบจำลอง OLAP
สคีมาแบบดาวและการออกแบบคลังข้อมูล เป็นบทเรียน SQL Interview Prep ฟรีบน CoddyKit นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน SQL Interview Prep และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส SQL Interview Prep มีบทเรียนทั้งหมด 4 บทเรียน
OLTP เทียบกับ OLAP
คำถามเกี่ยวกับคลังข้อมูลเริ่มต้นจากความแตกต่างประการหนึ่งที่ผู้สัมภาษณ์คาดหวังให้คุณตอบได้อย่างชัดเจน: OLTP เทียบกับ OLAP
- OLTP (เชิงธุรกรรม): การอ่าน/เขียนขนาดเล็กจำนวนมาก ทำให้เป็นรูปแบบมาตรฐานอย่างเข้มงวดเพื่อรักษาความถูกต้องของข้อมูล ใช้ขับเคลื่อนแอป
- OLAP (เชิงวิเคราะห์): การอ่านเพื่อรวมข้อมูลขนาดใหญ่จำนวนน้อยครั้งจากข้อมูลย้อนหลัง ทำให้ข้อมูลไม่เป็นมาตรฐานโดยเจตนาเพื่อความรวดเร็ว ใช้ขับเคลื่อนรายงานและแดชบอร์ด
สคีมาแบบดาวเป็นการออกแบบสำหรับ OLAP จุดประสงค์ทั้งหมดคือการทำให้คำสั่งวิเคราะห์ทำงานได้รวดเร็ว โดยยอมรับความซ้ำซ้อนเพื่อแลกกับความเร็ว
ข้อเท็จจริงและมิติ
สคีมาแบบดาวแบ่งข้อมูลออกเป็นตารางสองประเภท:
- ตารางข้อเท็จจริง: เหตุการณ์หรือธุรกรรมที่วัดค่าได้ (การขาย การคลิก) เก็บ ค่าตัวชี้วัด ที่เป็นตัวเลขและคีย์ต่างประเทศที่เชื่อมไปยังมิติ
- ตารางมิติ: บริบทเชิงพรรณนาที่ใช้แบ่งข้อมูลเพื่อวิเคราะห์ (วันที่ สินค้า ลูกค้า ร้านค้า)
ตารางข้อเท็จจริงอยู่ตรงกลาง ส่วนมิติจะล้อมรอบเหมือนจุดของดาว จึงเป็นที่มาของชื่อ
โครงสร้างของตารางข้อเท็จจริง
ตารางข้อเท็จจริงส่วนใหญ่ประกอบด้วย คีย์ต่างประเทศและค่าตัวชี้วัดที่เป็นตัวเลข ตารางนี้มีลักษณะยาวและแคบ และเติบโตอย่างต่อเนื่อง
ค่าตัวชี้วัดคือตัวเลขที่นำไปรวมยอดได้ เช่น จำนวน รายได้ ต้นทุน ต้องระบุระดับรายละเอียด (หนึ่งแถว = หนึ่ง ?) ให้ชัดเจน ในที่นี้หนึ่งแถวหมายถึงสินค้าหนึ่งรายการในรายการขายหนึ่งรายการ
CREATE TABLE fact_sales (
sale_id BIGINT PRIMARY KEY,
date_key INT NOT NULL, -- FK to dim_date
product_key INT NOT NULL, -- FK to dim_product
customer_key INT NOT NULL, -- FK to dim_customer
store_key INT NOT NULL, -- FK to dim_store
quantity INT, -- measure
revenue DECIMAL(12,2), -- measure
cost DECIMAL(12,2) -- measure
);โครงสร้างของตารางมิติ
ตารางมิติมีจำนวนแถวน้อยแต่ กว้าง: มีคอลัมน์เชิงพรรณนาจำนวนมากที่ใช้กรองและจัดกลุ่มข้อมูล ตารางเหล่านี้ถูกทำให้ไม่เป็นมาตรฐานโดยเจตนา เพื่อให้คำสั่งสืบค้นต้องใช้ Join เพียงครั้งเดียวต่อหนึ่งมิติ
สังเกตว่า dim_product เก็บหมวดหมู่และแบรนด์ไว้ในแถวเดียวกัน แทนที่จะแยกเป็นตารางคนละตาราง ความซ้ำซ้อนนี้เป็นจุดประสงค์หลัก เพราะช่วยหลีกเลี่ยง Join เพิ่มเติมขณะสืบค้น
CREATE TABLE dim_product (
product_key INT PRIMARY KEY, -- surrogate key
product_id INT, -- natural/business key
product_name VARCHAR(100),
category VARCHAR(50), -- denormalized
brand VARCHAR(50), -- denormalized
unit_price DECIMAL(10,2)
);คำสั่งสืบค้นในสคีมาแบบดาว
นี่คือประโยชน์ที่ได้จากการออกแบบดังกล่าว คำสั่งสืบค้นเชิงวิเคราะห์ทั่วไปจะเชื่อมตารางข้อเท็จจริงกับมิติบางส่วน กรองข้อมูล แล้วรวมยอด ใช้ Join เพียงครั้งเดียวต่อหนึ่งมิติ และไม่มีการเชื่อมต่อเป็นทอดลึก
ผู้สัมภาษณ์มักขอให้คุณเขียนคำสั่งสืบค้นลักษณะนี้กับสคีมาแบบดาวโดยตรง
SELECT d.category,
t.year,
SUM(f.revenue) AS total_revenue
FROM fact_sales f
JOIN dim_product d ON d.product_key = f.product_key
JOIN dim_date t ON t.date_key = f.date_key
WHERE t.year = 2025
GROUP BY d.category, t.year
ORDER BY total_revenue DESC;คีย์ตัวแทน
มิติใช้ คีย์ตัวแทน: คีย์หลักจำนวนเต็มที่ไม่มีความหมายทางธุรกิจ (เช่น product_key) ซึ่งสร้างโดยคลังข้อมูลและแยกจากคีย์ธรรมชาติของระบบต้นทาง
เหตุผลที่ผู้สัมภาษณ์ให้ความสำคัญ:
- ช่วยแยกคลังข้อมูลออกจากคีย์ทางธุรกิจที่อาจเปลี่ยนแปลง
- ทำให้ตารางข้อเท็จจริงมีขนาดแคบลง (การเชื่อมด้วยจำนวนเต็มทำได้รวดเร็ว)
- จำเป็นสำหรับการติดตามประวัติด้วยมิติที่เปลี่ยนแปลงอย่างช้า ๆ (ฉากถัดไป)
มิติที่เปลี่ยนแปลงอย่างช้า ๆ
หัวข้อยอดนิยมในการสัมภาษณ์เกี่ยวกับคลังข้อมูลคือ เมื่อแอตทริบิวต์ของมิติเปลี่ยนแปลง (เช่น ลูกค้าย้ายเมือง) คุณจะจัดการอย่างไร สิ่งเหล่านี้เรียกว่า มิติที่เปลี่ยนแปลงอย่างช้า ๆ (SCD):
- ประเภทที่ 1: เขียนทับค่าเดิม ไม่มีประวัติ
- ประเภทที่ 2: เพิ่มแถวใหม่พร้อมวันที่เริ่มมีผลและแฟล็กแสดงรายการปัจจุบัน มีประวัติครบถ้วน และต้องใช้คีย์ตัวแทน
- ประเภทที่ 3: เก็บคอลัมน์ “ค่าเดิม” ไว้ มีประวัติจำกัด
ประเภทที่ 2 คือคำตอบที่คาดหวังบ่อยที่สุดสำหรับการติดตามการเปลี่ยนแปลงตามเวลา
-- SCD Type 2 dimension
CREATE TABLE dim_customer (
customer_key INT PRIMARY KEY, -- surrogate
customer_id INT, -- natural key
city VARCHAR(50),
valid_from DATE,
valid_to DATE,
is_current BOOLEAN
);สคีมาแบบดาวเทียบกับสคีมาแบบเกล็ดหิมะ
เตรียมพบคำถามเปรียบเทียบไว้ได้เลย สคีมาแบบเกล็ดหิมะ จะทำให้มิติเป็นรูปแบบมาตรฐานโดยแยกเป็นตารางย่อย (สินค้า -> หมวดหมู่ -> แผนก) ขณะที่สคีมาแบบดาวเก็บข้อมูลไว้ในระดับเดียวกัน
- ดาว: ใช้ Join น้อยกว่า อ่านได้เร็วกว่า มีความซ้ำซ้อนอยู่บ้าง เหมาะสำหรับประสิทธิภาพในการสืบค้น
- เกล็ดหิมะ: ใช้พื้นที่จัดเก็บน้อยกว่าและดูแลมิติได้ง่ายกว่า แต่แต่ละคำสั่งสืบค้นต้องใช้ Join มากกว่า
ให้ตอบว่า: “โดยค่าเริ่มต้นให้ใช้สคีมาแบบดาวเพื่อความเร็วในการสืบค้น และใช้สคีมาแบบเกล็ดหิมะเฉพาะเมื่อมิติมีขนาดใหญ่และถูกใช้ซ้ำ”
มิติวันที่
สคีมาแบบดาวแทบทุกแบบมี มิติวันที่ โดยเฉพาะ แทนการใช้คอลัมน์วันที่ดิบ มิตินี้คำนวณปี ไตรมาส เดือน วันในสัปดาห์ แฟล็กวันหยุด และช่วงเวลาตามปีบัญชีไว้ล่วงหน้า
ทำให้นักวิเคราะห์จัดกลุ่มตาม “ไตรมาสบัญชี” หรือ “เป็นวันสุดสัปดาห์หรือไม่” ได้ด้วย Join อย่างง่าย แทนการกระจายฟังก์ชันวันที่ไปทั่วคำสั่ง การพูดถึงมิติวันที่โดยไม่ต้องมีผู้ถามถือเป็นสัญญาณที่ดีว่าคุณเคยสร้างคลังข้อมูลมาแล้ว
CREATE TABLE dim_date (
date_key INT PRIMARY KEY, -- e.g. 20250131
full_date DATE,
year INT,
quarter INT,
month INT,
day_of_week VARCHAR(10),
is_weekend BOOLEAN,
fiscal_qtr VARCHAR(6)
);การเลือกระดับรายละเอียด
การตัดสินใจที่สำคัญที่สุดเพียงข้อเดียวของตารางข้อเท็จจริงคือ ระดับรายละเอียด: หนึ่งแถวแทนอะไร ต้องประกาศให้ชัดเจนก่อนทำสิ่งอื่น
- หยาบเกินไป (หนึ่งแถวต่อวันต่อร้านค้า) จะทำให้สูญเสียรายละเอียด
- ละเอียดเกินไป (หนึ่งแถวต่อสินค้าที่สแกนหนึ่งชิ้น) จะทำให้ตารางขยายตัวมหาศาล
คำประกาศระดับรายละเอียดที่ชัดเจน เช่น “หนึ่งแถวต่อสินค้าหนึ่งรายการในแต่ละรายการสั่งซื้อ” จะเป็นตัวกำหนดว่าควรมีมิติและค่าตัวชี้วัดใดบ้าง ผู้สัมภาษณ์จะสังเกตว่าคุณมีวินัยในเรื่องนี้
เมื่อใดควรทำให้ข้อมูลไม่เป็นมาตรฐาน
เชื่อมโยงกลับไปยังเรื่องการทำให้เป็นรูปแบบมาตรฐาน ระบบ OLTP ทำให้ข้อมูลเป็นรูปแบบมาตรฐานระดับ 3NF เพื่อความถูกต้อง ส่วนคลังข้อมูลจะ ทำให้มิติไม่เป็นมาตรฐานโดยเจตนา เพื่อความรวดเร็วในการอ่าน
สิ่งที่คุณต้องอธิบายให้ได้คือข้อแลกเปลี่ยนดังนี้:
- ข้อมูลมิติที่ซ้ำซ้อนเป็นสิ่งที่ยอมรับได้ เพราะคลังข้อมูลโหลดข้อมูลผ่าน ETL ที่ควบคุมไว้ ไม่ใช่การเขียนจากแอปแบบเฉพาะกิจ
- การใช้ Join น้อยลงทำให้การรวมยอดจากแถวข้อเท็จจริงหลายพันล้านแถวเร็วขึ้น
สิ่งที่ทำให้คำตอบระดับอาวุโสแตกต่างคือการใช้วิจารณญาณ ไม่ใช่การยึดตามกฎเพียงอย่างเดียว
ตรวจสอบอย่างรวดเร็ว
คุณกำลังออกแบบคลังข้อมูลการขาย และจำเป็นต้องเก็บประวัติเมืองของลูกค้าไว้อย่างครบถ้วนเมื่อลูกค้าย้ายเมือง
สรุปทบทวน: สคีมาแบบดาวและการออกแบบคลังข้อมูล
ตอนนี้คุณสามารถตอบคำถามเกี่ยวกับการสร้างแบบจำลองคลังข้อมูลได้แล้ว:
- OLTP ทำให้ข้อมูลเป็นรูปแบบมาตรฐานเพื่อความถูกต้อง ส่วน OLAP ทำให้ข้อมูลไม่เป็นมาตรฐานเพื่อความรวดเร็วในการอ่าน
- สคีมาแบบดาวมี ตารางข้อเท็จจริง อยู่ตรงกลาง (คีย์ต่างประเทศและค่าตัวชี้วัดที่เป็นตัวเลข) ล้อมรอบด้วย มิติ ที่อยู่ในระดับเดียวกัน
- ใช้ คีย์ตัวแทน และ มิติวันที่ โดยเฉพาะ
- ติดตามการเปลี่ยนแปลงด้วย SCD ประเภทที่ 2 และประกาศ ระดับรายละเอียด ของตารางข้อเท็จจริงก่อน
- เลือกใช้ สคีมาแบบดาวแทนสคีมาแบบเกล็ดหิมะ เพื่อประสิทธิภาพในการสืบค้น
คำถามที่พบบ่อย
บทเรียน “สคีมาแบบดาวและการออกแบบคลังข้อมูล” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “สคีมาแบบดาวและการออกแบบคลังข้อมูล” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส SQL Interview Prep ให้อัปเกรดเป็น CoddyKit PRO คอร์ส SQL Interview Prep มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “สคีมาแบบดาวและการออกแบบคลังข้อมูล”
ตารางข้อเท็จจริงและตารางมิติ ข้อแลกเปลี่ยนของการลดรูปแบบบรรทัดฐาน และการสร้างแบบจำลอง OLAP คุณปฏิบัติ SQL Interview Prep ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน SQL Interview Prep หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน SQL Interview Prep บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 3 จากทั้งหมด 4 บทเรียน
บทเรียน “สคีมาแบบดาวและการออกแบบคลังข้อมูล” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน SQL Interview Prep นี้ได้ไหม
ได้ บทเรียน SQL Interview Prep ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การทำให้เป็นบรรทัดฐานจนถึง 3NF
- การสร้างแบบจำลอง ER และคาร์ดินาลิตีของความสัมพันธ์
- สคีมาแบบดาวและการออกแบบคลังข้อมูล
- ชุดโจทย์สัมภาษณ์จำลองฉบับเต็ม