การออกแบบคิวบ์ข้อมูล การสร้างคิวบ์ OLAP โดยใช้ Microsoft Query

ข้าว. 2.ชิ้นลูกบาศก์ OLAP

การหมุน(รูปที่ 3) - การดำเนินการเปลี่ยนตำแหน่งของการวัดที่แสดงในรายงานหรือบนหน้าที่แสดง ตัวอย่างเช่น การดำเนินการหมุนอาจเกี่ยวข้องกับการจัดเรียงแถวและคอลัมน์ของตารางใหม่ นอกจากนี้ การหมุนคิวบ์ข้อมูลจะย้ายมิติที่อยู่นอกตารางให้เข้าที่โดยมีมิติปรากฏบนเพจที่แสดง และในทางกลับกัน

คำอธิบายประกอบ: การบรรยายนี้ครอบคลุมพื้นฐานของการออกแบบคิวบ์ข้อมูลสำหรับคลังข้อมูล OLAP ตัวอย่างนี้แสดงวิธีการสร้างคิวบ์ข้อมูลโดยใช้เครื่องมือ CASE

วัตถุประสงค์ของการบรรยาย

หลังจากศึกษาเนื้อหาในการบรรยายนี้แล้ว คุณจะรู้ว่า:

• data cube อยู่ในอะไร คลังข้อมูล OLAP ;
• วิธีการออกแบบดาต้าคิวบ์สำหรับ คลังข้อมูล OLAP ;
• มิติข้อมูลคิวบ์คืออะไร
• ข้อเท็จจริงเกี่ยวข้องกับดาต้าคิวบ์อย่างไร
• คุณลักษณะของมิติคืออะไร
• ลำดับชั้นคืออะไร
• เมตริกคิวบ์ข้อมูลคืออะไร

และเรียนรู้:

• สร้าง แผนภูมิหลายมิติ ;
• การออกแบบที่เรียบง่าย แผนภูมิหลายมิติ.

การแนะนำ

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

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

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

แม้ว่า OLAP ไม่ใช่คุณลักษณะที่จำเป็นของคลังข้อมูล แต่ก็มีการใช้มากขึ้นในการวิเคราะห์ข้อมูลที่สะสมในคลังข้อมูลนี้

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

ดังนั้น, OLAP สามารถกำหนดเป็นชุดเครื่องมือสำหรับการวิเคราะห์ข้อมูลหลายมิติที่สะสมในคลังข้อมูล. ตามทฤษฎีแล้ว เครื่องมือ OLAP สามารถนำไปใช้กับข้อมูลการปฏิบัติงานหรือเครื่องมือเหล่านั้นได้โดยตรง สำเนาถูกต้อง. อย่างไรก็ตาม มีความเสี่ยงในการนำข้อมูลไปวิเคราะห์ซึ่งไม่เหมาะสำหรับการวิเคราะห์นี้

OLAP บนไคลเอนต์และเซิร์ฟเวอร์

OLAP ขึ้นอยู่กับการวิเคราะห์ข้อมูลหลายมิติ สามารถผลิตได้โดยใช้เครื่องมือต่างๆ ซึ่งสามารถแบ่งออกเป็นเครื่องมือ OLAP ของไคลเอนต์และเซิร์ฟเวอร์

เครื่องมือไคลเอ็นต์ OLAP คือแอปพลิเคชันที่คำนวณข้อมูลรวม (ผลรวม ค่าเฉลี่ย ค่าสูงสุดหรือต่ำสุด) และแสดงข้อมูลเหล่านั้น ในขณะที่ข้อมูลรวมนั้นอยู่ในแคชภายในพื้นที่ที่อยู่ของเครื่องมือ OLAP ดังกล่าว

หากข้อมูลต้นฉบับมีอยู่ใน DBMS บนเดสก์ท็อป การคำนวณข้อมูลรวมจะดำเนินการโดยเครื่องมือ OLAP เอง หากแหล่งที่มาของข้อมูลต้นฉบับคือเซิร์ฟเวอร์ DBMS เครื่องมือ OLAP ไคลเอนต์จำนวนมากจะส่งการสืบค้น SQL ที่มีตัวดำเนินการ GROUP BY ไปยังเซิร์ฟเวอร์ และด้วยเหตุนี้จึงได้รับข้อมูลรวมที่คำนวณบนเซิร์ฟเวอร์

ตามกฎแล้ว ฟังก์ชัน OLAP จะถูกนำไปใช้ในเครื่องมือประมวลผลข้อมูลทางสถิติ (ตั้งแต่ผลิตภัณฑ์ในระดับนี้ไปจนถึง ตลาดรัสเซียผลิตภัณฑ์จาก Stat Soft และ SPSS มีการใช้กันอย่างแพร่หลาย) และในสเปรดชีตบางรายการ โดยเฉพาะอย่างยิ่งมีเครื่องมือวิเคราะห์หลายมิติที่ดี ไมโครซอฟต์ เอ็กเซล 2000 การใช้ผลิตภัณฑ์นี้ คุณสามารถสร้างและบันทึกเป็นไฟล์ลูกบาศก์ OLAP หลายมิติขนาดเล็กในเครื่อง และแสดงส่วนสองหรือสามมิติ

มากมาย เครื่องมือในการพัฒนามีไลบรารีของคลาสหรือส่วนประกอบที่ช่วยให้คุณสามารถสร้างแอปพลิเคชันที่ใช้ฟังก์ชัน OLAP แบบง่าย ๆ ได้ (เช่น ส่วนประกอบ Decision Cube ใน Borland Delphi และ Borland C++ Builder) นอกจากนี้บริษัทหลายแห่งยังเสนอ การควบคุม ActiveX และไลบรารีอื่นๆ ที่ใช้ฟังก์ชันการทำงานที่คล้ายกัน

โปรดทราบว่าตามกฎแล้วใช้เครื่องมือ OLAP ไคลเอนต์โดยมีขนาดจำนวนน้อย (โดยปกติจะแนะนำให้ใช้ไม่เกินหก) และค่าที่หลากหลายเล็กน้อยสำหรับพารามิเตอร์เหล่านี้ - หลังจากนั้นข้อมูลรวมที่ได้จะต้องพอดีกับ ที่อยู่พื้นที่ของเครื่องมือดังกล่าว และจำนวนของมันจะเพิ่มขึ้นแบบทวีคูณเมื่อจำนวนเพิ่มการวัด ดังนั้นตามกฎแล้วแม้แต่เครื่องมือ OLAP ไคลเอนต์ดั้งเดิมที่สุดก็ยังอนุญาตให้คำนวณเบื้องต้นเกี่ยวกับจำนวน RAM ที่ต้องการเพื่อสร้างคิวบ์หลายมิติในนั้น

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

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

ข้อดีของการใช้เครื่องมือเซิร์ฟเวอร์ OLAP เมื่อเปรียบเทียบกับเครื่องมือ OLAP ไคลเอนต์นั้นคล้ายคลึงกับข้อดีของการใช้เซิร์ฟเวอร์ DBMS เมื่อเปรียบเทียบกับเดสก์ท็อป: ในกรณีที่ใช้เครื่องมือเซิร์ฟเวอร์ การคำนวณและการจัดเก็บข้อมูลรวมจะเกิดขึ้นบนเซิร์ฟเวอร์ และแอปพลิเคชันไคลเอนต์ รับเฉพาะผลลัพธ์ของการสืบค้นซึ่งโดยทั่วไปช่วยลดการรับส่งข้อมูลเครือข่าย เวลานำคำขอและข้อกำหนดทรัพยากรที่ใช้โดยแอปพลิเคชันไคลเอนต์ โปรดทราบว่าตามกฎแล้วเครื่องมือวิเคราะห์และประมวลผลข้อมูลระดับองค์กรจะขึ้นอยู่กับเครื่องมือ OLAP ของเซิร์ฟเวอร์ เช่น Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, ผลิตภัณฑ์จาก Crystal Decisions, Business Objects, Cognos, SAS สถาบัน. เนื่องจากผู้ผลิตเซิร์ฟเวอร์ DBMS ชั้นนำทั้งหมดผลิต (หรือได้รับอนุญาตจากบริษัทอื่น) เครื่องมือ OLAP เซิร์ฟเวอร์หนึ่งหรือหลายเครื่อง ทางเลือกจึงค่อนข้างกว้าง และในเกือบทุกกรณี คุณสามารถซื้อเซิร์ฟเวอร์ OLAP จากผู้ผลิตรายเดียวกันกับเซิร์ฟเวอร์ฐานข้อมูลเอง .

โปรดทราบว่าเครื่องมือ OLAP ไคลเอนต์จำนวนมาก (โดยเฉพาะ Microsoft Excel 2003, Seagate Analysis ฯลฯ) อนุญาตให้คุณเข้าถึงที่เก็บข้อมูล OLAP ของเซิร์ฟเวอร์ ซึ่งในกรณีนี้เป็นแอปพลิเคชันไคลเอนต์ที่ดำเนินการค้นหาดังกล่าว นอกจากนี้ยังมีผลิตภัณฑ์มากมายที่เป็นแอปพลิเคชันไคลเอนต์สำหรับเครื่องมือ OLAP จากผู้ผลิตหลายราย

ด้านเทคนิคของการจัดเก็บข้อมูลหลายมิติ

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

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

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

• โมแลป(OLAP หลายมิติ) - แหล่งข้อมูลและข้อมูลรวมจะถูกจัดเก็บไว้ในฐานข้อมูลหลายมิติ การจัดเก็บข้อมูลในโครงสร้างหลายมิติช่วยให้คุณสามารถจัดการข้อมูลเป็นอาร์เรย์หลายมิติได้เนื่องจากความเร็วในการคำนวณค่ารวมจะเท่ากันสำหรับมิติข้อมูลใด ๆ อย่างไรก็ตาม ในกรณีนี้ ฐานข้อมูลหลายมิติซ้ำซ้อน เนื่องจากข้อมูลหลายมิติประกอบด้วยข้อมูลเชิงสัมพันธ์ดั้งเดิมทั้งหมด
• โรแลป(OLAP เชิงสัมพันธ์) - ข้อมูลต้นฉบับยังคงอยู่ในฐานข้อมูลเชิงสัมพันธ์เดียวกันกับที่ข้อมูลเดิมตั้งอยู่ ข้อมูลรวมจะถูกวางไว้ในตารางบริการที่สร้างขึ้นเป็นพิเศษเพื่อจัดเก็บไว้ในฐานข้อมูลเดียวกัน
• ฮอลป(Hybrid OLAP) - ข้อมูลต้นฉบับยังคงอยู่ในฐานข้อมูลเชิงสัมพันธ์เดียวกันกับที่ข้อมูลเดิมตั้งอยู่ และข้อมูลรวมจะถูกจัดเก็บไว้ในฐานข้อมูลหลายมิติ

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

