เมื่อ OLAP ก้าวสู่เอ็นเตอร์ไพรส์แอพพลิเคชัน

ในอดีตเทคโนโลยีของ OLAP อาจจะเหมาะสมเฉพาะกับแอพพลิเคชันขนาดเล็กเท่านั้น แต่ในวันนี้ OLAP กลับมาอีกครั้งกับความพร้อมในเอ็นเตอร์ไพรส์แอพพลิเคชัน

ในอดีตเทคโนโลยีของ OLAP อาจจะเหมาะสมเฉพาะกับแอพพลิเคชันขนาดเล็กเท่านั้น แต่ในวันนี้ OLAP กลับมาอีกครั้งกับความพร้อมในเอ็นเตอร์ไพรส์แอพพลิเคชัน

เป็นที่ทราบกันดีอยู่แล้วว่า ข้อมูลขององค์กรส่วนใหญ่ได้รับการเก็บอยู่ในฐานข้อมูลแบบสัมพันธ์ ซึ่งในอดีตไม่ว่าจะเป็นนักออกแบบฐานข้อมูล โปรแกรมเมอร์ ไปจนถึงผู้บริหารต่างก็เชื่อว่าเทคโนโลยีของ Online Analytic Processing (OLAP) นั้น เหมาะสำหรับแอพพลิเคชันขนาดเล็กเท่านั้น

 แต่ในวันนี้ทั้งตัวฐานข้อมูลที่ได้รับการพัฒนาไปอย่างก้าวกระโดด ประกอบกับผู้ใช้ได้มองเห็นประโยชน์ของแอพพลิเคชัน OLAP เพิ่มมากขึ้น ทำให้เซิร์ฟเวอร์ OLAP ได้กลายมาเป็นส่วนประกอบที่สำคัญของดาต้าแวร์เฮาส์ ที่ช่วยให้องค์กรสามารถวิเคราะห์และนำข้อมูลที่ได้ไปใช้ประกอบการตัดสินใจอย่างมีประสิทธิภาพมากยิ่งขึ้น

ทำไมต้อง OLAP
 OLAP หรือ Online analytical processing เป็นเทคโนโลยีที่ประกอบด้วยเครื่องมือที่ช่วยดึงและนำเสนอข้อมูลในหลายมิติ (Multidimensional) จากหลายๆ มุมมอง โดยที่ OLAP ได้รับการออกแบบมาสำหรับผู้ใช้ในระดับของผู้บริหารหรือหน่วยงานในองค์กร ที่ต้องวิเคราะห์ข้อมูลเพื่อใช้ประกอบการตัดสินใจในระดับสูง สำหรับโครงสร้างของข้อมูล OLAP นั้นเป็นแบบลำดับชั้น (Hierarchical) ช่วยให้ผู้ใช้สามารถเข้าใจภาพรวมและความเกี่ยวข้องของข้อมูลในองค์กรได้ง่าย ส่วนฟังก์ชัน OLAP นั้นก็สนับสนุนการวิเคราะห์แนวโน้ม (Trend Analysis) การเจาะลึกข้อมูลในระดับรายละเอียดที่มีความซับซ้อน ความสามารถในการสรุปข้อมูล และความสามารถในการเปรียบเทียบข้อมูลในมุมมองต่างๆ อีกด้วย

OLAP นับเป็นเทคโนโลยีที่มีความสำคัญต่อธุรกิจในปัจจุบันเป็นอย่างมาก เนื่องจากความซับซ้อนที่มากขึ้น และเวลาที่น้อยลงสำหรับการตัดสินใจทางธุรกิจ OLAP จึงเป็นคำตอบที่เหมาะสมมากที่สุดในปัจจุบัน เพราะจุดเด่นที่สำคัญของ OLAP ประกอบด้วย การตอบสนองต่อการคิวรีของผู้ใช้ที่กินเวลาไม่มาก การทำงานที่ไม่ขึ้นกับขนาดและความซับซ้อนของฐานข้อมูล แอพพลิเคชัน OLAP ช่วยงานการวิเคราะห์ข้อมูล ไม่ว่าจะเป็นการเปรียบเทียบ การนำเสนอในมุมมองเฉพาะ รวมถึงการวิเคราะห์ข้อมูลย้อนหลังและคาดการณ์ข้อมูลในอนาคตตามโมเดลการตอบคำถามแบบ "What-If"

