Star Schema ในการสร้างแบบจำลอง Data Warehouse คืออะไร
ทีมบรรณาธิการ
⚡ สรุปอย่างชาญฉลาด
ในการสร้างแบบจำลองคลังข้อมูล รูปแบบ Star Schema จะวางตารางข้อเท็จจริงส่วนกลางไว้ที่แกนกลางของตารางมิติโดยรอบ ทำให้เกิดการออกแบบรูปทรงดาวที่ลดความซ้ำซ้อนของข้อมูล ซึ่งช่วยลดความซับซ้อนของการสืบค้นข้อมูลเชิงวิเคราะห์ เพิ่มความเร็วในการรายงาน และขับเคลื่อนคิวบ์ OLAP ในแพลตฟอร์มระบบธุรกิจอัจฉริยะต่างๆ
สตาร์สคีมาคืออะไร?
A สคีมาดาว ในคลังข้อมูล โครงสร้างการสร้างแบบจำลองอย่างหนึ่งคือ ตารางข้อเท็จจริงส่วนกลางหนึ่งตารางเชื่อมต่อกับตารางมิติที่เกี่ยวข้องหลายตาราง โครงสร้างนี้เรียกว่า สคีมาดาว (Star Schema) เพราะเค้าโครงมีลักษณะคล้ายดาว โดยมีตารางข้อเท็จจริงอยู่ตรงกลางและตารางมิติแผ่กระจายออกไปเหมือนจุด
โครงสร้างแบบสตาร์สคีมา (Star Schema) เป็นโครงสร้างคลังข้อมูลที่ง่ายที่สุด และเรียกอีกอย่างว่าโครงสร้างแบบสตาร์จอยน์สคีมา (Star Join Schema) เนื่องจากตารางมิติ (Dimension Tables) ไม่ได้ถูกทำให้เป็นรูปแบบปกติ (Denormalized) ทำให้โมเดลนี้เหมาะสมกับการสืบค้นชุดข้อมูลขนาดใหญ่มาก ซึ่งทำให้เป็นตัวเลือกที่นิยมใช้กันทั่วไป การสร้างแบบจำลองเชิงมิติ และการรายงาน
โครงสร้างข้อมูลแบบหลายมิติคืออะไร?
A แผนผังหลายมิติ ออกแบบมาโดยเฉพาะเพื่อสร้างแบบจำลองระบบคลังข้อมูล โครงสร้างข้อมูลเหล่านี้ตอบสนองความต้องการเฉพาะของฐานข้อมูลขนาดใหญ่มากที่สร้างขึ้นเพื่อวัตถุประสงค์ในการวิเคราะห์ สพป แทนที่จะใช้สำหรับการประมวลผลธุรกรรมทั่วไป
ประเภทของสคีมาคลังข้อมูล: มีรูปแบบโครงสร้างหลายมิติหลักๆ อยู่ 3 ประเภท และแต่ละประเภทก็มีข้อดีแตกต่างกันไป
- สตาร์สคีมา – ตารางข้อเท็จจริงส่วนกลางที่เชื่อมต่อโดยตรงกับตารางมิติที่ไม่เป็นรูปแบบปกติ (denormalized dimension tables)
- โครงร่างเกล็ดหิมะ – ส่วนขยายของสคีมาแบบดาว (star schema) โดยที่มิติข้อมูลจะถูกแปลงเป็นตารางมิติย่อยเพิ่มเติม
- แผนผังกาแล็กซี – หรือเรียกอีกอย่างว่ากลุ่มข้อเท็จจริง (fact constellation) ซึ่งใช้ตารางข้อเท็จจริงหลายตารางที่ใช้ตารางมิติร่วมกัน
เนื่องจากสคีมาแบบเกล็ดหิมะสร้างขึ้นโดยตรงจากสคีมาแบบดาว การเปรียบเทียบโมเดลทั้งสองก่อนที่จะลงมือศึกษาตัวอย่างสคีมาแบบดาวอย่างละเอียดจึงเป็นประโยชน์
Star Schema เทียบกับ Snowflake Schema
แผนผังดาวและ สคีมาเกล็ดหิมะ ทั้งสองแบบจัดระเบียบข้อมูลโดยใช้ตารางข้อเท็จจริงและตารางมิติ แต่แตกต่างกันในวิธีการจัดเก็บมิติ แบบแผนสตาร์ (Star Schema) เก็บแต่ละมิติไว้ในตารางที่ไม่เป็นมาตรฐานเพียงตารางเดียว ในขณะที่แบบแผนสโนว์เฟลก (Snowflake Schema) ทำให้มิติเหล่านั้นเป็นมาตรฐานและจัดเก็บไว้ในตารางที่เกี่ยวข้องกันหลายตาราง
- โครงสร้าง: โครงสร้างข้อมูลแบบดาว (Star Schema) นั้นเรียบง่ายและไม่ซับซ้อน ในขณะที่โครงสร้างข้อมูลแบบเกล็ดหิมะ (Snowflake Schema) จะแตกแขนงมิติออกเป็นมิติย่อยๆ
- ความเร็วในการค้นหาข้อมูล: โครงสร้างข้อมูลแบบดาว (Star schema) ต้องการการเชื่อมต่อ (joins) น้อยกว่า ดังนั้นโดยทั่วไปแล้วการค้นหาข้อมูลจึงทำงานได้เร็วขึ้น และโค้ด SQL ก็ยังคงเรียบง่ายกว่า
- การจัดเก็บ: โครงสร้างข้อมูลแบบ Snowflake ช่วยลดความซ้ำซ้อน จึงใช้พื้นที่น้อยลง แต่ทำให้การออกแบบซับซ้อนขึ้น
- ความสมบูรณ์ของข้อมูล: ขนาดของเกล็ดหิมะที่เป็นมาตรฐานช่วยรักษาความสมบูรณ์ได้ดีกว่า ในขณะที่ขนาดของดาวที่ไม่เป็นมาตรฐานจะส่งเสริมประสิทธิภาพ
- ความง่ายดายในการใช้งาน: โครงสร้างข้อมูลแบบดาว (Star Schema) เข้าใจง่ายกว่าและบำรุงรักษาได้รวดเร็วกว่าสำหรับนักวิเคราะห์ ในขณะที่โครงสร้างข้อมูลแบบเกล็ดหิมะ (Snowflake Schema) ต้องการการออกแบบที่รอบคอบกว่า
ในทางปฏิบัติ ทีมงานมักเลือกใช้สคีมาแบบดาว (star schema) สำหรับดาต้ามาทและแดชบอร์ดที่ต้องการการรายงานที่รวดเร็วและตรงไปตรงมา และเลือกใช้สคีมาแบบเกล็ดหิมะ (snowflake schema) เมื่อต้องการประหยัดพื้นที่จัดเก็บข้อมูลและรักษาความสอดคล้องอย่างเคร่งครัดมากกว่า
ตัวอย่างของ Star Schema
ในตัวอย่างโครงสร้างข้อมูลแบบสตาร์สคีมาต่อไปนี้ ตารางข้อเท็จจริงจะอยู่ตรงกลางและเก็บคีย์สำหรับตารางมิติทุกตาราง เช่น Dealer_ID, Model_ID, Date_ID, Product_ID และ Branch_ID พร้อมด้วยคุณลักษณะที่วัดได้ เช่น จำนวนหน่วยที่ขายและรายได้
ตารางมิติโดยรอบแต่ละตารางจะเพิ่มบริบทเชิงพรรณนาให้กับตัวชี้วัดเหล่านั้น ดังนั้นการสืบค้นเพียงครั้งเดียวจึงสามารถจัดกลุ่มหรือกรองข้อมูลการขายตามตัวแทนจำหน่าย รุ่น วันที่ ผลิตภัณฑ์ หรือสาขาได้โดยไม่ต้องเชื่อมตารางอื่นใด
ตารางข้อเท็จจริง
ตารางข้อเท็จจริงในสคีมาแบบสตาร์ประกอบด้วยข้อเท็จจริงและเชื่อมโยงกับมิติข้อมูล ตารางข้อเท็จจริงมีคอลัมน์สองประเภท:
- คอลัมน์ที่ใช้เก็บข้อมูลหรือค่าต่างๆ
- คีย์ต่างประเทศที่เชื่อมโยงไปยังตารางมิติแต่ละตาราง
โดยทั่วไป คีย์หลักของตารางข้อเท็จจริงจะเป็นคีย์ผสมที่สร้างขึ้นจากคีย์ต่างประเทศทั้งหมดที่ประกอบกันเป็นตารางนั้น
ตารางข้อเท็จจริงสามารถประกอบด้วยข้อเท็จจริงระดับรายละเอียดหรือข้อเท็จจริงที่รวบรวมไว้แล้ว ตารางข้อเท็จจริงที่รวมข้อเท็จจริงที่รวบรวมไว้มักเรียกว่าตารางสรุป และโดยทั่วไปจะประกอบด้วยข้อเท็จจริงที่ได้รับการรวบรวมไว้ในระดับใดระดับหนึ่งแล้ว
ตารางมิติ
มิติข้อมูลคือโครงสร้างที่จัดหมวดหมู่ข้อมูลเป็นลำดับชั้น มิติข้อมูลที่ไม่มีลำดับชั้นและระดับเรียกว่ามิติข้อมูลแบบแบนหรือแบบรายการ คีย์หลักของแต่ละตารางมิติข้อมูลเป็นส่วนหนึ่งของคีย์หลักแบบผสมของตารางข้อเท็จจริง
คุณลักษณะมิติ (Dimension attribute) คือคุณลักษณะเชิงข้อความที่ช่วยอธิบายค่าเชิงมิติ เช่น ชื่อผลิตภัณฑ์หรือเมือง เนื่องจากตารางมิติจัดเก็บบริบทเชิงพรรณนาเหล่านี้แทนที่จะเป็นเหตุการณ์ธุรกรรม ตารางข้อเท็จจริงจึงมักมีขนาดใหญ่กว่าตารางมิติมาก
วิธีออกแบบ Star Schema
การออกแบบสคีมาแบบดาว (Star Schema) เป็นไปตามแนวทางการสร้างแบบจำลองเชิงมิติ (Dimensional Modeling) ที่ได้รับความนิยมจาก Ralph Kimball เป้าหมายคือการจัดระเบียบตัวชี้วัดทางธุรกิจโดยใช้มิติที่ชัดเจนและนำกลับมาใช้ใหม่ได้ เพื่อให้แบบจำลองที่เสร็จสมบูรณ์นั้นง่ายต่อการสืบค้นและสร้างรายงานได้อย่างรวดเร็ว ห้าขั้นตอนด้านล่างนี้แสดงภาพรวมของกระบวนการที่โครงการสร้างแบบจำลองเชิงมิติส่วนใหญ่ปฏิบัติตาม โดยเริ่มจากคำถามทางธุรกิจระดับสูงสุด ไปจนถึงตารางข้อเท็จจริงและตารางมิติที่แท้จริง
- ระบุขั้นตอนทางธุรกิจ: เลือกกิจกรรมที่คุณต้องการวิเคราะห์ เช่น การขาย การจัดส่งpingหรือสินค้าคงคลัง การตัดสินใจนี้จะกำหนดว่าตารางข้อเท็จจริงจะวัดอะไรบ้าง
- ระบุชนิดของเมล็ดพืช: กำหนดระดับรายละเอียดที่แต่ละแถวข้อมูลแสดง เช่น หนึ่งแถวต่อรายการสินค้า หนึ่งแถวต่อธุรกรรม หรือหนึ่งแถวต่อวัน การกำหนดระดับรายละเอียดที่ชัดเจนจะช่วยให้แบบจำลองมีความสอดคล้องกัน
- ระบุขนาด: ระบุบริบทเชิงพรรณนาที่จำเป็นในการแบ่งย่อยข้อเท็จจริง เช่น ผลิตภัณฑ์ ลูกค้า ตัวแทนจำหน่าย สาขา และวันที่ โดยแต่ละส่วนจะกลายเป็นตารางมิติของคุณลักษณะ
- ระบุข้อเท็จจริง: กำหนดตัวชี้วัดเชิงตัวเลขที่ธุรกิจต้องการ track เช่น จำนวนหน่วยที่ขายได้ รายได้ หรือต้นทุน และนำไปใส่ไว้ในตารางข้อมูลหลัก
- สร้างดาวดวงนั้น: เชื่อมโยงตารางข้อเท็จจริงเข้ากับแต่ละมิติผ่านคีย์ต่างประเทศping มิติข้อมูลถูกทำให้ไม่เป็นมาตรฐาน ดังนั้นแผนภาพจึงก่อให้เกิดตารางข้อเท็จจริงส่วนกลางเพียงตารางเดียวที่ล้อมรอบด้วยมิติข้อมูล
หลังจากสร้างโครงสร้างข้อมูลแบบดาวแล้ว ให้เพิ่มคีย์ตัวแทน (surrogate key) ให้กับทุกมิติข้อมูล ตรวจสอบให้แน่ใจว่าตารางข้อเท็จจริงแต่ละตารางมีมิติข้อมูลวันที่ที่เกี่ยวข้อง และยืนยันว่าข้อเท็จจริงทั้งหมดอยู่ในระดับเดียวกัน นอกจากนี้ยังเป็นแนวปฏิบัติที่ดีที่จะโหลดข้อมูลระดับต่ำสุดที่เป็นอะตอมก่อน เนื่องจากตารางสรุปสามารถสร้างขึ้นในภายหลังได้เสมอ การปฏิบัติตามกฎเหล่านี้จะช่วยให้โครงสร้างข้อมูลได้รับการปรับให้เหมาะสมเพื่อประสิทธิภาพสูงและเรียบง่าย คลังข้อมูล รายงาน
ลักษณะของสคีมาดาว
- ในโครงสร้างข้อมูลแบบสตาร์สคีมา แต่ละมิติจะถูกแสดงด้วยตารางมิติเพียงตารางเดียวเท่านั้น
- ตารางมิติแต่ละตารางจะมีชุดคุณลักษณะเฉพาะของตนเอง
- ตารางมิติถูกเชื่อมโยงกับตารางข้อเท็จจริงโดยใช้คีย์ต่างประเทศ
- ตารางมิติเหล่านี้ไม่ได้เชื่อมต่อกัน
- ตารางข้อเท็จจริงประกอบด้วยคำอธิบายสัญลักษณ์และตัวชี้วัด
- รูปแบบการจัดเก็บข้อมูลแบบดาว (Star Schema) เข้าใจง่ายและช่วยให้ใช้พื้นที่ดิสก์ได้อย่างมีประสิทธิภาพสูงสุด
- ตารางมิติไม่ได้ถูกทำให้เป็นรูปแบบมาตรฐาน (normalized) ตัวอย่างเช่น ในตัวอย่างข้างต้น Country_ID ไม่มีตารางค้นหา Country แยกต่างหากเหมือนกับตารางอื่นๆ OLTP การออกแบบจะเป็นเช่นนั้น
- โครงสร้างข้อมูลนี้ได้รับการสนับสนุนอย่างกว้างขวางจากเครื่องมือ BI
ข้อดีของสตาร์สคีมา
โครงสร้างข้อมูลแบบสตาร์สคีมามีข้อดีหลายประการ ทำให้เป็นจุดเริ่มต้นยอดนิยมสำหรับการออกแบบคลังข้อมูล:
- สคีมาแบบดาวใช้ตรรกะการเชื่อมต่อที่ง่ายกว่าสคีมาประเภทอื่นเมื่อดึงข้อมูลจากแหล่งข้อมูลธุรกรรมที่มีการจัดระเบียบข้อมูลอย่างเข้มงวด
- รูปแบบโครงสร้างข้อมูลแบบดาว (Star Schema) ช่วยลดความซับซ้อนของตรรกะการรายงานทางธุรกิจทั่วไป เช่น การรายงานเปรียบเทียบระหว่างช่วงเวลา และการรายงาน ณ วันที่ปัจจุบัน
- โครงสร้างข้อมูลแบบดาว (Star schema) ถูกนำมาใช้กันอย่างแพร่หลายในระบบ OLAP เพื่อสร้างคิวบ์อย่างมีประสิทธิภาพ และโครงสร้างข้อมูลแบบดาวสามารถใช้เป็นแหล่งข้อมูลได้โดยไม่ต้องออกแบบโครงสร้างคิวบ์ในระบบ OLAP หลักๆ ส่วนใหญ่
- ด้วยการเปิดใช้งานการปรับแต่งประสิทธิภาพเฉพาะที่สามารถนำไปใช้กับคำสั่งค้นหาได้ ตัวประมวลผลคำสั่งค้นหาจึงสามารถนำเสนอแผนการดำเนินการที่ดีขึ้นได้
ข้อเสียของ Star Schema
- เนื่องจากโครงสร้างข้อมูลมีการลดการทำซ้ำอย่างมาก ความสมบูรณ์ของข้อมูลจึงไม่ได้รับการบังคับใช้อย่างเข้มงวด
- มันไม่ยืดหยุ่นในแง่ของความต้องการด้านการวิเคราะห์ขั้นสูง
- โครงสร้างข้อมูลแบบดาว (Star schema) ไม่ได้ส่งเสริมความสัมพันธ์แบบหลายต่อหลาย (many-to-many) ระหว่างหน่วยงานทางธุรกิจ
เมื่อใดควรใช้ Star Schema
โครงสร้างข้อมูลแบบสตาร์สคีมา (Star Schema) เป็นตัวเลือกที่เหมาะสมเมื่อประสิทธิภาพการสืบค้นข้อมูลที่รวดเร็วและคาดการณ์ได้มีความสำคัญมากกว่าการประหยัดพื้นที่จัดเก็บข้อมูล เนื่องจากโมเดลนี้รักษาตารางมิติข้อมูลให้อยู่ในรูปแบบที่ไม่เป็นมาตรฐาน (denormalized) และมีจำนวนการเชื่อมต่อ (joins) ต่ำ จึงเหมาะสำหรับงานวิเคราะห์ที่ผู้ใช้ทางธุรกิจเรียกใช้รายงาน แดชบอร์ด และการรวมข้อมูลที่คล้ายกันซ้ำๆ กับข้อมูลในอดีตจำนวนมาก
สถานการณ์ทั่วไปที่โครงสร้างข้อมูลแบบดาว (Star Schema) เหมาะสมอย่างยิ่ง ได้แก่:
- คลังข้อมูล: แผนก ตลาดข้อมูล โครงสร้างที่อ่านง่ายจะได้รับประโยชน์จากความสัมพันธ์ที่เรียบง่ายและเข้าใจได้ง่าย
- แดชบอร์ด BI: ระบบธุรกิจอัจฉริยะ เครื่องมือต่างๆ สามารถแมปเข้ากับสคีมาแบบดาวได้อย่างลงตัว ทำให้สร้างรายงานและภาพกราฟิกได้รวดเร็ว
- คิวบ์ OLAP: โครงสร้างข้อมูลแบบ Star schema เป็นแหล่งข้อมูลที่เหมาะสมสำหรับการสร้าง OLAP cube การรวมข้อมูล และการวิเคราะห์แบบแยกส่วน (slice-and-dice analysis)
หากลำดับความสำคัญเปลี่ยนไปเป็นการจัดเก็บข้อมูลให้น้อยที่สุด ความสมบูรณ์ของข้อมูลที่เข้มงวด หรือลำดับชั้นที่ซับซ้อนและเปลี่ยนแปลงได้ โครงสร้างข้อมูลแบบเกล็ดหิมะ (Snowflake Schema) หรือการออกแบบที่เป็นมาตรฐานมากขึ้นอาจเหมาะสมกว่า ทีมหลายทีมยังผสมผสานทั้งสองแบบเข้าด้วยกัน โดยเริ่มต้นด้วยโครงสร้างข้อมูลแบบดาว (Star Schema) และปรับให้เป็นมาตรฐานเฉพาะมิติข้อมูลที่จำเป็นจริงๆ เท่านั้น