โปรดทราบว่าเครื่องมือ OLAP สมัยใหม่ส่วนใหญ่ไม่เก็บค่า "ว่างเปล่า" (ตัวอย่างของค่า "ว่างเปล่า" คือการไม่มีการขายผลิตภัณฑ์ตามฤดูกาลนอกฤดูกาล)

แนวคิด OLAP พื้นฐาน

การทดสอบแฟมซี

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

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

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

การแสดงข้อมูลหลายมิติ

ลูกบาศก์

OLAP มอบวิธีที่สะดวกและรวดเร็วในการเข้าถึง ดู และวิเคราะห์ข้อมูลทางธุรกิจ ผู้ใช้จะได้รับความเป็นธรรมชาติและใช้งานง่าย แบบจำลองข้อมูลจัดเรียงเป็นรูปลูกบาศก์หลายมิติ (Cubes). แกนของระบบพิกัดหลายมิติเป็นคุณลักษณะหลักของกระบวนการทางธุรกิจที่วิเคราะห์ ตัวอย่างเช่น สำหรับการขาย อาจเป็นผลิตภัณฑ์ ภูมิภาค ประเภทผู้ซื้อ เวลาถูกใช้เป็นมิติหนึ่ง ที่จุดตัดของแกนการวัด (ขนาด) จะมีข้อมูลที่อธิบายลักษณะเชิงปริมาณของกระบวนการ - การวัด (การวัด) นี่อาจเป็นปริมาณการขายเป็นชิ้นหรือเป็นเงื่อนไขทางการเงิน ยอดคงเหลือ ต้นทุน ฯลฯ ผู้ใช้ที่วิเคราะห์ข้อมูลสามารถ "ตัด" คิวบ์ไปในทิศทางที่ต่างกัน รับข้อมูลสรุป (เช่น ตามปี) หรือในทางกลับกัน มีรายละเอียด ( ตามสัปดาห์ ) ข้อมูลและดำเนินการจัดการอื่น ๆ ที่อยู่ในใจของเขาในระหว่างกระบวนการวิเคราะห์

ตามการวัดในลูกบาศก์สามมิติที่แสดงในรูปที่. 26.1 มีการใช้ยอดขาย และเวลา ผลิตภัณฑ์ และร้านค้าถูกใช้เป็นมิติ การวัดจะแสดงใน ระดับหนึ่งการจัดกลุ่ม: สินค้าจะถูกจัดกลุ่มตามหมวดหมู่ ร้านค้า - ตามประเทศ และข้อมูล ณ เวลาที่ทำธุรกรรม - ตามเดือน อีกไม่นานเราจะดูรายละเอียดเพิ่มเติมเกี่ยวกับระดับของการจัดกลุ่ม ( ลำดับชั้น)

ข้าว. 26.1.

"ตัด" ลูกบาศก์

แม้แต่ลูกบาศก์สามมิติก็ยากที่จะแสดงบนหน้าจอคอมพิวเตอร์เพื่อให้มองเห็นค่าของการวัดที่น่าสนใจ เราจะพูดอะไรเกี่ยวกับลูกบาศก์ที่มีมากกว่าสามมิติ? ตามกฎแล้วในการแสดงภาพข้อมูลที่เก็บไว้ในคิวบ์ จะใช้สองมิติที่คุ้นเคย เช่น มุมมองตารางที่มีแถวลำดับชั้นและส่วนหัวของคอลัมน์ที่ซับซ้อน

การแสดงลูกบาศก์สองมิติสามารถรับได้โดยการ "ตัด" ตามขวางตามแกน (มิติ) หนึ่งแกนขึ้นไป: เราแก้ไขค่าของทุกมิติยกเว้นสองและเราจะได้ตารางสองมิติปกติ แกนนอนของตาราง (ส่วนหัวของคอลัมน์) แสดงถึงมิติหนึ่ง แกนตั้ง (ส่วนหัวของแถว) แสดงถึงอีกมิติหนึ่ง และเซลล์ตารางแสดงถึงค่าของการวัด ในกรณีนี้ ชุดของหน่วยวัดจะถือว่าเป็นหนึ่งในมิติข้อมูล: เราจะเลือกหนึ่งหน่วยวัดที่จะแสดง (จากนั้นเราสามารถวางสองมิติในส่วนหัวของแถวและคอลัมน์) หรือแสดงหลายหน่วยวัด (และจากนั้นหนึ่งใน แกนตารางจะถูกครอบครองโดยชื่อของการวัดและอีกอันจะเป็นค่าของมิติ "ไม่ได้เจียระไน" เท่านั้น)

สถาปัตยกรรมของแอปพลิเคชัน OLAP

ทุกสิ่งที่กล่าวไว้ข้างต้นเกี่ยวกับ OLAP เกี่ยวข้องกับการนำเสนอข้อมูลหลายมิติเป็นหลัก พูดคร่าวๆ แล้ววิธีการจัดเก็บข้อมูลไม่ได้เกี่ยวข้องกับผู้ใช้ปลายทางหรือผู้พัฒนาเครื่องมือที่ลูกค้าใช้

ความเป็นหลายมิติในแอปพลิเคชัน OLAP สามารถแบ่งออกเป็นสามระดับ

• การแสดงข้อมูลหลายมิติ - เครื่องมือสำหรับผู้ใช้ปลายทางที่ให้การแสดงภาพและการจัดการข้อมูลหลายมิติ เลเยอร์การแสดงหลายมิติจะสรุปจากโครงสร้างทางกายภาพของข้อมูลและถือว่าข้อมูลเป็นแบบหลายมิติ
• การประมวลผลหลายมิติเป็นวิธี (ภาษา) สำหรับการกำหนดแบบสอบถามหลายมิติ (SQL ภาษาเชิงสัมพันธ์แบบดั้งเดิมไม่เหมาะสมที่นี่) และตัวประมวลผลที่สามารถประมวลผลและดำเนินการแบบสอบถามดังกล่าว
• พื้นที่จัดเก็บข้อมูลหลายมิติเป็นวิธีการจัดระเบียบข้อมูลทางกายภาพที่ช่วยให้การดำเนินการสืบค้นหลายมิติมีประสิทธิภาพ

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

ตามกฎแล้วผลิตภัณฑ์ OLAP เฉพาะเป็นเครื่องมือการนำเสนอข้อมูลหลายมิติ (ไคลเอนต์ OLAP - ตัวอย่างเช่น Pivot Tables ใน Excel 2000 จาก Microsoft หรือ ProClarity จาก Knosys) หรือเซิร์ฟเวอร์ DBMS หลายมิติ (เซิร์ฟเวอร์ OLAP - เช่น Oracle Express Server หรือ บริการ Microsoft OLAP)

โดยปกติแล้วเลเยอร์การประมวลผลหลายมิติจะถูกสร้างขึ้นในไคลเอนต์ OLAP และ/หรือเซิร์ฟเวอร์ OLAP แต่สามารถแยกได้ในรูปแบบที่บริสุทธิ์ เช่น ส่วนประกอบ Pivot Table Service ของ Microsoft

/ ในลักษณะเหลี่ยม. การประยุกต์คิวบ์ OLAP ในการจัดการของบริษัทขนาดใหญ่

ติดต่อกับ

เพื่อนร่วมชั้น

คอนสแตนติน ต็อกมาเชฟ, สถาปนิกระบบ

ในสไตล์คิวบิสต์
การประยุกต์คิวบ์ OLAP ในการจัดการของบริษัทขนาดใหญ่

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

เกี่ยวกับประโยชน์ของการวิเคราะห์ธุรกิจ

ในวงจรการจัดการองค์กร ระหว่างข้อมูล "ดิบ" และ "คันโยก" ที่มีอิทธิพลต่อออบเจ็กต์ที่ได้รับการจัดการ จะมี "ตัวบ่งชี้ประสิทธิภาพ" - KPI พวกมันสร้าง "แดชบอร์ด" ชนิดหนึ่งซึ่งสะท้อนถึงสถานะของระบบย่อยต่าง ๆ ของวัตถุที่ถูกควบคุม การจัดหาตัวบ่งชี้ประสิทธิภาพที่ให้ข้อมูลแก่บริษัทและการติดตามการคำนวณและมูลค่าที่ได้รับเป็นงานของนักวิเคราะห์ธุรกิจ บริการวิเคราะห์อัตโนมัติ เช่น ยูทิลิตี MS SQL Server Analysis Services (SSAS) และเครื่องมือหลัก OLAP cube สามารถให้ความช่วยเหลือที่สำคัญในการจัดระเบียบงานการวิเคราะห์ของบริษัท

ต้องมีอีกประเด็นหนึ่งที่นี่ สมมติว่าตามธรรมเนียมของอเมริกา ความเชี่ยวชาญพิเศษที่เน้นการทำงานกับคิวบ์ OLAP เรียกว่า BI (Business Intelligence) ไม่ควรมีภาพลวงตาว่า American BI สอดคล้องกับ "นักวิเคราะห์ธุรกิจ" ของรัสเซีย ไม่มีความผิด แต่บ่อยครั้งที่นักวิเคราะห์ธุรกิจของเราเป็น "นักบัญชี" และ "นักบัญชีต่ำกว่า" ซึ่งเป็นผู้เชี่ยวชาญที่มีความรู้คลุมเครือและมีเงินเดือนเพียงเล็กน้อย ซึ่งจริงๆ แล้วไม่มีเครื่องมือและวิธีการเป็นของตัวเอง

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

ใน เมื่อเร็วๆ นี้แนวโน้มที่เป็นอันตรายเกิดขึ้นอีกประการหนึ่ง ด้วยความเชี่ยวชาญ ความเข้าใจร่วมกันระหว่างพนักงานบริษัทประเภทต่างๆ จึงสูญหายไป นักบัญชี ผู้จัดการ และโปรแกรมเมอร์ เช่น “หงส์ กั้ง และหอก” ในนิทานของ I.A. ครีลอฟ กำลังดึงบริษัทไปในทิศทางที่ต่างกัน