OLAP เดสก์ทอป vs เซิร์ฟเวอร์
 แอพพลิเคชันของ OLAP นั้น มีทั้งที่ทำงานบนเดสก์ทอปและบนเซิร์ฟเวอร์ ซึ่งถ้าเป็น OLAP ที่ทำงานบนเดสก์ทอปนั้น ฟังก์ชันการวิเคราะห์ข้อมูลจะเก็บและทำงานอยู่บนคอมพิวเตอร์ไคลเอ็นต์ โดยติดต่อกับฐานข้อมูลที่อยู่บนเซิร์ฟเวอร์โดยการส่งคิวรี SQL และรับผลลัพธ์กลับมา จากนั้นแอพพลิเคชันก็จะวิเคราะห์ เปรียบเทียบและนำเสนอข้อมูลตามรูปแบบที่ผู้ใช้ต้องการ ซึ่งจากการทำงานนี้จะเห็นได้ค่อนข้างชัดเจนว่าแอพพลิเคชัน OLAP ที่ทำงานบนเดสก์ทอปถึงแม้ว่าติดตั้งและใช้งานได้สะดวก แต่ก็มีปัญหากับเรื่องของการขยายขนาด ในทางกลับกันข้าม แอพพลิเคชัน OLAP ที่ทำงานบนฝั่งเซิร์ฟเวอร์ จะมีความสามารถในการเก็บข้อมูลไว้ในตัวเองรวมถึงการเชื่อมต่อกับฐานข้อมูลภายได้ ทำให้มีความสามารถในการขยายขนาดที่ดีกว่า รวมทั้งยังสนับสนุนฟังก์ชันการวิเคราะห์ที่ซับซ้อนมากกว่าแอพพลิเคชันที่ทำงานบนเดสก์ทอปเนื่องด้วย ทั้งนี้ก็มาจากการที่ไม่มีข้อจำกัดของทรัพยากรนั่นเอง

ในตลาดของเซิร์ฟเวอร์ OLAP นั้นมีผลิตภัณฑ์ที่โด่งดังอยู่ 4 ตัวประกอบด้วย Microsoft SQL Server Analysis Services, Hyperion Essbase, Oracle Express และ MicroStrategy นอกจากนี้ก็ยังมีผลิตภัณฑ์จากผู้ขายรายย่อยอีกเป็นจำนวนไม่น้อยให้เลือกใช้งานตามความเหมาะสม

เซิร์ฟเวอร์ OLAP นั้นสนับสนุนการบราวซ์และคิวรีข้อมูลพื้นฐาน มีฟังก์ชันการวิเคราะห์ข้อมูลที่มีความซับซ้อน และมีประสิทธิภาพของการคิวรีที่ยอดเยี่ยมด้วยการใช้คุณสมบัติของ Aggregation ที่ได้มีการคำนวณไว้ก่อนหน้าแล้ว (Pre-Computed Aggregation) เนื่องด้วยฟังก์ชันในการวิเคราะห์ของ OLAP ทำงานอยู่บนเซิร์ฟเวอร์ ดังนั้นการติดต่อระหว่างผู้ใช้กับเซิร์ฟเวอร์จึงจำเป็นต้องมีภาษาในการคิวรีอื่นที่เหมาะสมมากกว่า SQL (ที่สนับสนุนเฉพาะการดึงและค้นหาข้อมูลบนพื้นฐานของเซ็ตเท่านั้น) ภาษาที่ใช้ใน OLAP ก็ได้แก่ MDX หรือ Calc Scripts โดยภาษาในการคิวรีของ OLAP ได้รับการออกแบบให้มีประสิทธิภาพในการทำงานด้วยการเก็บคำนิยามของการคำนวณที่ซับซ้อนต่างๆ ไว้ที่เซิร์ฟเวอร์ ทำให้ฟังก์ชันในการคำนวณทั้งที่เป็นพื้นฐาน และที่ซับซ้อนสามารถให้บริการกับผู้ใช้ที่ต้องการได้อย่างกว้างขวาง