นักบัญชียุ่งอยู่กับการรายงานจำนวนเงินของเขาทั้งในความหมายและเชิงไดนามิกไม่เกี่ยวข้องโดยตรงกับกระบวนการทางธุรกิจของ บริษัท

ผู้จัดการกำลังยุ่งอยู่กับส่วนหนึ่งของกระบวนการทางธุรกิจ แต่ไม่สามารถประเมินผลลัพธ์และแนวโน้มของการกระทำของเขาในระดับบริษัทโดยรวมได้ทั่วโลก

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

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

ข้อดีของคิวบ์ OLAP

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

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

เหตุใดคิวบ์ OLAP จึงเหมาะอย่างยิ่งสำหรับการแก้ปัญหาเชิงวิเคราะห์ OLAP cube ได้รับการออกแบบในลักษณะที่ตัวบ่งชี้ทั้งหมดในส่วนที่เป็นไปได้ทั้งหมดได้รับการคำนวณล่วงหน้า (ทั้งหมดหรือบางส่วน) และผู้ใช้สามารถ "ดึง" ตัวบ่งชี้ที่ต้องการ (การวัด) และขนาด (มิติ) ที่ต้องการเท่านั้น เมาส์และโปรแกรมสามารถวาดตารางใหม่ได้

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

การกำหนดการวิเคราะห์สามารถทำได้ในสามตัวเลือก: เป็นฟิลด์ฐานข้อมูล (หรือฟิลด์คลังสินค้า) หรือฟิลด์การคำนวณที่กำหนดที่ระดับการออกแบบคิวบ์ หรือนิพจน์ภาษา MDX เมื่อทำงานแบบโต้ตอบกับคิวบ์

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

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

ลองยกตัวอย่าง สมมติว่าผู้จัดการควบคุมบัญชีลูกหนี้ ตราบใดที่ KPI สำหรับลูกหนี้ที่เกินกำหนดชำระเป็นสีเขียว หมายความว่าทุกอย่างเป็นปกติ และไม่จำเป็นต้องดำเนินการใดๆ จากฝ่ายจัดการ หากสีเปลี่ยนเป็นสีเหลืองหรือสีแดง แสดงว่ามีสิ่งผิดปกติ เราตัด KPI ตามแผนกขาย และเห็นแผนกต่างๆ “เป็นสีแดง” ทันที ส่วนถัดไปโดยผู้จัดการ - และผู้ขายที่มีลูกค้าที่อยู่เบื้องหลังการชำระเงินจะถูกระบุ (นอกจากนี้จำนวนเงินที่ค้างชำระสามารถแบ่งตามลูกค้าตามเงื่อนไข ฯลฯ ) หัวหน้า บริษัท สามารถติดต่อผู้ฝ่าฝืนได้โดยตรงทุกระดับ แต่โดยทั่วไปแล้ว ทั้งหัวหน้าแผนกและผู้จัดการฝ่ายขายจะเห็น KPI เดียวกัน (ที่ระดับลำดับชั้น) ดังนั้น เพื่อแก้ไขสถานการณ์ พวกเขาไม่จำเป็นต้องรอ "เรียกร้อง" ด้วยซ้ำ... แน่นอนว่า KPI ไม่จำเป็นต้องเป็นจำนวนเงินที่ค้างชำระ - อาจเป็น ระยะเวลาถัวเฉลี่ยถ่วงน้ำหนักของการชำระเงินที่ค้างชำระหรือโดยทั่วไปคืออัตราการหมุนเวียนของลูกหนี้

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

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

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

นั่นคือ OLAP cube ช่วยให้คุณทำงานวิเคราะห์ได้ (ซึ่งจริง ๆ แล้วไม่เพียงดำเนินการโดยนักวิเคราะห์แผนกต้อนรับเท่านั้น แต่ในความเป็นจริงแล้วโดยพนักงานเกือบทั้งหมดของ บริษัท แม้แต่นักโลจิสติกส์และผู้จัดการที่ควบคุมยอดคงเหลือและการจัดส่ง) คัดเลือกมากขึ้น “ไม่ใช่เงื่อนไขทั่วไป” ซึ่งสร้างเงื่อนไขในการปรับปรุงงานและเพิ่มผลผลิต

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

OLTP + OLAP: วงจรป้อนกลับในห่วงโซ่การจัดการของบริษัท

ตอนนี้เรามาดูแนวคิดทั่วไปของคิวบ์ OLAP และจุดใช้งานในห่วงโซ่การจัดการองค์กร คำว่า OLAP (OnLine Analytical Processing) ได้รับการแนะนำโดยนักคณิตศาสตร์ชาวอังกฤษ Edgar Codd นอกเหนือจากคำที่แนะนำก่อนหน้านี้ OLTP (OnLine Transactions Processing) จะมีการหารือเรื่องนี้ในภายหลัง แต่แน่นอนว่า E. Codd ไม่เพียงเสนอคำศัพท์เท่านั้น แต่ยังรวมถึงทฤษฎีทางคณิตศาสตร์ของ OLTP และ OLAP ด้วย ในการตีความสมัยใหม่ OLTP เป็นฐานข้อมูลเชิงสัมพันธ์ซึ่งถือเป็นกลไกในการบันทึก จัดเก็บ และเรียกค้นข้อมูลโดยไม่ต้องลงรายละเอียด

วิธีการแก้ปัญหา

ระบบ ERP (การวางแผนทรัพยากรองค์กร) เช่น 1C7, 1C8, MS Dynamics AX มีอินเทอร์เฟซซอฟต์แวร์ที่มุ่งเน้นผู้ใช้ (การป้อนและแก้ไขเอกสาร ฯลฯ) และฐานข้อมูลเชิงสัมพันธ์ (DB) สำหรับจัดเก็บและเรียกค้นข้อมูลที่นำเสนอในปัจจุบัน ผลิตภัณฑ์ซอฟต์แวร์พิมพ์ MS SQL Server (SS)

โปรดทราบว่าข้อมูลที่ลงทะเบียนในฐานข้อมูลระบบ ERP ถือเป็นทรัพยากรที่มีค่ามากจริงๆ ประเด็นไม่เพียงแต่ข้อมูลที่ลงทะเบียนช่วยให้มั่นใจถึงการไหลของเอกสารปัจจุบันของบริษัท (การแยกเอกสาร การแก้ไข ความสามารถในการพิมพ์และกระทบยอด ฯลฯ) และไม่เพียงแต่ความเป็นไปได้ในการคำนวณ งบการเงิน(ภาษี การตรวจสอบ ฯลฯ) จากมุมมองของฝ่ายบริหาร สิ่งสำคัญกว่านั้นคือระบบ OLTP (ฐานข้อมูลเชิงสัมพันธ์) นั้นเป็นแบบจำลองดิจิทัลขนาดเท่าจริงของกิจกรรมของบริษัท

แต่ในการจัดการกระบวนการ การลงทะเบียนข้อมูลเกี่ยวกับกระบวนการนั้นไม่เพียงพอ กระบวนการควรนำเสนอในรูปแบบของระบบตัวชี้วัดเชิงตัวเลข (KPI) ที่แสดงถึงความก้าวหน้า นอกจากนี้ต้องกำหนดช่วงของค่าที่ยอมรับได้สำหรับตัวบ่งชี้ และเฉพาะในกรณีที่ค่าของตัวบ่งชี้อยู่นอกช่วงเวลาที่อนุญาต การดำเนินการควบคุมควรปฏิบัติตาม

เกี่ยวกับตรรกะ (หรือตำนาน) ของการควบคุม (“การควบคุมโดยการเบี่ยงเบน”) ทั้งสองอย่าง นักปรัชญาชาวกรีกโบราณเพลโตผู้สร้างภาพลักษณ์ของผู้ถือหางเสือเรือ (ไซเบอร์โนส) ซึ่งพิงไม้พายเมื่อเรือเบี่ยงเบนไปจากเส้นทางและนักคณิตศาสตร์ชาวอเมริกัน Norbert Wiener ผู้สร้างวิทยาศาสตร์แห่งไซเบอร์เนติกส์ในยุคคอมพิวเตอร์

นอกเหนือจากระบบปกติสำหรับการบันทึกข้อมูลโดยใช้วิธี OLTP แล้ว ยังจำเป็นต้องมีระบบอื่น - ระบบสำหรับการวิเคราะห์ข้อมูลที่รวบรวม ส่วนเสริมนี้ซึ่งในลูปควบคุมมีบทบาทในการตอบรับระหว่างการจัดการและออบเจ็กต์ควบคุม คือระบบ OLAP หรือกล่าวโดยย่อคือ OLAP cube

ในการใช้งานซอฟต์แวร์ของ OLAP เราจะพิจารณายูทิลิตี้ MS Analysis Services ซึ่งเป็นส่วนหนึ่งของการจัดส่งมาตรฐานของ MS SQL Server หรือ SSAS แบบย่อ โปรดทราบว่าตามแผนของ E. Codd คิวบ์ OLAP ในการวิเคราะห์ควรให้อิสระในการดำเนินการที่ครอบคลุมเช่นเดียวกับที่ระบบ OLTP และฐานข้อมูลเชิงสัมพันธ์ (SQL Server) จัดให้มีในการจัดเก็บและเรียกค้นข้อมูล

โอแล็ป โลจิสติกส์

ตอนนี้เรามาดูการกำหนดค่าเฉพาะของอุปกรณ์ภายนอก โปรแกรมแอปพลิเคชัน และการดำเนินการทางเทคโนโลยีที่ใช้การทำงานอัตโนมัติของคิวบ์ OLAP

เราจะถือว่าบริษัทใช้ระบบ ERP เช่น 1C7 หรือ 1C8 ซึ่งภายในข้อมูลจะถูกบันทึกตามปกติ ฐานข้อมูลของระบบ ERP นี้อยู่บนเซิร์ฟเวอร์บางตัวและได้รับการสนับสนุนโดย MS SQL Server