นอกจากนี้ด้วยการปรับปรุงอย่างต่อเนื่องทำให้บรรดาผู้พัฒนาแอพพลิเคชันของ OLAP ได้เริ่มปรับเปลี่ยนการใช้แหล่งข้อมูลของตนเอง ซึ่งในอดีตเป็นการเก็บข้อมูลในไฟล์หรือในฐานข้อมูลเฉพาะมาเป็นฐานข้อมูลแบบสัมพันธ์ซึ่งเป็นมาตรฐานและมีผลิตภัณฑ์รองรับที่เปิดกว้างมากกว่าแทน นับเป็นปัจจัยสำคัญที่ทำให้ผลิตภัณฑ์ OLAP กำลังกลายเป็นสิ่งที่มีความสำคัญในการตัดสินใจเลือกโซลูชันขององค์กร

แต่ถ้าเทคโนโลยีของ OLAP มีความสามารถในการวิเคราะห์ข้อมูลที่ซับซ้อนและมีประสิทธิภาพในการคิวรีที่ยอดเยี่ยมแล้ว ทำไมตลาดของแอพพลิเคชันชนิดนี้ยังเล็กอยู่เมื่อเทียบกับเซิร์ฟเวอร์ฐานข้อมูล สาเหตุก็มีหลายประการด้วยกัน ได้แก่ การทำตลาด ความสามารถในการขยายขนาด และความยืดหยุ่น สำหรับในส่วนของการทำตลาด เป็นปัญหาเนื่องจากผู้ใช้ยังไม่ยอมรับผลิตภัณฑ์ที่มีอยู่ ซึ่งก็เกิดขึ้นทั้งจากความไม่คุ้นเคยของตัวผู้ใช้เองไปจนถึงผลิตภัณฑ์ที่ทำความเข้าใจ ติดตั้งและใช้งานได้ยาก จนถึงขณะนี้เซิร์ฟเวอร์ OLAP ยังคงไม่มีข้อตกลงในเรื่องของ API เพื่อให้ไคลเอ็นต์เข้าใช้เลย

อย่างไรดี ปัญหานี้กำลังได้รับการแก้ไขด้วยการเกิดขึ้นของเทคโนโลยีอย่าง XML ซึ่งกำลังได้รับการยอมรับจากบรรดาผู้ขายเซิร์ฟเวอร์ OLAP นั่นก็เป็นสัญญาณที่บ่งชี้ให้เห็นว่าในอนาคตอันใกล้นี้มาตรฐานการเข้าใช้ OLAP จากไคลเอ็นต์คงจะได้รับการโมเดลให้อยู่ในรูปของเอกสาร XML อย่างแน่นอน

ในส่วนความสามารถในการขยายขนาดนั้น ในอดีตที่ผ่านมา ระบบ OLAP นั้นยังทำได้ไม่ดีเท่ากับระบบฐานข้อมูลแบบสัมพันธ์ ถึงแม้ว่าในวันนี้ปัญหาในเรื่องของความสามารถในการขยายขนาดจะยังคงมีอยู่ในผลิตภัณฑ์ OLAP ส่วนใหญ่ แต่บรรดาผู้ที่เกี่ยวข้องก็เริ่มที่จะแก้ปัญหานี้บ้างแล้ว ดังจะเห็นได้จาก Case Study และเอกสารเกี่ยวกับการใช้ OLAP ที่ทำงานกับข้อมูลระดับเทอระไบต์จากผู้ผลิตหลายๆ รายที่มีอยู่ในปัจจุบัน (โดยเฉพาะอย่างยิ่ง MicroStrategy และ Microsoft)

ในส่วนของความยืดหยุ่นนั้น ถึงแม้ว่า OLAP จะยังมีความยืดหยุ่นไม่เท่ากับฐานข้อมูลแบบสัมพันธ์ แต่ก็นับได้ว่าในปัจจุบันเซิร์ฟเวอร์ OLAP ได้รับการพัฒนาให้รองรับกับความต้องการของผู้ใช้ โปรแกรมเมอร์และฝ่ายบริหารได้อย่างหลากหลายมากยิ่งขึ้น ดังที่เราจะได้กล่าวถึงในรายละเอียดต่อไป

ด้านของราคา ถึงแม้ว่าจะเป็นผลิตภัณฑ์ที่ดูว่าจำเป็นต้องใช้เทคโนโลยีชั้นสูง ก็น่าจะส่งผลให้ราคาของผลิตภัณฑ์แพงขึ้นตามไปด้วย แต่ความจริงก็คือ เซิร์ฟเวอร์ OLAP ที่มีอยู่ส่วนใหญ่ยังคงเป็นเพียงฟังก์ชันที่เพิ่มเติมขึ้นมาจากเซิร์ฟเวอร์ฐานข้อมูลแบบสัมพันธ์อยู่แล้ว ทำให้ค่าใช้จ่ายที่เกิดขึ้นเป็นเพียงการจ่ายเงินเพิ่มจากการซื้อเซิร์ฟเวอร์ฐานข้อมูล ซึ่งก็มีจำนวนไม่สูงมากอย่างที่คิด
แนวคิดของ Dimensional ที่เหมือนกัน

olap star schema

 สำหรับผู้ออกแบบและโมเดลข้อมูลแบบ Dimensional ที่มีประสบการณ์ สามารถทำงานได้สะดวกมากขึ้น เนื่องจากเอกสารเกี่ยวกับผลิตภัณฑ์เซิร์ฟเวอร์ OLAP ส่วนใหญ่มักจะมีการพูดถึงแนวคิดและใช้คำศัพท์ที่คุ้นเคยไม่ว่าจะเป็น Dimensional, Hierarchies และ Facts หรือ Measures ซึ่งผลิตภัณฑ์เกือบทั้งหมดใช้แนวคิดของ Cube ซึ่งสามารถเปรียบเทียบได้โดยตรงกับ Table Schema ในฐานข้อมูลแบบสัมพันธ์ ซึ่งมีความสัมพันธ์กับ Dimension และ Aggregate Tables

Dimension ของ OLAP นั้นประกอบด้วย Hierarchies หรือ Summarization Paths โดยความสัมพันธ์ระหว่าง Data Hierarchy กับ OLAP Dimension นั้นเป็นสิ่งที่มีความสำคัญมาก มีผลิตภัณฑ์ OLAP จำนวนไม่น้อยที่สามารถให้ผู้ใช้กำหนด Hierarchies หลายๆ ตัวได้บน Dimension ตัวอย่างเช่น ข้อมูลยอดขายประจำปีกับปฏิทินมาตรฐาน ถ้าผู้ใช้สร้างแอพพลิเคชัน OLAP ขึ้นมาจากดาต้าแวร์เฮาส์ที่สนับสนุน Relational Dimensional ในกรณีนี้แอพพลิเคชันที่สร้างขึ้นก็สามารถใช้ Surrogate Key ซึ่งเป็นคุณสมบัติที่ดีของ OLAP เมื่อเทียบกับฐานข้อมูลแบบสัมพันธ์ได้ด้วย