นอกจากนี้ เรายังถือว่าเซิร์ฟเวอร์อื่นมีซอฟต์แวร์ติดตั้งอยู่ รวมถึง MS SQL Server พร้อมยูทิลิตี MS Analysis Services (SSAS) รวมถึง MS SQL Server Management Studio, MS C#, MS Excel และ MS Visual Studio โปรแกรมเหล่านี้ร่วมกันสร้างบริบทที่จำเป็น: เครื่องมือและอินเทอร์เฟซที่จำเป็นสำหรับนักพัฒนาคิวบ์ OLAP

เซิร์ฟเวอร์ SSAS มีโปรแกรมแจกจ่ายฟรีที่เรียกว่า blat ซึ่งเรียกว่า (พร้อมพารามิเตอร์) จาก บรรทัดคำสั่งและการให้บริการไปรษณีย์

ที่สถานที่ทำงานของพนักงานภายใน เครือข่ายท้องถิ่นเหนือสิ่งอื่นใดคือมีการติดตั้งโปรแกรม MS Excel (เวอร์ชันไม่ต่ำกว่า 2003) รวมถึงไดรเวอร์พิเศษเพื่อให้แน่ใจว่า MS Excel ทำงานร่วมกับ MS Analysis Services (เว้นแต่ว่าไดรเวอร์ที่เกี่ยวข้องจะรวมอยู่ใน MS Excel แล้ว)

เพื่อความชัดเจน เราจะถือว่าระบบปฏิบัติการ Windows XP ได้รับการติดตั้งบนเวิร์กสเตชันของพนักงาน และเซิร์ฟเวอร์ก็มี วินโดวส์เซิร์ฟเวอร์ 2008 นอกจากนี้ ให้ MS SQL Server 2005 ใช้เป็น SQL Server โดยติดตั้ง Enterprise Edition (EE) หรือ Developer Edition (DE) บนเซิร์ฟเวอร์ที่มีคิวบ์ OLAP ในฉบับเหล่านี้คุณสามารถใช้สิ่งที่เรียกว่าได้ “มาตรการกึ่งเติมแต่ง” เช่น ฟังก์ชันรวมเพิ่มเติม (สถิติ) นอกเหนือจากผลรวมปกติ (เช่น สุดขั้วหรือค่าเฉลี่ย)

การออกแบบลูกบาศก์ OLAP (คิวบิสม์ OLAP)

ลองพูดสักสองสามคำเกี่ยวกับการออกแบบของ OLAP cube เอง ในภาษาสถิติ OLAP cube คือชุดของตัวบ่งชี้ประสิทธิภาพที่คำนวณในส่วนที่จำเป็นทั้งหมด ตัวอย่างเช่น ตัวบ่งชี้การจัดส่งในส่วนตามลูกค้า ตามสินค้า ตามวันที่ ฯลฯ เนื่องจากการแปลโดยตรงจากภาษาอังกฤษในวรรณคดีรัสเซียบนคิวบ์ OLAP ตัวบ่งชี้จึงเรียกว่า "มาตรการ" และส่วนต่างๆ เรียกว่า "มิติ" นี่เป็นการแปลที่ถูกต้องทางคณิตศาสตร์ แต่การแปลทางวากยสัมพันธ์และความหมายไม่ประสบความสำเร็จมากนัก คำภาษารัสเซีย "การวัด" "มิติ" "มิติ" เกือบจะเหมือนกันทั้งในด้านความหมายและการสะกดคำ ในขณะที่ "การวัด" และ "มิติ" ในภาษาอังกฤษมีความแตกต่างกันทั้งในการสะกดและความหมาย ดังนั้นเราจึงให้ความสำคัญกับคำศัพท์ทางสถิติรัสเซียแบบดั้งเดิม "ตัวบ่งชี้" และ "การตัด" ซึ่งมีความหมายคล้ายกัน

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

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

แม้ว่าอย่างเป็นทางการแล้ว OLAP cube จะสามารถสร้างได้โดยใช้ตารางฐานข้อมูลเชิงสัมพันธ์ของระบบ ERP ทั้งหมด (หลายพัน) ตารางเป็นแหล่งข้อมูล และฟิลด์ทั้งหมด (หลายร้อย) ฟิลด์เป็นตัวบ่งชี้หรือส่วนต่างๆ แต่ในความเป็นจริง สิ่งนี้ไม่ควรทำ ในทางกลับกัน หากต้องการโหลดลงในคิวบ์ จะเป็นการถูกต้องมากกว่าในการเตรียมฐานข้อมูลแยกต่างหากที่เรียกว่า "ตู้โชว์" หรือ "คลังสินค้า"

มีเหตุผลหลายประการที่บังคับให้เราต้องทำเช่นนี้

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

คุณยังสามารถเพิ่มได้ว่าระบบ ERP และคิวบ์ OLAP ควรอยู่บนเซิร์ฟเวอร์ที่แตกต่างกันเพื่อแชร์โหลด แต่หากมีตารางทั่วไปสำหรับ OLAP และ OLTP ปัญหาการรับส่งข้อมูลเครือข่ายก็เกิดขึ้นเช่นกัน ปัญหาที่ไม่สามารถแก้ไขได้จริงเกิดขึ้นในกรณีนี้เมื่อจำเป็นต้องรวมระบบ ERP ที่แตกต่างกันหลายระบบ (1C7, 1C8, MS Dynamics AX) ไว้ในคิวบ์ OLAP เดียว

อาจเป็นไปได้ว่าเรายังสามารถสะสมปัญหาทางเทคนิคต่อไปได้ แต่สิ่งสำคัญที่สุดคือ จำไว้ว่า OLAP ต่างจาก OLTP ตรงที่ไม่ใช่วิธีการบันทึกและจัดเก็บข้อมูล แต่เป็นเครื่องมือในการวิเคราะห์ ซึ่งหมายความว่าไม่จำเป็นต้องอัปโหลดและดาวน์โหลดข้อมูล “สกปรก” จาก ERP ไปยัง OLAP “เผื่อไว้” ในทางตรงกันข้าม คุณต้องพัฒนาแนวคิดในการจัดการบริษัทก่อน อย่างน้อยก็ในระดับของระบบ KPI จากนั้นจึงออกแบบคลังข้อมูลแอปพลิเคชัน (คลังสินค้า) ซึ่งอยู่บนเซิร์ฟเวอร์เดียวกันกับคิวบ์ OLAP และประกอบด้วยขนาดเล็ก ปรับปรุงปริมาณข้อมูลจาก ERP ที่จำเป็นสำหรับการจัดการ

โดยไม่ต้องโปรโมท นิสัยที่ไม่ดีลูกบาศก์ OLAP ที่เกี่ยวข้องกับ OLTP สามารถเปรียบได้กับ "ลูกบาศก์นิ่ง" ที่รู้จักกันดี โดยสกัด "ผลิตภัณฑ์บริสุทธิ์" จาก "มวลหมัก" ของการลงทะเบียนจริง

ดังนั้นเราจึงพบว่าแหล่งข้อมูลสำหรับ OLAP เป็นฐานข้อมูลพิเศษ (คลังสินค้า) ซึ่งอยู่บนเซิร์ฟเวอร์เดียวกันกับ OLAP โดยทั่วไปนี่หมายถึงสองสิ่ง อันดับแรก จะต้องมีขั้นตอนพิเศษที่จะสร้างคลังสินค้าจากฐานข้อมูล ERP ประการที่สอง OLAP cube ไม่ซิงโครไนซ์กับระบบ ERP

เมื่อคำนึงถึงสิ่งที่กล่าวมาข้างต้น เราขอเสนอสถาปัตยกรรมกระบวนการประมวลผลเวอร์ชันต่อไปนี้

สถาปัตยกรรมโซลูชัน

สมมติว่ามีระบบ ERP จำนวนมากของบริษัทบางแห่ง (ถือครอง) ซึ่งอยู่บนเซิร์ฟเวอร์ที่แตกต่างกัน ข้อมูลการวิเคราะห์ที่เราต้องการจะดูรวมอยู่ในคิวบ์ OLAP เดียว เราเน้นย้ำว่าในเทคโนโลยีที่อธิบายไว้ เรารวมข้อมูลจากระบบ ERP ที่ระดับคลังสินค้า โดยไม่เปลี่ยนแปลงการออกแบบคิวบ์ OLAP

บนเซิร์ฟเวอร์ OLAP เราสร้างรูปภาพ (สำเนาเปล่า) ของฐานข้อมูลของระบบ ERP เหล่านี้ทั้งหมด เราทำการจำลองฐานข้อมูล ERP ที่ใช้งานอยู่ที่เกี่ยวข้องบางส่วนเป็นระยะๆ (ทุกคืน) ไปยังสำเนาเปล่าเหล่านี้

ถัดไป SP (ขั้นตอนการจัดเก็บ) จะถูกเปิดใช้งานซึ่งบนเซิร์ฟเวอร์ OLAP เดียวกันโดยไม่มีการรับส่งข้อมูลเครือข่าย โดยอิงตามแบบจำลองบางส่วนของฐานข้อมูลระบบ ERP จะสร้าง (หรือเติมเต็ม) คลังสินค้า (คลังสินค้า) - แหล่งข้อมูลของคิวบ์ OLAP

จากนั้น ขั้นตอนมาตรฐานสำหรับการอัพเดต/การสร้างคิวบ์ตามข้อมูลคลังสินค้าจะถูกเปิดใช้งาน (การดำเนินการประมวลผลในอินเทอร์เฟซ SSAS)

ขอแสดงความคิดเห็นเกี่ยวกับบางแง่มุมของเทคโนโลยี สปส.ทำงานด้านใดบ้าง?

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

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

ประการที่สอง การจำลองแบบบางส่วนอาจหมายความว่าไม่ได้คัดลอกฟิลด์ทั้งหมดของตาราง แต่จะคัดลอกเฉพาะฟิลด์ที่เกี่ยวข้องกับการสร้างคลังสินค้าเท่านั้น รายการฟิลด์ที่จะคัดลอกถูกระบุหรือสร้างขึ้นแบบไดนามิกใน SP ในรูปภาพของการคัดลอก (หากไม่ใช่ทุกฟิลด์จะแสดงในตอนแรกในสำเนาของตาราง)