เช่นเดียวกับฐานข้อมูลแบบสัมพันธ์ เซิร์ฟเวอร์ OLAP นั้นมี Physical และ Calculated Facts อย่างไรก็ตามเอนจิ้นในการวิเคราะห์ของเซิร์ฟเวอร์ OLAP นั้นสนับสนุน Calculated Facts ที่หลากหลายมากกว่า รวมทั้งยังสนับสนุนการกำหนดคีย์ซึ่งเป็นประโยชน์ต่อการสร้างแอพพลิเคชัน OLAP ของผู้ใช้ให้ทำได้ง่ายขึ้นอีกด้วย


แนวคิดของ Dimension ที่ต่างกัน 
 ความแตกต่างที่สำคัญระหว่าง Dimension ของ OLAP กับ Relational Dimension พื้นฐานก็คือ บทบาทกลางของ Hierarchies ของ OLAP ใน Dimension ของ OLAP นั้นเป็นโครงสร้างที่เข้มงวดมากกว่าโครงสร้างของ Hierarchies รวมทั้ง Metadata ของ Cube Definition ก็ประกอบอยู่ในระดับต่างๆ ของ Hierarchical ซึ่งนับได้ว่าเป็นจุดแข็งหนึ่งของ OLAP ส่วนเครื่องมือในการคิวรีของ OLAP ก็มีความสามารถในการดึงข้อมูลเกี่ยวกับโครงสร้างแบบ Hierarchical จากเซิร์ฟเวอร์ OLAP รวมทั้งยังสามารถนำเสนอโครงสร้างเดียวกันนี้ให้กับผู้ใช้ในรูปแบบที่ทำความเข้าใจและใช้งานได้ง่ายอีกด้วย

ที่มีความสำคัญไม่แพ้กันก็คือ เครื่องมือ OLAP นั้นใช้ Hierarchies ในการกำหนด Aggregation เซิร์ฟเวอร์ OLAP จะบังคับความถูกต้องของการอ้างอิงระหว่างระดับใน Hierarchy โดยการใช้ Dimension ในขณะที่ระบบเก็บข้อมูลแบบสัมพันธ์ปกติจะไม่มีการเก็บและบังคับความถูกต้องของ Hierarchies โดยเฉพาะอย่างยิ่งถ้าผู้ใช้ใช้การออกแบบ Dimension แบบ Star แทนที่จะเป็น Snowflake

olap star schema

ความแตกต่างอีกประการระหว่าง OLAP กับฐานข้อมูลแบบสัมพันธ์ก็คือ การสร้าง ชนิดที่ต่างกัน (Different Type) ของ Dimension ที่มีการเปลี่ยนแปลง ใน Dimension ชนิด 2 (Type 2) ซึ่งเกี่ยวข้องกับการติดตามประวัติโดยการเพิ่มสมาชิกของ Dimension เข้ามาใหม่ ได้ง่าย เมื่อเทียบกับที่การสร้างระบบให้มีคุณสมบัติเดียวกันในฐานข้อมูลแบบสัมพันธ์ อย่างไรก็ตามในทางตรงกันข้าม Dimension ชนิด 1 (Type 1) ซึ่งเกี่ยวข้องกับการแก้ไขสถานะของประวัติโดยการอัพเดตนั้น กลับเป็นปัญหาที่ยากสำหรับผู้ใช้ใน OLAP ซึ่งถ้าคุณเคยสร้างและดูแล Aggregate Table บน Relational Schema โดยใช้ Dimension ชนิด 1 แล้ว คุณจะสามารถบอกได้ทันทีว่าปัญที่เกิดขึ้นคืออะไร นั่นคือเมื่อลูกค้าจำเป็นต้องแก้ไข Schema แล้วก็จะส่งผลให้ Aggregate จำเป็นต้องได้รับการแก้ไข นั่นหมายความว่าวิธีเดียวที่คุณทำได้ก็คือจะต้องลบและสร้าง Aggregate Table ขึ้นมาใหม่ทั้งหมด หรือไม่ก็จะต้องมีการแบ่งว่าส่วนใดของ Schema ที่ได้รับผลกระทบจาก Aggregate จากนั้นจึงลงมือแก้ไข ผลิตภัณฑ์เซิร์ฟเวอร์ OLAP กำลังหาทางแก้ไขปัญหานี้อยู่ ซึ่งถึงแม้ว่าขั้นตอนทั้งหมดสามารถทำได้โดยไม่จำเป็นต้องให้ผู้ใช้ทราบ แต่ผลที่ตามมาก็คือการประมวลผลที่มากขึ้นซึ่งหมายถึงเวลา และทรัพยากรของระบบที่จะต้องเสียไปนั่นเอง สำหรับการเปลี่ยนแปลง Dimension ชนิด 1 นั้นนับว่าเป็นงานที่ใช้ทรัพยากรของเซิร์ฟเวอร์ OLAP ค่อนข้างมากทีเดียว
ข้อมูลที่เกี่ยวข้องกับเวลา
 อีกตัวอย่างหนึ่งของงานที่สามารถทำได้ง่ายมากบน Schema ฐานข้อมูลแบบสัมพันธ์แต่นับเป็นงานที่ต้องใช้เทคนิคและประสบการณ์บน OLAP นั่นก็คือ การคิวรีที่ให้ผลลัพธ์เป็นผลรวมของค่าในช่วงเวลาที่ต้องการ สำหรับการคิวรียอดขายทั้งหมดสำหรับผลิตภัณฑ์ Q1 ในปี 2002 แล้ว ก็นับเป็นงานที่ไม่ยากในการสร้างสูตรและเซิร์ฟเวอร์ OLAP ก็สามารถให้คำตอบกับคิวรีนี้ได้เกือบจะทันทีทันใด

 แต่สำหรับปัญหาที่ซับซ้อนขึ้นมา อย่างเช่น ผู้ใช้ต้องการทราบยอดขายสำหรับช่วงระยะเวลาตั้งแต่วันที่ 3 มกราคม ถึงวันที่ 12 มีนาคมของปี 2002 แล้ว ในกรณีนี้ข้อมูลที่เก็บอยู่อาจจะไม่ได้มีการกำหนด Hierarchy รองรับไว้ ส่วนหนึ่งของปัญหานี้กล่าวได้ว่ามาจากเครื่องมือในการคิวรีของไคลเอ็นต์ เครื่องบางตัวไม่สนับสนุนให้ผู้ใช้คิวรีผลลัพธ์ชนิดอื่นยกเว้นแต่ข้อมูลรายวันในแต่ละเดือนได้ ซึ่งถ้าลูกค้ามีความต้องการคุณสมบัติในการคิวรีลักษณะนี้แล้ว คุณก็ควรจะพิจารณาด้วยว่าผลิตภัณฑ์ตัวใดที่สนับสนุน
ข้อดีที่สำคัญ
 ที่ผ่านมาเราได้กล่าวถึงงานที่สามารถทำได้ง่ายกับฐานข้อมูลแบบสัมพันธ์ แต่ถือได้ว่าเป็นเรื่องยากกับเซิร์ฟเวอร์ OLAP บางตัว อย่างไรก็ตาม ยังมีจุดเด่นของ OLAP อีกหลายประการที่เหนือกว่าฐานข้อมูลแบบสัมพันธ์

ประกอบด้วย