แน่นอนว่าเป็นไปไม่ได้ที่จะไม่คัดลอกแถวทั้งหมดของตาราง แต่จะเพิ่มระเบียนใหม่เท่านั้น อย่างไรก็ตาม สิ่งนี้ทำให้เกิดความไม่สะดวกอย่างร้ายแรงเมื่อคำนึงถึงการแก้ไข ERP "ย้อนหลัง" ซึ่งมักเกิดขึ้นกับระบบในชีวิตจริง ดังนั้นจึงง่ายกว่าโดยไม่ต้องกังวลใจอีกต่อไปในการคัดลอกบันทึกทั้งหมด (หรืออัปเดต "ส่วนท้าย" โดยเริ่มจากวันที่กำหนด)

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

งานในการรวมระบบ ERP ที่แตกต่างกันหลายระบบไว้ในคิวบ์จะยากเป็นพิเศษหากชุดของอ็อบเจ็กต์ (ไดเร็กทอรีของสินค้า, ผู้รับเหมา, คลังสินค้า ฯลฯ) ทับซ้อนกันบางส่วน อ็อบเจ็กต์มีความหมายเหมือนกัน แต่โดยธรรมชาติแล้วจะอธิบายแตกต่างกันในไดเร็กทอรี ระบบที่แตกต่างกัน(ในแง่ของรหัส ตัวระบุ ชื่อ ฯลฯ)

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

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

นี่คือคำอธิบาย "การสอน" แบบเห็นภาพ ที่จริงแล้ว สถาปัตยกรรมของคิวบ์ OLAP อาจซับซ้อนกว่านี้มาก

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

ประการที่สอง "รังสี" ของเครื่องหมายดอกจันสามารถไม่ใช่แค่ไดเร็กทอรีเดียว แต่เป็นระบบไฟล์ทั้งหมด (แบบลำดับชั้น)

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

ประการที่สี่ ขึ้นอยู่กับตัวบ่งชี้และส่วนที่มีอยู่ โดยใช้นิพจน์ภาษา MDX สามารถกำหนดตัวบ่งชี้ใหม่ (การคำนวณ) ได้ สิ่งสำคัญคือต้องทราบว่าคิวบ์ใหม่ ตัวบ่งชี้ใหม่ ส่วนใหม่จะถูกรวมเข้ากับองค์ประกอบดั้งเดิมโดยสมบูรณ์โดยอัตโนมัติ ควรสังเกตว่าการคำนวณที่มีการกำหนดสูตรไม่ดีและส่วนลำดับชั้นอาจทำให้การทำงานของคิวบ์ OLAP ช้าลงอย่างมาก

MS Excel เป็นส่วนต่อประสานกับ OLAP

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

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

อินเทอร์เฟซสำหรับ MS Excel มีให้โดยไดรเวอร์พิเศษ ซึ่งสามารถดาวน์โหลดแยกต่างหากหรือรวมอยู่ในการแจกจ่าย Excel ไม่ครอบคลุมฟังก์ชันการทำงานทั้งหมดของ OLAP แต่ด้วยการเติบโตของหมายเลขเวอร์ชัน MS Excel ความครอบคลุมนี้จึงกว้างขึ้น (ตัวอย่างเช่น การแสดง KPI แบบกราฟิกปรากฏใน MS Excel 2007 ซึ่งไม่ใช่กรณีใน MS Excel 2003 ฯลฯ)

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

ข้อได้เปรียบที่ยอดเยี่ยมของ MS Excel ในฐานะอินเทอร์เฟซกับ OLAP คือความสามารถในการประมวลผลข้อมูลที่ได้รับในรายงาน OLAP ได้อย่างอิสระเพิ่มเติม (เช่น ศึกษาข้อมูลที่ได้รับจาก OLAP ต่อไปบนแผ่นงานอื่นของ Excel เดียวกัน โดยไม่ได้ใช้เครื่องมือ OLAP อีกต่อไป แต่ โดยใช้เครื่องมือ Excel ทั่วไป)

วงจรการรักษา Facubi ทุกคืน

ตอนนี้เราจะอธิบายวงจรการคำนวณรายวัน (ทุกคืน) ของการดำเนินการ OLAP การคำนวณดำเนินการภายใต้การควบคุมของโปรแกรม facubi ซึ่งเขียนด้วยภาษา C# 2005 และเปิดใช้งานผ่าน Task Scheduler บนเซิร์ฟเวอร์ที่มีคลังสินค้าและ SSAS ในตอนเริ่มต้น facubi ไปที่อินเทอร์เน็ตและอ่านอัตราแลกเปลี่ยนปัจจุบัน (ใช้เพื่อแสดงตัวบ่งชี้จำนวนหนึ่งในสกุลเงิน) จากนั้นทำตามขั้นตอนต่อไปนี้

ขั้นแรก facubi เปิดตัว SP ที่ทำการจำลองฐานข้อมูลบางส่วนของระบบ ERP ต่างๆ (องค์ประกอบที่เก็บ) ที่มีอยู่ในเครือข่ายท้องถิ่น การจำลองแบบจะดำเนินการดังที่เรากล่าวไว้ใน "พื้นหลัง" ที่เตรียมไว้ล่วงหน้า - รูปภาพของระบบ ERP ระยะไกลที่อยู่บนเซิร์ฟเวอร์ SSAS

ประการที่สอง ผ่าน SP การแมปจะดำเนินการจากแบบจำลอง ERP ไปยังที่จัดเก็บคลังสินค้า - ฐานข้อมูลพิเศษซึ่งเป็นแหล่งที่มาของข้อมูลคิวบ์ OLAP และตั้งอยู่บนเซิร์ฟเวอร์ SSAS ในกรณีนี้ งานหลักสามประการจะได้รับการแก้ไข:

• ข้อมูลระบบอีอาร์พีปรับเป็นรูปแบบคิวบ์ที่ต้องการ เรากำลังพูดถึงทั้งตารางและเขตข้อมูลตาราง (บางครั้งตารางที่ต้องการจำเป็นต้อง "จัดรูปแบบ" เช่น จากแผ่นงาน MS Excel หลายแผ่น) ข้อมูลที่คล้ายกันอาจมีรูปแบบที่แตกต่างกันใน ERP ที่แตกต่างกัน ตัวอย่างเช่น ฟิลด์รหัสคีย์ในไดเร็กทอรี 1C7 มีรหัสอักขระ 36 หลักที่มีความยาว 8 และฟิลด์ _idrref ในไดเร็กทอรี 1С8 – เลขฐานสิบหกที่มีความยาว 32;
• ระหว่างการประมวลผล มีการดำเนินการควบคุมข้อมูลเชิงตรรกะ (รวมถึงการเขียนค่าเริ่มต้นแทนข้อมูลที่หายไป หากเป็นไปได้) และการควบคุมความสมบูรณ์ เช่น ตรวจสอบการมีอยู่ของคีย์หลักและรองในลักษณนามที่เกี่ยวข้อง
• การรวมรหัส วัตถุที่มีความหมายเหมือนกันใน ERP ที่แตกต่างกัน ตัวอย่างเช่น องค์ประกอบที่สอดคล้องกันของไดเร็กทอรีของ ERP ที่แตกต่างกันอาจมีความหมายเหมือนกัน กล่าวคือ เป็นคู่สัญญาเดียวกัน ปัญหาของการรวมโค้ดได้รับการแก้ไขโดยการสร้างตารางการแมป โดยที่โค้ดที่แตกต่างกันของออบเจ็กต์เดียวกันจะถูกรวมเป็นหนึ่งเดียว

ประการที่สาม facubi เรียกใช้ขั้นตอนมาตรฐานสำหรับการอัพเดตข้อมูล Process cube (จากขั้นตอนของยูทิลิตี SSAS)

ตามรายการตรวจสอบ facubi จะส่งอีเมลเกี่ยวกับความคืบหน้าของขั้นตอนการประมวลผล

หลังจากดำเนินการ facubi แล้ว Task Scheduler จะเปิดไฟล์ Excel หลายไฟล์ตามลำดับ ซึ่งรายงานจะถูกสร้างขึ้นล่วงหน้าตามตัวบ่งชี้คิวบ์ OLAP ดังที่เราได้กล่าวไว้ MS Excel มีอินเทอร์เฟซซอฟต์แวร์พิเศษ (ดาวน์โหลดแยกต่างหากหรือมีไดรเวอร์ในตัว) สำหรับการทำงานกับคิวบ์ OLAP (พร้อม SSAS) เมื่อคุณเริ่ม MS Excel โปรแกรม MS VBA (เช่น มาโคร) จะถูกเปิดใช้งาน ซึ่งช่วยให้มั่นใจว่าข้อมูลในรายงานได้รับการอัปเดต รายงานจะได้รับการแก้ไขหากจำเป็นและส่งทางไปรษณีย์ (โปรแกรม blat) ไปยังผู้ใช้ตามรายการตรวจสอบ

ผู้ใช้เครือข่ายท้องถิ่นที่สามารถเข้าถึงเซิร์ฟเวอร์ SSAS จะได้รับรายงาน "สด" ที่กำหนดค่าสำหรับคิวบ์ OLAP (โดยหลักการแล้ว พวกเขาเองโดยไม่ต้องส่งเมลใด ๆ สามารถอัปเดตรายงาน OLAP ใน MS Excel ซึ่งอยู่บนเครื่องคอมพิวเตอร์ของตนได้) ผู้ใช้นอกเครือข่ายท้องถิ่นจะได้รับรายงานต้นฉบับ แต่มีฟังก์ชันการทำงานที่จำกัดหรือสำหรับพวกเขา (หลังจากอัปเดต OLAP รายงานใน MS Excel) รายงานพิเศษ "เสีย" ที่ไม่สามารถเข้าถึงเซิร์ฟเวอร์ SSAS จะถูกคำนวณ

การประเมินผล

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

เวลาดำเนินการของขั้นตอนการอัพเดตขึ้นอยู่กับคุณสมบัติการออกแบบของคิวบ์ OLAP (ความซับซ้อนมากหรือน้อย คำจำกัดความของตัวบ่งชี้และส่วนที่ประสบความสำเร็จไม่มากก็น้อย) และปริมาณฐานข้อมูลของระบบ OLTP ภายนอก ตามประสบการณ์ ขั้นตอนการก่อสร้างคลังสินค้าใช้เวลาหลายนาทีถึงสองชั่วโมง ขั้นตอนการอัปเดตคิวบ์ (กระบวนการ) จะใช้เวลาตั้งแต่ 1 ถึง 20 นาที เรากำลังพูดถึงคิวบ์ OLAP ที่ซับซ้อนซึ่งรวมโครงสร้างดาวหลายสิบรายการเข้าด้วยกัน “รังสี” ทั่วไปหลายสิบรายการ (ส่วนอ้างอิง) สำหรับพวกมัน และตัวบ่งชี้หลายร้อยตัว การประมาณปริมาณฐานข้อมูลของระบบ ERP ภายนอกตามเอกสารการจัดส่ง เรากำลังพูดถึงเอกสารหลายแสนฉบับและตามด้วยสายผลิตภัณฑ์นับล้านต่อปี ความลึกของการประมวลผลในอดีตที่ผู้ใช้สนใจคือสามถึงห้าปี

เทคโนโลยีดังกล่าวได้ถูกนำมาใช้ในองค์กรขนาดใหญ่หลายแห่ง: ตั้งแต่ปี 2551 ใน Russian Fish Company (RRK) และ Russian Sea Company (RM) ตั้งแต่ปี 2555 ในบริษัท Santa Bremor (SB) บริษัทบางแห่งส่วนใหญ่เป็นบริษัทการค้าและการจัดซื้อ (PPC) ส่วนบริษัทอื่นๆ เป็นบริษัทผู้ผลิต (โรงงานแปรรูปปลาและอาหารทะเลในสาธารณรัฐมอลโดวาและสาธารณรัฐเบลารุส) บริษัททั้งหมดถือหุ้นใหญ่ โดยรวมบริษัทหลายแห่งเข้ากับระบบบัญชีคอมพิวเตอร์ที่เป็นอิสระและหลากหลาย ตั้งแต่ระบบ ERP มาตรฐาน เช่น 1C7 และ 1C8 ไปจนถึงระบบบัญชี "โบราณ" ที่ใช้ DBF และ Excel ฉันจะเสริมว่าเทคโนโลยีที่อธิบายไว้สำหรับการใช้งานคิวบ์ OLAP (โดยไม่คำนึงถึงขั้นตอนการพัฒนา) ไม่จำเป็นต้องใช้พนักงานพิเศษเลยหรือเป็นความรับผิดชอบของนักวิเคราะห์ธุรกิจเต็มเวลาคนหนึ่ง งานดังกล่าวดำเนินการโดยอัตโนมัติมานานหลายปี ทำให้พนักงานองค์กรประเภทต่างๆ ได้รับรายงานที่ทันสมัยทุกวัน

ข้อดีข้อเสียของการแก้ปัญหา

ประสบการณ์แสดงให้เห็นว่าโซลูชันที่นำเสนอค่อนข้างเชื่อถือได้และใช้งานง่าย ปรับเปลี่ยนได้อย่างง่ายดาย (การเชื่อมต่อ/ยกเลิกการเชื่อมต่อ ERP ใหม่ การสร้างตัวบ่งชี้และส่วนใหม่ การสร้างและการแก้ไขรายงาน Excel และรายชื่ออีเมล) โดยไม่แปรผันของโปรแกรมควบคุม facubi

MS Excel เป็นอินเทอร์เฟซกับ OLAP ให้การแสดงออกที่เพียงพอและช่วยให้พนักงานสำนักงานประเภทต่างๆ คุ้นเคยกับเทคโนโลยี OLAP ได้อย่างรวดเร็ว ผู้ใช้จะได้รับรายงาน OLAP “มาตรฐาน” ทุกวัน การใช้อินเทอร์เฟซ MS Excel กับ OLAP สามารถสร้างรายงาน OLAP ใน MS Excel ได้อย่างอิสระ นอกจากนี้ผู้ใช้สามารถศึกษาข้อมูลรายงาน OLAP ต่อไปได้อย่างอิสระโดยใช้ความสามารถปกติของ MS Excel

ฐานข้อมูลคลังสินค้า "ที่ได้รับการปรับปรุง" ซึ่งมีการรวมระบบ ERP ที่ต่างกันหลายระบบเข้าด้วยกัน (ระหว่างการสร้างคิวบ์) แม้ว่าจะไม่มี OLAP ก็ตาม ก็ช่วยให้คุณแก้ไขได้ (บนเซิร์ฟเวอร์ SSAS โดยใช้วิธีสืบค้นใน Transact SQL หรือวิธี SP ฯลฯ) ปัญหาการจัดการที่ประยุกต์ใช้มากมาย ให้เราระลึกว่าโครงสร้างฐานข้อมูลคลังสินค้าเป็นหนึ่งเดียวและง่ายกว่ามาก (ในแง่ของจำนวนตารางและจำนวนฟิลด์ของตาราง) มากกว่าโครงสร้างฐานข้อมูลของ ERP ดั้งเดิม

เราทราบเป็นพิเศษว่าในโซลูชันที่เรานำเสนอ มีความเป็นไปได้ที่จะรวมระบบ ERP ต่างๆ ไว้ใน OLAP cube เดียว สิ่งนี้ช่วยให้คุณได้รับการวิเคราะห์สำหรับการถือครองทั้งหมดและรักษาความต่อเนื่องในระยะยาวในการวิเคราะห์เมื่อองค์กรย้ายไปยังระบบ ERP การบัญชีอื่น เช่น เมื่อย้ายจาก 1C7 เป็น 1C8

เราใช้โมเดลลูกบาศก์ MOLAP ข้อดีของรุ่นนี้คือความน่าเชื่อถือในการทำงานและความเร็วสูงในการประมวลผลคำขอของผู้ใช้ ข้อเสีย: OLAP และ OLTP เป็นแบบอะซิงโครนัส เช่นเดียวกับหน่วยความจำจำนวนมากสำหรับจัดเก็บ OLAP

โดยสรุป นี่เป็นอีกข้อโต้แย้งที่สนับสนุน OLAP ที่อาจเหมาะสมกว่าในยุคกลาง เพราะอำนาจในการพิสูจน์หลักฐานขึ้นอยู่กับอำนาจ อี. คอดด์ นักคณิตศาสตร์ชาวอังกฤษผู้เจียมเนื้อเจียมตัวและประเมินต่ำเกินไปอย่างชัดเจนได้พัฒนาทฤษฎีฐานข้อมูลเชิงสัมพันธ์ในช่วงปลายทศวรรษที่ 60 พลังของทฤษฎีนี้ทำให้หลังจากผ่านไป 50 ปีแล้ว การค้นหาฐานข้อมูลที่ไม่เกี่ยวข้องและภาษาคิวรีฐานข้อมูลอื่นที่ไม่ใช่ SQL เป็นเรื่องยากอยู่แล้ว

เทคโนโลยี OLTP ซึ่งใช้ทฤษฎีฐานข้อมูลเชิงสัมพันธ์เป็นแนวคิดแรกของ E. Codd ในความเป็นจริง แนวคิดของคิวบ์ OLAP เป็นแนวคิดที่สองของเขา ซึ่งแสดงออกโดยเขาในช่วงต้นทศวรรษที่ 90 แม้จะไม่ได้เป็นนักคณิตศาสตร์ คุณก็สามารถคาดหวังได้ว่าแนวคิดที่สองจะมีประสิทธิภาพเท่ากับแนวคิดแรก นั่นคือในแง่ของการวิเคราะห์คอมพิวเตอร์ แนวคิด OLAP จะเข้ายึดครองโลกในไม่ช้าและเข้ามาแทนที่แนวคิดอื่นๆ ทั้งหมด เพียงเพราะหัวข้อการวิเคราะห์พบวิธีแก้ปัญหาทางคณิตศาสตร์ที่ครอบคลุมใน OLAP และวิธีการแก้ปัญหานี้ "เพียงพอ" (คำศัพท์ของ B. Spinoza) สำหรับปัญหาเชิงปฏิบัติของการวิเคราะห์ “เพียงพอ” หมายถึงในสปิโนซาว่าพระเจ้าเองก็ไม่สามารถคิดอะไรได้ดีไปกว่านี้แล้ว...

1. Larson B. การพัฒนาการวิเคราะห์ธุรกิจใน Microsoft SQL Server 2005 – เซนต์ปีเตอร์สเบิร์ก: “Peter”, 2008
2. Codd E. ความสมบูรณ์เชิงสัมพันธ์ของภาษาย่อยฐานข้อมูล, ระบบฐานข้อมูล, Courant วิทยาการคอมพิวเตอร์ Sumposia Series 1972, v. 6, หน้าผา Englwood, NY, Prentice – Hall

ติดต่อกับ

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

คลังข้อมูล (สถานที่ของ OLAP ในโครงสร้างข้อมูลขององค์กร)

คำว่า "OLAP" มีความเชื่อมโยงกับคำว่า "คลังข้อมูล" (คลังข้อมูล) อย่างแยกไม่ออก

นี่คือคำจำกัดความที่กำหนดโดย Bill Inmon “บิดาผู้ก่อตั้ง” แห่งคลังข้อมูล: “คลังข้อมูลคือการรวบรวมข้อมูลเฉพาะโดเมน มีกำหนดเวลา และไม่เปลี่ยนรูป เพื่อสนับสนุนการตัดสินใจของฝ่ายบริหาร”

ข้อมูลในคลังสินค้ามาจากระบบปฏิบัติการ (ระบบ OLTP) ซึ่งได้รับการออกแบบมาเพื่อทำให้กระบวนการทางธุรกิจเป็นแบบอัตโนมัติ นอกจากนี้ พื้นที่เก็บข้อมูลสามารถเติมเต็มจากแหล่งภายนอก เช่น รายงานทางสถิติ

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

ดังนั้น วัตถุประสงค์ของพื้นที่เก็บข้อมูลคือเพื่อจัดเตรียม “วัตถุดิบ” สำหรับการวิเคราะห์ไว้ในที่เดียวและในโครงสร้างที่เรียบง่ายและเข้าใจได้ Ralph Kimball ในคำนำของหนังสือ "The Data Warehouse Toolkit" เขียนว่าหากหลังจากอ่านหนังสือทั้งเล่มแล้ว ผู้อ่านเข้าใจเพียงสิ่งเดียวเท่านั้น กล่าวคือ โครงสร้างของคลังสินค้าควรเรียบง่าย ผู้เขียนจะพิจารณาของเขา งานเสร็จสมบูรณ์

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