•  OLAP มีส่วนติดต่อกับผู้ใช้ที่ง่ายสำหรับการบราวซ์ข้อมูล
•  OLAP มีประสิทธิภาพในการคิวรีข้อมูลที่โดดเด่น ทั้งนี้ขึ้นอยู่กับการจัดโครงสร้างของ Aggregates และ Partition ด้วยว่าทำไว้ดีและเหมาะสมเพียงใด
•  โครงสร้างของ Dimension แบบ Parent-Child นั้นง่ายต่อการสร้างและใช้งาน
•  OLAP มีกฎที่กำหนดไว้บนเซิร์ฟเวอร์สำหรับรองรับ Measure แบบ Semiadditive และ Nonadditive

 เราขอยกตัวอย่างง่ายๆ ก็คือระบบจัดการยอดคงเหลือของคลังสินค้า ยอดคงเหลือของคลังสินค้าสำหรับเดือนมกราคมและกุมภาพันธ์นั้น ไม่ใช่ผลรวมของสินค้าในคลังทั้งหมดในเดือนมกราคมและกุมภาพันธ์ คุณควรแนะนำผู้ใช้ว่าไม่ควรรวมยอดคงเหลือของสินค้าคงคลังตลอดระยะเวลาที่ต้องการ แต่ปัญหาก็คือผู้ใช้จะจำได้หรือไม่ และผู้ใช้ทั้งหมดจะใช้วิธีของ Aggregation เดียวกัน อย่างเช่น การหายอดคงเหลือท้ายสุดหรือเฉลี่ยแทนหรือไม่? อย่างไรก็ตามระบบ OLAP สามารถจัดการปัญหานี้ได้โดยอัตโนมัติ

olap snowflake schema

ระบบ OLAP ให้คุณสามารถใช้การคำนวณที่มีความซับซ้อนสูงที่เซิร์ฟเวอร์ได้ ในขณะที่ภาษา SQL นั้นมีข้อจำกัดเนื่องจากไม่ได้เป็นภาษาที่ออกแบบมาสำหรับการวิเคราะห์ รวมทั้งยังไม่เหมาะสำหรับการสร้างรายงานอีกด้วย ในกรณีนี้คุณต้องการเซิร์ฟเวอร์ซึ่งทำหน้าที่วิเคราะห์ เซิร์ฟเวอร์นี้สนับสนุนการวิเคราะห์ทางสถิติ, อัลกอริทึมของ Data Mining หรือการคำนวณทางธุรกิจตามกฎพื้นฐาน อย่างเช่น การจัดสรรและการวิเคราะห์ทรัพยากรโดยไม่ต้องสนใจว่าข้อมูลและคิวรีเหล่านี้ถูกเก็บและมีวิธีการทำงานเป็นอย่างไร

คิวรีและการคำนวณที่มีการทำงานบนเซิร์ฟเวอร์ประสิทธิภาพสูงสามารถทำงานร่วมกับ Fact Table หรือ Cube หลายๆ ตัวได้พร้อมกัน ด้วยการใช้ข้อมูลจาก Fact Table หลายๆ ตัวนับเป็นงานที่ยากสำหรับฐานข้อมูลแบบสัมพันธ์ (นึกถึงการ Join ระหว่างตาราง ยิ่งมีจำนวนตารางมากเท่าใดก็จะทำให้โปรแกรมมีความซับซ้อนและประสิทธิภาพก็จะตกลงอย่างฉับพลัน) แต่สำหรับงานเดียวกับบนเซิร์ฟเวอร์ OLAP นับเป็นสิ่งที่ทำได้ง่ายและมีประสิทธิภาพสูงอีกด้วย

การคำนวณสามารถกำหนดขึ้นมาเพื่อใช้งานเพียงครั้งเดียวหรือหลายครั้งก็คือ ถึงแม้จะมีจำนวนการคำนวณมากเท่าใด คุณก็สามารถเก็บไว้บนเซิร์ฟเวอร์ซึ่งช่วยให้การจัดการทำได้ง่ายกว่า และมีความยืดหยุ่นต่อผู้ใช้ในการนำมาใช้งานเพื่อประมวลผลข้อมูลที่ดีกว่า ด้วยเครื่องมือที่ใช้งานได้ง่าย ช่วยให้การเข้าใช้การวิเคราะห์ข้อมูลที่ซับซ้อนซึ่งถูกเก็บอยู่บนเซิร์ฟเวอร์ OLAP ไม่ใช่เรื่องยากอีกต่อไป ความสามารถนี้นับว่าเป็นจุดเด่นซึ่งไม่มีในฐานข้อมูลแบบสัมพันธ์ และแน่นอนว่าสำหรับผู้ใช้ที่ต้องการกำหนดการคำนวณที่ซับซ้องเองก็สามารถทำได้บนเซิร์ฟเวอร์ ซึ่งผู้ใช้คนอื่นก็สามารถเข้าใช้งานได้ด้วยเช่นกัน