ในความคิดของฉัน พื้นที่เก็บข้อมูลไม่จำเป็นต้องหมายถึงการสะสมข้อมูลจำนวนมหาศาล - สิ่งสำคัญคือสะดวกในการวิเคราะห์ โดยทั่วไปแล้ว มีคำศัพท์แยกต่างหากสำหรับสถานที่จัดเก็บข้อมูลขนาดเล็ก นั่นคือ Data Marts (ตู้ข้อมูล) แต่ในทางปฏิบัติของรัสเซีย คุณอาจไม่ได้ยินคำนี้บ่อยนัก

OLAP - เครื่องมือวิเคราะห์ที่สะดวก

การรวมศูนย์และการจัดโครงสร้างที่สะดวกไม่ใช่ทั้งหมดที่นักวิเคราะห์ต้องการ เขายังคงต้องการเครื่องมือในการดูและแสดงข้อมูลเป็นภาพ รายงานแบบเดิม แม้แต่รายงานที่สร้างขึ้นบนพื้นที่เก็บข้อมูลเดียวก็ยังขาดสิ่งหนึ่งที่สำคัญ นั่นก็คือความยืดหยุ่น ไม่สามารถ "บิด" "ขยาย" หรือ "ยุบ" เพื่อให้ได้มุมมองข้อมูลที่ต้องการ แน่นอนคุณสามารถโทรหาโปรแกรมเมอร์ได้ (ถ้าเขาต้องการมา) และเขา (ถ้าเขาไม่ยุ่ง) จะทำรายงานใหม่เร็วพอ - พูดภายในหนึ่งชั่วโมง (ฉันกำลังเขียนสิ่งนี้และฉันไม่เชื่อ ด้วยตัวเอง - ในชีวิตมันไม่ได้เกิดขึ้นเร็วขนาดนั้น ให้เวลาเขาสามชั่วโมงเถอะ) . ปรากฎว่านักวิเคราะห์สามารถทดสอบแนวคิดได้ไม่เกินสองแนวคิดต่อวัน และเขา (หากเขาเป็นนักวิเคราะห์ที่ดี) ก็สามารถคิดไอเดียดังกล่าวได้หลายไอเดียต่อชั่วโมง และยิ่งนักวิเคราะห์เห็น "ส่วน" และ "ส่วน" ของข้อมูลที่มากขึ้น เขาก็จะมีแนวคิดมากขึ้น ซึ่งในทางกลับกัน ก็ต้องอาศัย "ส่วน" ในการตรวจสอบมากขึ้นเรื่อยๆ ถ้าเพียงเขามีเครื่องมือที่ช่วยให้เขาขยายและยุบข้อมูลได้อย่างง่ายดายและสะดวก! OLAP ทำหน้าที่เป็นเครื่องมือดังกล่าว

แม้ว่า OLAP ไม่ใช่คุณลักษณะที่จำเป็นของคลังข้อมูล แต่ก็มีการใช้มากขึ้นในการวิเคราะห์ข้อมูลที่สะสมในคลังสินค้า

ส่วนประกอบที่รวมอยู่ในที่เก็บทั่วไปจะแสดงในรูปที่ 1 1.

ข้าว. 1. โครงสร้างคลังข้อมูล

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

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

ความหมายและแนวคิดพื้นฐานของ OLAP

ก่อนอื่น มาถอดรหัสกันก่อน: OLAP คือการประมวลผลการวิเคราะห์แบบออนไลน์ กล่าวคือ การวิเคราะห์ข้อมูลการปฏิบัติงาน หลักการกำหนด 12 ประการของ OLAP ถูกกำหนดขึ้นในปี 1993 โดย E.F. Codd "ผู้ประดิษฐ์" ฐานข้อมูลเชิงสัมพันธ์ ต่อมา คำจำกัดความได้รับการแก้ไขใหม่ในสิ่งที่เรียกว่าการทดสอบ FASMI ซึ่งกำหนดให้แอปพลิเคชัน OLAP ต้องมีความสามารถในการวิเคราะห์ข้อมูลหลายมิติที่ใช้ร่วมกันได้อย่างรวดเร็ว ()

การทดสอบฟาสมี

เร็ว(เร็ว) - การวิเคราะห์ควรดำเนินการอย่างรวดเร็วเท่าๆ กันในทุกด้านของข้อมูล เวลาตอบสนองที่ยอมรับได้คือ 5 วินาทีหรือน้อยกว่า

การวิเคราะห์(การวิเคราะห์) - จะต้องเป็นไปได้ที่จะดำเนินการวิเคราะห์เชิงตัวเลขและสถิติประเภทพื้นฐานที่กำหนดล่วงหน้าโดยผู้พัฒนาแอปพลิเคชันหรือกำหนดโดยผู้ใช้อย่างอิสระ

แบ่งปันแล้ว(แชร์) - ผู้ใช้จำนวนมากต้องมีสิทธิ์เข้าถึงข้อมูล ในขณะที่จำเป็นต้องควบคุมการเข้าถึงข้อมูลที่เป็นความลับ

หลายมิติ(หลายมิติ) เป็นคุณลักษณะหลักที่สำคัญที่สุดของ OLAP

ข้อมูล(ข้อมูล) - แอปพลิเคชันจะต้องสามารถเข้าถึงข้อมูลที่จำเป็นใด ๆ โดยไม่คำนึงถึงปริมาณและตำแหน่งการจัดเก็บ

OLAP = มุมมองหลายมิติ = Cube

OLAP มอบวิธีที่สะดวกและรวดเร็วในการเข้าถึง ดู และวิเคราะห์ข้อมูลทางธุรกิจ ผู้ใช้จะได้รับแบบจำลองข้อมูลที่เป็นธรรมชาติและใช้งานง่าย โดยจัดเรียงข้อมูลไว้ในรูปแบบของลูกบาศก์หลายมิติ (Cubes) แกนของระบบพิกัดหลายมิติเป็นคุณลักษณะหลักของกระบวนการทางธุรกิจที่วิเคราะห์ ตัวอย่างเช่น สำหรับการขาย อาจเป็นผลิตภัณฑ์ ภูมิภาค ประเภทผู้ซื้อ เวลาถูกใช้เป็นมิติหนึ่ง ที่จุดตัดของแกน - มิติ (มิติ) - มีข้อมูลที่อธิบายลักษณะเชิงปริมาณของกระบวนการ - การวัด (การวัด) นี่อาจเป็นปริมาณการขายเป็นชิ้นหรือเป็นเงื่อนไขทางการเงิน ยอดคงเหลือ ต้นทุน ฯลฯ ผู้ใช้ที่วิเคราะห์ข้อมูลสามารถ "ตัด" คิวบ์ไปในทิศทางที่ต่างกัน รับข้อมูลสรุป (เช่น ตามปี) หรือในทางกลับกัน มีรายละเอียด ( ตามสัปดาห์ ) ข้อมูลและดำเนินการจัดการอื่น ๆ ที่อยู่ในใจของเขาในระหว่างกระบวนการวิเคราะห์

ตามการวัดในลูกบาศก์สามมิติที่แสดงในรูปที่. 2 มีการใช้ยอดขาย และเวลา ผลิตภัณฑ์และร้านค้าถูกใช้เป็นมิติ การวัดผลจะแสดงในระดับเฉพาะของการจัดกลุ่ม ได้แก่ ผลิตภัณฑ์จะถูกจัดกลุ่มตามหมวดหมู่ ร้านค้าตามประเทศ และข้อมูลระยะเวลาในการทำธุรกรรมตามเดือน อีกไม่นานเราจะดูรายละเอียดเพิ่มเติมเกี่ยวกับระดับของการจัดกลุ่ม (ลำดับชั้น)

ข้าว. 2. ตัวอย่างคิวบ์

"ตัด" ลูกบาศก์

แม้แต่ลูกบาศก์สามมิติก็ยากที่จะแสดงบนหน้าจอคอมพิวเตอร์เพื่อให้มองเห็นค่าของการวัดที่น่าสนใจ เราจะพูดอะไรเกี่ยวกับลูกบาศก์ที่มีมากกว่าสามมิติ? ตามกฎแล้วในการแสดงภาพข้อมูลที่เก็บไว้ในคิวบ์ จะใช้สองมิติที่คุ้นเคย เช่น ตาราง มุมมองที่มีแถวลำดับชั้นที่ซับซ้อนและส่วนหัวของคอลัมน์

การแสดงลูกบาศก์สองมิติสามารถรับได้โดยการ "ตัด" มันข้ามแกน (มิติ) หนึ่งแกนขึ้นไป: เราแก้ไขค่าของทุกมิติยกเว้นสองและเราจะได้ตารางสองมิติปกติ แกนนอนของตาราง (ส่วนหัวของคอลัมน์) แสดงถึงมิติหนึ่ง แกนตั้ง (ส่วนหัวของแถว) แสดงถึงอีกมิติหนึ่ง และเซลล์ตารางแสดงถึงค่าของการวัด ในกรณีนี้ ชุดของการวัดจะถือว่าเป็นหนึ่งในมิติ - เราจะเลือกหนึ่งหน่วยวัดที่จะแสดง (จากนั้นเราสามารถวางสองมิติในส่วนหัวของแถวและคอลัมน์) หรือแสดงหลายหน่วยวัด (และจากนั้นหนึ่งใน แกนตารางจะถูกครอบครองโดยชื่อของการวัดและค่าอื่น ๆ ของมิติ "ไม่ได้เจียระไน" เท่านั้น)

ลองดูที่รูป 3 - นี่คือลูกบาศก์สองมิติสำหรับหนึ่งหน่วยวัด - ยอดขายต่อหน่วย (ชิ้นที่ขาย) และสองมิติ "ไม่ได้เจียระไน" - ร้านค้า (ร้านค้า) และเวลา (เวลา)

ข้าว. 3. ชิ้นลูกบาศก์ 2D สำหรับการวัดหนึ่งครั้ง

ในรูป รูปที่ 4 แสดงมิติที่ "ไม่ได้เจียระไน" เพียงมิติเดียว - ร้านค้า แต่แสดงค่าของการวัดต่างๆ - ยอดขายต่อหน่วย (หน่วยที่ขาย) ยอดขายในร้าน (จำนวนการขาย) และต้นทุนร้านค้า (ค่าใช้จ่ายร้านค้า)