OLAP เทคโนโยลีสำหรับการวิเคราะห์
 แนวโน้มของตลาด OLAP แสดงให้เห็นว่าผลิตภัณฑ์เซิร์ฟเวอร์ OLAP กำลังมีราคาลดลง มีประสิทธิภาพมากขึ้น สนับสนุนการขยายขนาด เพิ่มฟังก์ชันการทำงานโดยเฉพาะอย่างยิ่งการวิเคราะห์ข้อมูลทางธุรกิจ รวมทั้งยังมีส่วนขยายเพื่อทำงานร่วมกับระบบอื่น อย่างเช่น Data Mining ได้อีกด้วย แนวโน้มที่เกิดขึ้นกับ OLAP จะยังคงอยู่ต่อไปอีกหลายปีข้างหน้า ดังจะเห็นได้จากผู้ขายฐานข้อมูลรายใหญ่หลายรายได้เริ่มลงทุนและผลักดันผลิตภัณฑ์เซิร์ฟเวอร์ OLAP ของตนไปข้างหน้า ด้วยการเพิ่มลงในผลิตภัณฑ์เซิร์ฟเวอร์ฐานข้อมูลแบบสัมพันธ์ที่เป็นเรือธงของตัวเอง

เซิร์ฟเวอร์ OLAP นั้นทำหน้าที่นำเสนอข้อมูลในรูปแบบ Dimensional ด้วยวิธีการทำความเข้าใจได้ง่าย ช่วยให้ผู้ใช้สามารถเข้าใช้ฟังก์ชันในการวิเคราะห์ข้อมูลขององค์กรได้อย่างมีประสิทธิภาพ

มุมมองข้อมูลแบบ Cube

OLAP นั้นเป็นโมเดลการจัดโครงสร้างข้อมูลแบบ Dimension ที่ได้สืบทอดคุณสมบัติบางส่วนมาจากฐานข้อมูลแบบสัมพันธ์ โดยมีการเพิ่มความสามารถในการกำหนดความสัมพันธ์และการคำนวณที่มีประโยชน์ไว้บนเซิร์ฟเวอร์ การทำงานบนเซิร์ฟเวอร์มีข้อดีที่สำคัญก็ประสิทธิภาพของการคิวรีสูงขึ้นรวมทั้งยังสามารถใช้เครื่องมือในการคิวรีและวิเคราะห์ข้อมูลได้อย่างหลากหลาย คุณไม่ควรคิดว่าเซิร์ฟเวอร์ OLAP เป็นคู่แข่งของดาต้าแวร์เฮาส์ที่ทำงานบนของฐานข้อมูลแบบสัมพันธ์ หากแต่เป็นส่วนขยายที่ช่วยเพิ่มการใช้ประโยชน์จากเซิร์ฟเวอร์ฐานข้อมูลให้คุ้มค่ามากยิ่งขึ้น ผู้ใช้ต้องเข้าใจและทราบจุดเด่นของแต่ละผลิตภัณฑ์

ฐานข้อมูลแบบสัมพันธ์สำหรับการเก็บและจัดการข้อมูล รวมถึงการดึงและคิวรีข้อมูลพื้นฐานด้วยภาษาที่เข้าใจได้ง่ายอย่าง SQL หาก แต่สำหรับฟังก์ชันในการวิเคราะห์ข้อมูลที่เก็บอยู่แล้วก็คงจะต้องยกบทบาทให้กับ OLAP เป็นพระเอกสำหรับงานนี้



ที่มา :  PC Magazine ฉบับที่ 47 ธันวาคม 2545