ข้าว. 4. ชิ้นลูกบาศก์ 2D สำหรับการวัดหลายแบบ

การแสดงลูกบาศก์สองมิติยังเป็นไปได้เมื่อมีมิติมากกว่าสองมิติที่ยังคง "ไม่ได้เจียระไน" ในกรณีนี้ ลูกบาศก์ "ตัด" สองมิติขึ้นไปจะถูกวางบนแกนชิ้น (แถวและคอลัมน์) - ดูรูปที่ 1 5.

ข้าว. 5. ชิ้นลูกบาศก์ 2D ที่มีหลายมิติบนแกนเดียว

แท็ก

ค่าที่ "วาง" ตามมิติเรียกว่าสมาชิกหรือป้ายกำกับ ป้ายกำกับถูกใช้ทั้งเพื่อ "ตัด" คิวบ์และเพื่อจำกัด (กรอง) ข้อมูลที่เลือก - เมื่ออยู่ในมิติที่ยังคง "ไม่ได้เจียระไน" เราไม่ได้สนใจค่าทั้งหมด แต่อยู่ในชุดย่อยของค่าเหล่านั้น เช่น สามเมือง จากหลายสิบ ค่าป้ายกำกับจะปรากฏในมุมมองคิวบ์ 2D เป็นส่วนหัวของแถวและคอลัมน์

ลำดับชั้นและระดับ

ป้ายกำกับสามารถรวมกันเป็นลำดับชั้นที่ประกอบด้วยหนึ่งระดับขึ้นไป ตัวอย่างเช่น ป้ายกำกับของมิติร้านค้าจะถูกจัดกลุ่มเป็นลำดับชั้นตามระดับต่างๆ ตามธรรมชาติ:

ประเทศ

สถานะ

เมือง

เก็บ.

ค่ารวมจะคำนวณตามระดับของลำดับชั้น เช่น ปริมาณการขายสำหรับสหรัฐอเมริกา (ระดับ "ประเทศ") หรือสำหรับแคลิฟอร์เนีย (ระดับ "รัฐ") คุณสามารถใช้ลำดับชั้นมากกว่าหนึ่งลำดับชั้นในมิติเดียว เช่น สำหรับเวลา: (ปี ไตรมาส เดือน วัน) และ (ปี สัปดาห์ วัน)

สถาปัตยกรรมของแอปพลิเคชัน OLAP

ทุกสิ่งที่กล่าวไว้ข้างต้นเกี่ยวกับ OLAP เกี่ยวข้องกับการนำเสนอข้อมูลหลายมิติเป็นหลัก พูดคร่าวๆ แล้ววิธีการจัดเก็บข้อมูลไม่ได้เกี่ยวข้องกับผู้ใช้ปลายทางหรือผู้พัฒนาเครื่องมือที่ลูกค้าใช้

ความเป็นหลายมิติในแอปพลิเคชัน OLAP สามารถแบ่งออกเป็นสามระดับ:

• การแสดงข้อมูลหลายมิติ - เครื่องมือสำหรับผู้ใช้ปลายทางที่ให้การแสดงภาพและการจัดการข้อมูลหลายมิติ เลเยอร์การแสดงหลายมิติจะสรุปจากโครงสร้างทางกายภาพของข้อมูลและถือว่าข้อมูลเป็นแบบหลายมิติ
• การประมวลผลหลายมิติเป็นวิธี (ภาษา) สำหรับการกำหนดแบบสอบถามหลายมิติ (SQL ภาษาเชิงสัมพันธ์แบบดั้งเดิมไม่เหมาะสมที่นี่) และตัวประมวลผลที่สามารถประมวลผลและดำเนินการแบบสอบถามดังกล่าว
• พื้นที่จัดเก็บข้อมูลหลายมิติเป็นวิธีการจัดระเบียบข้อมูลทางกายภาพที่ช่วยให้การดำเนินการสืบค้นหลายมิติมีประสิทธิภาพ

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

ตามกฎแล้ว ผลิตภัณฑ์ OLAP ที่เฉพาะเจาะจงอาจเป็นเครื่องมือการแสดงข้อมูลหลายมิติ ไคลเอ็นต์ OLAP (เช่น Pivot Tables ใน Excel 2000 จาก Microsoft หรือ ProClarity จาก Knosys) หรือเซิร์ฟเวอร์ DBMS หลายมิติ เซิร์ฟเวอร์ OLAP (เช่น Oracle Express Server หรือบริการ Microsoft OLAP)

โดยปกติแล้วเลเยอร์การประมวลผลหลายมิติจะถูกสร้างขึ้นในไคลเอนต์ OLAP และ/หรือเซิร์ฟเวอร์ OLAP แต่สามารถแยกได้ในรูปแบบที่บริสุทธิ์ เช่น ส่วนประกอบ Pivot Table Service ของ Microsoft

ด้านเทคนิคของการจัดเก็บข้อมูลหลายมิติ

ตามที่กล่าวไว้ข้างต้น เครื่องมือวิเคราะห์ OLAP ยังสามารถแยกข้อมูลได้โดยตรงจากระบบเชิงสัมพันธ์ แนวทางนี้น่าสนใจกว่าในสมัยนั้นเมื่อเซิร์ฟเวอร์ OLAP ไม่รวมอยู่ในรายการราคาของผู้ผลิต DBMS ชั้นนำ แต่วันนี้ Oracle, Informix และ Microsoft นำเสนอเซิร์ฟเวอร์ OLAP เต็มรูปแบบและแม้แต่ผู้จัดการฝ่ายไอทีที่ไม่ชอบสร้าง "สวนสัตว์" ของซอฟต์แวร์จากผู้ผลิตหลายรายในเครือข่ายของพวกเขาก็สามารถซื้อ (หรือส่งคำขอที่เกี่ยวข้องเพื่อ ฝ่ายบริหารของบริษัท ) เซิร์ฟเวอร์ OLAP ยี่ห้อเดียวกันกับเซิร์ฟเวอร์ฐานข้อมูลหลัก

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

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

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

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

แต่ละวิธีมีข้อดีและข้อเสียในตัวเอง และควรใช้ขึ้นอยู่กับเงื่อนไข เช่น ปริมาณข้อมูล พลังของ DBMS เชิงสัมพันธ์ เป็นต้น

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

ยังมีต่อ. ในอนาคตเราจะพูดถึงผลิตภัณฑ์ OLAP เฉพาะที่ผลิตโดยผู้ผลิตชั้นนำ

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

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

ดังนั้น นักวิเคราะห์จึงต้องการข้อมูลจำนวนมาก ข้อมูลนี้เป็นข้อมูลเฉพาะเจาะจงและเป็นลักษณะของ " ชุดคุณลักษณะ - หมายเลข" อย่างหลังหมายความว่านักวิเคราะห์ทำงานกับตารางประเภทต่อไปนี้:

ที่นี่ " ประเทศ", "ผลิตภัณฑ์", "ปี" เป็นคุณลักษณะหรือ การวัด, เอ " ปริมาณการขาย" - ดังนั้นค่าตัวเลขหรือ วัด. เราทำซ้ำอีกครั้งว่างานของนักวิเคราะห์คือการระบุความสัมพันธ์ที่แข็งแกร่งระหว่างคุณลักษณะและพารามิเตอร์ตัวเลข. เมื่อดูที่ตาราง คุณจะสังเกตเห็นว่าสามารถแปลงเป็นสามมิติได้อย่างง่ายดาย เราจะวางประเทศไว้บนแกนใดแกนหนึ่ง สินค้าอยู่บนอีกแกน และปีที่สาม และค่าในอาร์เรย์สามมิตินี้จะเป็นปริมาณการขายที่สอดคล้องกัน

การแสดงตารางสามมิติ ส่วนสีเทาแสดงว่าไม่มีข้อมูลสำหรับอาร์เจนตินาในปี 1988

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

การวัด OLAP cube ประกอบด้วยสิ่งที่เรียกว่า เครื่องหมายหรือสมาชิก ตัวอย่างเช่น มิติข้อมูลประเทศประกอบด้วยป้ายกำกับอาร์เจนตินา บราซิล เวเนซุเอลา และอื่นๆ

ไม่จำเป็นต้องกรอกองค์ประกอบทั้งหมดของลูกบาศก์: หากไม่มีข้อมูลเกี่ยวกับการขายผลิตภัณฑ์ยางในอาร์เจนตินาในปี 1988 ก็จะไม่กำหนดค่าในเซลล์ที่เกี่ยวข้อง ไม่จำเป็นเลยที่แอปพลิเคชัน OLAP จำเป็นต้องจัดเก็บข้อมูลในโครงสร้างหลายมิติ - สิ่งสำคัญคือข้อมูลนี้มีลักษณะเช่นนี้สำหรับผู้ใช้ อย่างไรก็ตาม มันเป็นวิธีการพิเศษในการจัดเก็บข้อมูลหลายมิติขนาดกะทัดรัดที่ "สุญญากาศ" (องค์ประกอบที่ไม่ได้บรรจุ) ในคิวบ์ไม่ทำให้หน่วยความจำสิ้นเปลือง

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

ตามกฎแล้วมีเพียงสองมิติเท่านั้นที่ยังคง "ไม่ได้เจียระไน" - ตามจำนวนมิติในตาราง มันเกิดขึ้นว่ามีเพียงมิติเท่านั้นที่ยังคง "ไม่ได้เจียระไน" - หากคิวบ์มีค่าตัวเลขหลายประเภทก็สามารถลงจุดตามมิติตารางใดมิติหนึ่งได้

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

ตัวอย่างลำดับชั้น

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

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

แน่นอนว่าคุณต้องจ่ายเงินเพื่อเพิ่มผลผลิตด้วยวิธีนี้ บางครั้งมีการกล่าวกันว่าโครงสร้างข้อมูลเพียงแค่ "ระเบิด" - OLAP cube สามารถใช้พื้นที่มากกว่าข้อมูลดั้งเดิมหลายสิบหรือหลายร้อยเท่า

ตอบคำถาม:

เกิดอะไรขึ้น ลูกบาศก์ โอแลป?

เกิดอะไรขึ้น แท็ก การวัดเฉพาะ? ยกตัวอย่าง.

ได้ไหม มาตรการ วี คิวบ์ OLAPมีค่าที่ไม่ใช่ตัวเลข