Умови високої конкуренції та зростаючої динаміки довкілля диктують підвищені вимоги до систем управління підприємства. Розвиток теорії та практики управління супроводжувалися появою нових методів, технологій та моделей, орієнтованих на підвищення ефективності діяльності. Методи та моделі у свою чергу сприяли появі аналітичних систем. Затребуваність аналітичних систем у Росії – висока. Найцікавіші з погляду застосування ці системи у фінансовій сфері: банки, страховий бізнес, інвестиційні компанії. Результати роботи аналітичних систем потрібні насамперед людям, від вирішення яких залежить розвиток компанії: керівникам, експертам, аналітикам. Аналітичні системи дозволяють вирішувати завдання консолідації, звітності, оптимізації та прогнозування. До цього часу не склалося остаточної класифікації аналітичних систем, як і немає загальної системи визначень у термінах, що використовуються в даному напрямку. Інформаційна структура підприємства може бути представлена ​​послідовністю рівнів, кожен з яких характеризується своїм способом обробки та управління інформацією, та має свою функцію у процесі управління. Таким чином, аналітичні системи будуть розташовуватися ієрархічно на різних рівнях цієї інфраструктури.

Рівень трансакційних систем

Рівень сховищ даних

Рівень вітрин даних

Рівень OLAP – систем

Рівень аналітичних програм

OLAP - системи - (OnLine Analytical Processing, аналітична обробка в даний час) - є технологією комплексного багатовимірного аналізу даних. OLAP - системи застосовні там, де є завдання аналізу багатофакторних даних. Є ефективним засобом аналізу та генерації звітів. Розглянуті вище сховища даних, вітрини даних та OLAP – системи відносяться до систем бізнес – інтелекту (Business Intelligence, BI).

Найчастіше інформаційно-аналітичні системи, створювані для безпосереднього використання особами, які приймають рішення, виявляються надзвичайно прості у застосуванні, але жорстко обмежені у функціональності. Такі статичні системи називаються в літературі Інформаційними системами керівника (ІСР) або Executive Information Systems (EIS). Вони містять у собі зумовлені безлічі запитів і, будучи достатніми для повсякденного огляду, неспроможні відповісти на всі питання до наявних даних, які можуть виникнути при прийнятті рішень. Результатом роботи такої системи зазвичай є багатосторінкові звіти, після ретельного вивчення яких у аналітика з'являється нова серія питань. Однак кожен новий запит, непередбачений при проектуванні такої системи, повинен спочатку формально описаний, закодований програмістом і тільки потім виконаний. Час очікування у такому разі може становити години та дні, що не завжди прийнятно. Таким чином, зовнішня простота статичних СППР, за яку активно бореться більшість замовників інформаційно-аналітичних систем, обертається катастрофічною втратою гнучкості.

Динамічні СППР, навпаки, спрямовані на обробку нерегламентованих (ad hoc) запитів аналітиків до даних. Найбільш глибоко вимоги до таких систем розглянув E. F. Codd у статті, що започаткувала концепцію OLAP. Робота аналітиків з цими системами полягає в інтерактивній послідовності формування запитів та вивчення їх результатів.

Але динамічні СППР можуть діяти у сфері оперативної аналітичної обробки (OLAP); Підтримка прийняття управлінських рішень на основі накопичених даних може виконуватись у трьох базових сферах.

Сфера деталізованих даних. Це область впливу більшості систем, орієнтованих на пошук інформації. Найчастіше реляційні СУБД добре справляються з які виникають тут завданнями. Загальновизнаним стандартом мови маніпулювання реляційними даними є SQL. Інформаційно-пошукові системи, що забезпечують інтерфейс кінцевого користувача в задачах пошуку деталізованої інформації, можуть використовуватися як надбудови як над окремими базами даних транзакційних систем, так і над загальним сховищем даних.

Сфера агрегованих показників. Комплексний погляд на зібрану в сховищі даних інформацію, її узагальнення та агрегація, гіперкубічне подання та багатовимірний аналіз є завданнями систем оперативної аналітичної обробки даних (OLAP). Тут можна або орієнтуватися на спеціальні багатовимірні СУБД або залишатися в рамках реляційних технологій. У другому випадку заздалегідь агреговані дані можуть збиратися в БД зіркоподібного вигляду, або агрегація інформації може проводитися на льоту у процесі сканування деталізованих таблиць реляційної БД.

Сфера закономірностей. Інтелектуальна обробка проводиться методами інтелектуального аналізу даних (ІАД, Data Mining), головними завданнями яких є пошук функціональних та логічних закономірностей у накопиченій інформації, побудова моделей та правил, які пояснюють знайдені аномалії та/або прогнозують розвиток деяких процесів.

Оперативна аналітична обробка даних

В основі концепції OLAP лежить принцип багатовимірного представлення даних. У 1993 році у статті E. F. Codd розглянув недоліки реляційної моделі, насамперед вказавши на неможливість "об'єднувати, переглядати та аналізувати дані з точки зору множинності вимірювань, тобто найзрозумілішим для корпоративних аналітиків способом", і визначив загальні вимоги до систем OLAP, що розширює функціональність реляційних СУБД і що включає багатовимірний аналіз як одну зі своїх характеристик.

Класифікація продуктів OLAP за способом представлення даних.

В даний час на ринку є велика кількість продуктів, які в тій чи іншій мірі забезпечують функціональність OLAP. Близько 30 найвідоміших перераховано у списку оглядового Web-сервера http://www.olapreport.com/. Забезпечуючи багатовимірне концептуальне уявлення з боку інтерфейсу користувача до вихідної бази даних, всі продукти OLAP діляться на три класи за типом вихідної БД.

Найперші системи оперативної аналітичної обробки (наприклад, Essbase компанії Arbor Software, Oracle Express Server компанії Oracle) належали до класу MOLAP, тобто могли працювати лише зі своїми власними багатовимірними базами даних. Вони ґрунтуються на патентованих технологіях для багатовимірних СУБД і є найдорожчими. Ці системи забезпечують повний цикл обробки OLAP. Вони або включають, крім серверного компонента, власний інтегрований клієнтський інтерфейс, або використовують для зв'язку з користувачем зовнішні програми роботи з електронними таблицями. Для обслуговування таких систем потрібен спеціальний штат співробітників, які займаються встановленням, супроводом системи, формуванням уявлень даних кінцевих користувачів.

Системи оперативної аналітичної обробки реляційних даних (ROLAP) дозволяють представляти дані, що зберігаються в реляційній базі, в багатовимірній формі, забезпечуючи перетворення інформації в багатовимірну модель через проміжний шар метаданих. ROLAP-системи добре пристосовані до роботи з великими сховищами. Подібно до систем MOLAP, вони вимагають значних витрат на обслуговування фахівцями з інформаційних технологій і передбачають розрахований на багато користувачів режим роботи.

Нарешті, гібридні системи (Hybrid OLAP, HOLAP) розроблені з метою поєднання переваг та мінімізації недоліків, властивих попереднім класам. До цього класу належить Media/MR компанії Speedware. За твердженням розробників, він поєднує аналітичну гнучкість та швидкість відповіді MOLAP з постійним доступом до реальних даних, властивих ROLAP.

Багатовимірний OLAP (MOLAP)

У спеціалізованих СУБД, заснованих на багатовимірному поданні даних, дані організовані над формі реляційних таблиць, а вигляді упорядкованих багатовимірних масивів:

1) гіперкубів (всі зберігаються в БД осередки повинні мати однакову мірність, тобто перебувати в максимально повному базисі вимірів) або

2) полікубів (кожна змінна зберігається з власним набором вимірювань, і всі пов'язані з цим складності обробки перекладаються на внутрішні механізми системи).

Використання багатовимірних БД у системах оперативної аналітичної обробки має такі переваги.

У разі використання багатовимірних СУБД пошук і вибірка даних здійснюється значно швидше, ніж при багатовимірному концептуальному погляді на реляційну базу даних, так як багатовимірна база даних денормалізована, містить заздалегідь агреговані показники і забезпечує оптимізований доступ до осередків, що запитуються.

Багатовимірні СУБД легко справляються із завданнями включення до інформаційної моделі різноманітних вбудованих функцій, тоді як об'єктивно існуючі обмеження мови SQL роблять виконання цих завдань на основі реляційних СУБД досить складним, а іноді й неможливим.

З іншого боку, є суттєві обмеження.

Багатовимірні СУБД не дозволяють працювати з великими базами даних. До того ж за рахунок денормалізації та попередньо виконаної агрегації обсяг даних у багатовимірній базі, як правило, відповідає (за оцінкою Кодда) у 2.5-100 разів меншому обсягу вихідних деталізованих даних.

Багатовимірні СУБД у порівнянні з реляційними дуже неефективно використовують зовнішню пам'ять. У переважній більшості випадків інформаційний гіперкуб є сильно розрідженим, а оскільки дані зберігаються в упорядкованому вигляді, невизначені значення вдається видалити тільки за рахунок вибору оптимального порядку сортування, що дозволяє організувати дані максимально безперервні групи. Але навіть у цьому випадку проблема вирішується лише частково. Крім того, оптимальний з точки зору зберігання розріджених даних порядок сортування швидше за все не співпадатиме з порядком, який найчастіше використовується в запитах. Тому в реальних системах доводиться шукати компроміс між швидкодією та надмірністю дискового простору, зайнятого базою даних.

Отже, використання багатовимірних СУБД виправдано лише за таких умов.

Обсяг вихідних даних для аналізу невеликий (не більше кількох гігабайт), тобто рівень агрегації даних досить високий.

Набір інформаційних вимірів стабільний (оскільки будь-яка зміна їх структурі майже завжди потребує повної перебудови гиперкуба).

Час відповіді системи на нерегламентовані запити є критичним параметром.

Потрібне широке використання складних вбудованих функцій для виконання кросмерних обчислень над осередками гіперкуба, в тому числі можливість написання функцій користувача.

Реляційний OLAP (ROLAP)

Безпосереднє використання реляційних БД у системах оперативної аналітичної обробки має такі переваги.

У більшості випадків корпоративні сховища даних реалізуються засобами реляційних СУБД і інструменти ROLAP дозволяють проводити аналіз безпосередньо над ними. При цьому розмір сховища не є таким критичним параметром як у випадку MOLAP.

У разі змінної розмірності завдання, коли зміни до структури вимірювань доводиться вносити досить часто, ROLAP системи з динамічним уявленням розмірності є оптимальним рішенням, оскільки такі модифікації не потребують фізичної реорганізації БД.

Реляційні СУБД забезпечують значно вищий рівень захисту даних та хороші можливості розмежування прав доступу.

Головний недолік ROLAP у порівнянні з багатовимірними СУБД – менша продуктивність. Для забезпечення продуктивності, порівнянної з MOLAP, реляційні системи вимагають ретельного опрацювання схеми бази даних та налаштування індексів, тобто великих зусиль з боку адміністраторів БД. Тільки при використанні зіркоподібних схем продуктивність добре налаштованих реляційних систем може бути наближена до продуктивності систем на основі багатовимірних баз даних.

У циклі статей «Введення до баз даних», що публікувався останнім часом (див. Комп'ютерПрес №3'2000 - 3'2001), ми обговорювали різні технології та програмні засоби, що застосовуються при створенні інформаційних систем - настільні та серверні СУБД, засоби проектування даних , засоби розробки додатків, а також Business Intelligence – засоби аналізу та обробки даних масштабу підприємства, які в даний час стають все більш популярними у світі, у тому числі й у нашій країні. Зазначимо, що питання застосування засобів Business Intelligence та технології, що використовуються при створенні додатків такого класу, у вітчизняній літературі поки що висвітлені недостатньо. У новому циклі статей ми спробуємо заповнити цю прогалину і розповісти про те, що є технологіями, що лежать в основі подібних додатків. Як приклади реалізації ми будемо використовувати в основному OLAP-технології фірми Microsoft (головним чином Analysis Services у Microsoft SQL Server 2000), але сподіваємося, що основна частина матеріалу буде корисною і для користувачів інших засобів.

Перша стаття у цьому циклі присвячена основам OLAP (On-Line Analytical Processing) – технології багатовимірного аналізу даних. У ній ми розглянемо концепції сховищ даних та OLAP, вимоги до сховищ даних та OLAP-засобів, логічну організацію OLAP-даних, а також основні терміни та поняття, що застосовуються під час обговорення багатовимірного аналізу.

Що таке сховище даних

p align="justify"> Інформаційні системи масштабу підприємства, як правило, містять додатки, призначені для комплексного багатовимірного аналізу даних, їх динаміки, тенденцій і т.п. Такий аналіз зрештою покликаний сприяти прийняттю рішень. Нерідко ці системи і називаються - системи підтримки прийняття рішень.

Прийняти будь-яке управлінське рішення неможливо, не володіючи необхідною для цього інформацією, зазвичай кількісною. Для цього необхідно створення сховищ даних (Data warehouses), тобто процес збирання, відсіювання та попередньої обробки даних з метою надання результуючої інформації користувачам для статистичного аналізу (а нерідко й створення аналітичних звітів).

Ральф Кімбол (Ralph Kimball), один з авторів концепції сховищ даних, описував сховище даних як «місце, де люди можуть отримати доступ до своїх даних» (див., наприклад, Ralph Kimball, The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses», John Wiley & Sons, 1996 і «The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse», John Wiley & Sons, 2000). Він також сформулював і основні вимоги до сховищ даних:

• підтримка високої швидкості отримання даних із сховища;
• підтримка внутрішньої несуперечності даних;
• можливість отримання та порівняння про зрізів даних (slice and dice);
• наявність зручних утиліт перегляду даних у сховищі;
• повнота і достовірність даних, що зберігаються;
• - підтримка якісного процесу поповнення даних.

Задовольняти всім переліченим вимогам у межах того самого продукту часто не вдається. Тому для реалізації сховищ даних зазвичай використовується кілька продуктів, одні з яких являють собою власне засоби зберігання даних, інші – засоби їх отримання та перегляду, треті – засоби їх поповнення тощо.

Типове сховище даних зазвичай відрізняється від звичайної реляційної бази даних. По-перше, звичайні бази даних призначені для того, щоб допомогти користувачам виконувати повсякденну роботу, тоді як сховища даних призначені для прийняття рішень. Наприклад, продаж товару та виписка рахунки проводяться з використанням бази даних, призначеної для обробки транзакцій, а аналіз динаміки продажів за кілька років, що дозволяє спланувати роботу з постачальниками, – за допомогою сховища даних.

По-друге, звичайні бази даних схильні до постійних змін у процесі роботи користувачів, а сховище даних відносно стабільне: дані в ньому зазвичай оновлюються згідно з розкладом (наприклад, щотижня, щодня або щогодини - залежно від потреб). В ідеалі процес поповнення є просто додаванням нових даних за певний період часу без зміни колишньої інформації, що вже знаходиться в сховищі.

І по-третє, звичайні бази даних найчастіше є джерелом даних, що потрапляють до сховища. Крім того, сховище може поповнюватися за рахунок зовнішніх джерел, наприклад, статистичних звітів.

Що таке OLAP

Системи підтримки прийняття рішень зазвичай мають засоби надання користувачеві агрегатних даних для різних вибірок з вихідного набору в зручному для сприйняття та аналізу вигляді. Як правило, такі агрегатні функції утворюють багатовимірний (і, отже, нереляційний) набір даних (нерідко званий гіперкуб або метакуб), осі якого містять параметри, а комірки - залежні від них агрегатні дані. Вздовж кожної осі дані можуть бути організовані як ієрархії, що представляє різні рівні їх деталізації. Завдяки такій моделі даних користувачі можуть формулювати складні запити, генерувати звіти, отримувати підмножини даних.

Технологія комплексного багатовимірного аналізу даних одержала назву OLAP (On-Line Analytical Processing). OLAP – це ключовий компонент організації сховищ даних. Концепція OLAP була описана в 1993 році Едгаром Коддом, відомим дослідником баз даних і автором реляційної моделі даних (див. E.F. Codd, S.B. Codd, і C.T. Technical report, 1993). У 1995 році на основі вимог, викладених Коддом, був сформульований так званий тест FASMI (Fast Analysis of Shared Multidimensional Information - швидкий аналіз багатовимірної інформації, що розділяється), що включає наступні вимоги до додатків для багатовимірного аналізу:

• надання користувачеві результатів аналізу за прийнятний час (зазвичай не більше 5 с), навіть ціною менш детального аналізу;
• можливість здійснення будь-якого логічного та статистичного аналізу, характерного для даної програми, та її збереження в доступному для кінцевого користувача вигляді;
• розрахований на багато користувачів доступ до даних з підтримкою відповідних механізмів блокувань і засобів авторизованого доступу;
• багатовимірне концептуальне подання даних, включаючи повну підтримку для ієрархій та множинних ієрархій (це - ключова вимога OLAP);
• можливість звертатися до будь-якої потрібної інформації незалежно від її обсягу та місця зберігання.

Слід зазначити, що OLAP-функціональність може бути реалізована у різний спосіб, починаючи з найпростіших засобів аналізу даних в офісних додатках і закінчуючи розподіленими аналітичними системами, заснованими на серверних продуктах. Але перш ніж говорити про різні реалізації цієї функціональності, давайте розглянемо, що ж являють собою куби OLAP з логічного погляду.

Багатовимірні куби

У цьому розділі ми детальніше розглянемо концепцію OLAP та багатовимірних кубів. Як приклад реляційної бази даних, який ми будемо використовувати для ілюстрації принципів OLAP, скористаємося базою даних Northwind, що входить до комплектів постачання Microsoft SQL Server або Microsoft Access і є типовою базою даних, що зберігає відомості про торгові операції компанії, що займається оптовими поставками продовольства. До таких даних відносяться відомості про постачальників, клієнтів, компаній, що здійснюють доставку, список товарів, що поставляються, та їх категорій, дані про замовлення та замовлені товари, список співробітників компанії. Детальний опис бази даних Northwind можна знайти в довідкових системах Microsoft SQL Server або Microsoft Access - тут, за браком місця, ми його не наводимо.

Для розгляду концепції OLAP скористаємося поданням Invoices та таблицями Products та Categories з бази даних Northwind, створивши запит, в результаті якого отримаємо докладні відомості про всі замовлені товари та виписані рахунки:

SELECT dbo.Invoices.Country, dbo.Invoices.City, dbo.Invoices.CustomerName, dbo.Invoices.Salesperson, dbo.Invoices.OrderDate, dbo.Categories.CategoryName, dbo.Invoices.ProductName, dbo.Invoices.ShipperName, dbo. .Invoices.ExtendedPrice FROM dbo.Products INNER JOIN dbo.Categories ON dbo.Products.CategoryID = dbo.Categories.CategoryID INNER JOIN dbo.Invoices ON dbo.Products.ProductID = dbo.Invoices.ProductID

У Access 2000 аналогічний запит має вигляд:

SELECT Invoices.Country, Invoices.City, Invoices.Customers.CompanyName AS CustomerName, Invoices.Salesperson, Invoices.OrderDate, Categories.CategoryName, Invoices.ProductName, Invoices.Shippers.CompanyName AS ShipperName, Invoices INNER JOIN Products ON Invoices.ProductID = Products.ProductID) ON Categories.CategoryID = Products.CategoryID;

Цей запит звертається до подання Invoices, що містить відомості про всі виписані рахунки, а також до таблиць Categories і Products, що містять відомості про категорії продуктів, які замовлялися, і про продукти відповідно. В результаті цього запиту ми отримаємо набір даних про замовлення, що включає категорію та найменування замовленого товару, дату розміщення замовлення, ім'я співробітника, який виписав рахунок, місто, країну та назву компанії-замовника, а також найменування компанії, яка відповідає за доставку.

Для зручності збережемо цей запит у вигляді подання, назвавши його Invoices1. Результат звернення до цього подання наведено на рис. 1 .

Які агрегатні дані ми можемо одержати на основі цього подання? Зазвичай це відповіді питання типу:

• Якою є сумарна вартість замовлень, зроблених клієнтами з Франції?
• Якою є сумарна вартість замовлень, зроблених клієнтами з Франції та доставлених компанією Speedy Express?
• Яка сумарна вартість замовлень, зроблених клієнтами з Франції у 1997 році та доставлених компанією Speedy Express?

Перекладемо ці запитання запити мовою SQL (табл. 1).

Результатом будь-якого з наведених вище запитів є число. Якщо в першому із запитів замінити параметр 'France' на 'Austria' або назву іншої країни, можна знову виконати цей запит і отримати інше число. Виконавши цю процедуру з усіма країнами, ми отримаємо наступний набір даних (наведений нижче фрагмент):

Country	SUM (ExtendedPrice)
Argentina	7327.3
Austria	110788.4
Belgium	28491.65
Brazil	97407.74
Canada	46190.1
Denmark	28392.32
Finland	15296.35
Франція	69185.48
Німеччина	209373.6
…	…

Отриманий набір агрегатних значень (у разі - сум) може бути інтерпретований як одномірний набір даних. Цей же набір даних можна отримати в результаті запиту з пропозицією GROUP BY наступного виду:

SELECT Country, SUM (ExtendedPrice) FROM invoices1 GROUP BY Country

Тепер звернемося до другого з наведених вище запитів, який містить дві умови у пропозиції WHERE. Якщо виконувати цей запит, підставляючи у нього всі можливі значення параметрів Country та ShipperName, ми отримаємо двомірний набір даних наступного виду (нижче показаний фрагмент):

	ShipperName
Country	Federal Shipping	Speedy Express	United Package
Argentina	1 210.30	1 816.20	5 092.60
Austria	40 870.77	41 004.13	46 128.93
Belgium	11 393.30	4 717.56	17 713.99
Brazil	16 514.56	35 398.14	55 013.08
Canada	19 598.78	5 440.42	25 157.08
Denmark	18 295.30	6 573.97	7 791.74
Finland	4 889.84	5 966.21	7 954.00
Франція	28 737.23	21 140.18	31 480.90
Німеччина	53 474.88	94 847.12	81 962.58
…	…	…	…

Такий набір даних називається зведеною таблицею (pivot table) чи крос-таблицею (cross table, crosstab). Створювати подібні таблиці дозволяють багато електронних таблиць і настільних СУБД - від Paradox для DOS до Microsoft Excel 2000. Ось так, наприклад, виглядає подібний запит у Microsoft Access 2000:

TRANSFORM Sum(Invoices1.ExtendedPrice) AS SumOfExtendedPrice SELECT Invoices1.Country FROM Invoices1 GROUP BY Invoices1.Country PIVOT Invoices1.ShipperName;

Агрегатні дані для подібної зведеної таблиці можна отримати за допомогою звичайного запиту GROUP BY:

Зазначимо, що результатом цього запиту буде не сама зведена таблиця, а лише набір агрегатних даних для її побудови (нижче показаний фрагмент):

Country	ShipperName	SUM (ExtendedPrice)
Argentina	Federal Shipping	845.5
Austria	Federal Shipping	35696.78
Belgium	Federal Shipping	8747.3
Brazil	Federal Shipping	13998.26
…	…	…

Третій із розглянутих вище запитів має вже три параметри за умови WHERE. Варіюючи їх, ми отримаємо тривимірний набір даних (рис. 2).

Осередки куба, показаного на рис. 2 містять агрегатні дані, відповідні знаходяться на осях куба значенням параметрів запиту в пропозиції WHERE.

Можна отримати набір двомірних таблиць за допомогою перерізу куба площинами, паралельними його граням (для їх позначення використовують терміни cross-sections та slices).

Очевидно, що дані, що містяться в осередках куба, можна отримати за допомогою відповідного запиту з пропозицією GROUP BY. Крім того, деякі електронні таблиці (зокрема Microsoft Excel 2000) також дозволяють побудувати тривимірний набір даних і переглядати різні перерізи куба, паралельні його грані, зображеної на аркуші робочої книги (workbook).

Якщо WHERE містить чотири або більше параметрів, результуючий набір значень (також званий OLAP-кубом) може бути 4-мірним, 5-мірним і т.д.

Розглянувши, що є багатовимірними OLAP-куби, перейдемо до деяких ключових термінів і понять, що використовуються при багатовимірному аналізі даних.

Деякі терміни та поняття

Поряд із сумами в осередках OLAP-куба можуть міститися результати виконання інших агрегатних функцій мови SQL, таких як MIN, MAX, AVG, COUNT, а в деяких випадках – та інших (дисперсії, середньоквадратичного відхилення тощо). Для опису значень даних в осередках використовується термін summary (загалом у одному кубі їх може бути кілька), для позначення вихідних даних, на основі яких вони обчислюються, - термін measure, а для позначення параметрів запитів - термін dimension (перекладається російською мовою) зазвичай як «вимірювання», коли йдеться про OLAP-куби, і як «розмірність», коли йдеться про сховища даних). Значення, що відкладаються на осях, називаються членами вимірів (members).

Говорячи про виміри, слід згадати про те, що значення, що наносяться на осі, можуть мати різні рівні деталізації. Наприклад, нас може цікавити сумарна вартість замовлень, зроблених клієнтами у різних країнах, або сумарна вартість замовлень, зроблених іногородніми клієнтами чи навіть окремими клієнтами. Звичайно, результуючий набір агрегатних даних у другому та третьому випадках буде більш детальним, ніж у першому. Зауважимо, що можливість отримання агрегатних даних з різним ступенем деталізації відповідає одному з вимог, що висуваються до сховищ даних, - вимогу доступності різних зрізів даних для порівняння та аналізу.

Оскільки у розглянутому прикладі у випадку кожної країни може бути кілька міст, а місті - кілька клієнтів, можна говорити про ієрархії значень у вимірах. І тут першому рівні ієрархії розташовуються країни, другого - міста, але в третьому - клієнти (рис. 3).

Зазначимо, що ієрархії може бути збалансованими (balanced), як, наприклад, ієрархія, представлена ​​на рис. 3 , і навіть ієрархії, засновані на даних типу «дата-час», і незбалансованими (unbalanced). Типовий приклад незбалансованої ієрархії - ієрархія типу "начальник-підлеглий" (її можна побудувати, наприклад, використовуючи значення поля Salesperson вихідного набору даних із розглянутого вище прикладу), представлений на рис. 4 .

Іноді таких ієрархій використовується термін Parent-child hierarchy.

Існують також ієрархії, що займають проміжне положення між збалансованими та незбалансованими (вони позначаються терміном ragged – «нерівний»). Зазвичай вони містять такі члени, логічні «батьки» яких знаходяться не на безпосередньо вищому рівні (наприклад, у географічній ієрархії є рівні Country, City та State, але при цьому в наборі даних є країни, які не мають штатів чи регіонів між рівнями Country та City ;рис.5).

Зазначимо, що незбалансовані та «нерівні» ієрархії підтримуються далеко не всіма OLAP-засобами. Наприклад, у Microsoft Analysis Services 2000 підтримуються обидва типи ієрархії, а Microsoft OLAP Services 7.0 - лише збалансовані. Різним у різних OLAP-засобах може бути і кількість рівнів ієрархії, і максимально допустима кількість членів одного рівня, і максимально можлива кількість самих вимірювань.

Висновок

У цій статті ми ознайомились із основами OLAP. Ми дізналися наступне:

• Призначення сховищ даних – надання користувачам інформації для статистичного аналізу та прийняття управлінських рішень.
• Сховища даних повинні забезпечувати високу швидкість отримання даних, можливість отримання та порівняння так званих зрізів даних, а також несуперечність, повноту та достовірність даних.
• OLAP (On-Line Analytical Processing) є ключовим компонентом побудови та застосування сховищ даних. Ця технологія заснована на побудові багатовимірних наборів даних - OLAP-кубів, осі якого містять параметри, а комірки - агрегатні дані, що залежать від них.
• Програми з OLAP-функціональністю повинні надавати користувачеві результати аналізу за прийнятний час, здійснювати логічний та статистичний аналіз, підтримувати багатокористувацький доступ до даних, здійснювати багатовимірне концептуальне подання даних та мати можливість звертатися до будь-якої потрібної інформації.

Крім того, ми розглянули основні принципи логічної організації OLAP-кубів, а також дізналися основні терміни та поняття, що застосовуються під час багатовимірного аналізу. І нарешті, ми з'ясували, що є різними типами ієрархій у вимірах OLAP-кубів.

У наступній статті даного циклу ми розглянемо типову структуру сховищ даних, поговоримо про те, що є клієнтським та серверним OLAP, а також зупинимося на деяких технічних аспектах багатовимірного зберігання даних.

Комп'ютерПрес 4"2001

Основна різниця між фактами та інформацією полягає в тому, що дані ми отримуємо та приймаємо до уваги, а інформацію можемо використовувати з користю. Грубо кажучи, інформація – це проаналізовані та систематизовані дані. Завдяки вчасно отриманої інформації багатьом фірмам вдається вистояти як за умов фінансової кризи, і за найжорсткішої конкуренції. Мало збирати факти і мати всі необхідні дані. Потрібно ще вміти їх аналізувати. Для полегшення праці людей, покликаних приймати важливі рішення, були розроблені різні системи підтримки. Саме з цією метою були розроблені різні комплексні системи, що дозволяють аналізувати великі масиви різнорідних даних і перетворюють їх на інформацію, корисну для користувача бізнесу. Нова область бізнес-аналітики спрямована на підвищення управління процесами бізнес-систем шляхом використання сховищ даних та технологій.

Ринок інформаційних систем для бізнесу пропонує сьогодні різноманітний вибір рішень, які допомагають підприємству організувати управлінський облік, забезпечити оперативне управління виробництвом та збутом, здійснювати ефективну взаємодію із замовниками та постачальниками.

Окрему нішу над ринком бізнес-систем займають аналітичні програмні продукти, призначені підтримки прийняття рішень на стратегічному рівні управління підприємством. Головна відмінність таких інструментів від систем оперативного управління полягає в тому, що останні забезпечують управління підприємством у режимі функціонування, тобто виконання цілком певної виробничої програми, у той час як аналітичні системи стратегічного рівня допомагають керівництву підприємства виробляти рішення в режимі розвитку.

Масштаби проведених змін можуть бути різними від глибокої реструктуризації до часткового оновлення технологій на окремих виробничих ділянках, але, у будь-якому випадку, особи, які приймають рішення, розглядають альтернативи розвитку, від яких залежить доля підприємства в довгостроковій перспективі.

Якою б потужною та розвиненою не була інформаційна система підприємства, вона не може допомогти у вирішенні цих питань, по-перше, тому, що налаштована на стаціонарні, усталені бізнес-процеси, по-друге, у ній немає, і не може бути інформації для прийняття рішень щодо нових сфер бізнесу, нових технологій, нових організаційних рішень.

Завдяки технології обробки та аналізу даних OLAP (On-Line Analytical Processing) будь-яка організація може майже миттєво (протягом п'яти секунд) отримати необхідні для роботи дані. OLAP можна визначити коротко п'ятьма ключовими словами.

FAST (Швидкий) – це означає, що час пошуку та видачі необхідної інформації займає не більше п'яти секунд. Найпростіші запити обробляються за секунду, і лише деякі складні запити мають час обробки понад двадцять секунд. Щоб досягти такого результату, використовуються різні методи, від особливих форм зберігання даних до великих попередніх обчислень. Таким чином, ви можете за хвилину отримати звіт, на підготовку якого раніше були потрібні дні.

ANALYSIS (Аналітичний) говорить, що система може зробити будь-який аналіз, як статистичний, і логічний, і потім зберігає їх у доступному вигляді.

SHARED (Розділяється) означає, що система забезпечує необхідну конфіденційність, аж до рівня комірки

MULTIDIMENSIONAL (багатомірний) – є основною характеристикою OLAP. Система повинна повністю підтримувати ієрархії та численні ієрархії, оскільки саме таким чином логічніше вести аналіз і бізнесу, і діяльності організацій.

INFORMATION (Інформаційна). Потрібна інформація має бути доставлена ​​туди, де вона потрібна.

При роботі організації завжди накопичуються дані, пов'язані зі сферою її діяльності, які часом зберігаються в різних місцях, і звести їх воєдино і непросто, і довго. Саме для того, щоб прискорити отримання даних для перевірки бізнес-гіпотез, що виникають, і була розроблена технологія інтерактивної аналітичної обробки даних або OLAP. Основне призначення таких OLAP – систем – швидко відповідатиме на довільні запити користувачів. Така необхідність часто виникає при розробці якогось важливого бізнес-проекту, коли розробнику необхідна робоча гіпотеза. Найчастіше потрібна користувачеві інформація має бути представлена ​​як певної залежності – наприклад, як залежить обсяг продажу від категорії товару, від регіону продажів, від пори року тощо. Завдяки OLAP він має можливість одразу отримати необхідні дані в потрібній компонуванні за обраний період.

Інтерактивна технологія OLAP дозволяє перетворити величезні стоси звітів та масу даних у корисну та точну інформацію, яка у потрібний час допоможе працівникові прийняти обґрунтоване ділове чи фінансове рішення.

Крім цього, завдяки OLAP підвищується ефективність обробки, а більші обсяги відсортованої (агрегованої) інформації може отримати майже миттєво. Завдяки OLAP користувач може чітко бачити, наскільки ефективно працює його організація, має можливість швидко та гнучко реагувати на зовнішні зміни, може звести до мінімуму фінансові втрати своєї організації. OLAP надає точну інформацію, яка підвищує якість прийнятих рішень.

Єдиним недоліком систем бізнес-аналізу є їхня висока вартість. Створення персонального інформаційного сховища потребує часу і великих грошей.

Застосування OLAP – технології у бізнесі дозволяє оперативно отримати необхідну інформацію, яка, за бажанням користувача, може бути представлена ​​у звичному вигляді – звітів, графіків чи таблиць.

Процедури системної інтеграції бізнес-структур ґрунтуються на використанні спільних рішень ERP, CRM та SCM. У багатьох випадках системи поставляються різними виробниками, а дані, що імпортуються, повинні пройти процедуру узгодження даних і подання у вигляді гетерогенних даних. У середовищі бізнес передбачається однозначна вимога - повний аналіз даних, що передбачає перегляд консолідованих звітів з різних точок зору.

Різні виробники мають різні механізми представлення даних. Процедура гетерогенного подання передбачає вилучення, трансформування та завантаження (ETL). Наприклад, у Microsoft SQL Server 2005 Analysis Services проблема консолідації даних реалізована за допомогою Data Source Views – видів джерел даних, що описують аналітичні моделі уявлення.

Бізнес-додатки на основі OLAP технологій, приклади продуктів. Найчастіше зустрічаються такі застосування OLAP технологій:

Аналіз даних.

Завдання, для якого спочатку використовувалися і досі залишаються найпопулярнішими OLAP засоби. Багатомірна модель даних, можливість аналізувати значні обсяги даних та швидкий відгук на запити роблять подібні системи незамінними для аналізу продажів, маркетингових заходів, дистрибуції та інших завдань із великим обсягом вихідних даних.

Приклади продуктів: Microsoft Excel Pivot Tables, Microsoft Analysis Services, SAP BW, Oracle Essbase, OLAP Oracle, Cognos PowerPlay, MicroStrategy, Business Objects.

Фінансове планування-бюджетування.

Багатовимірна модель дозволяє одночасно вводити дані та легко аналізувати їх (наприклад, план факт аналіз). Тому ряд сучасних продуктів класу CPM (Corporate Performance Management) використовують OLAP% моделі. Важливим завданням є багатовимірний зворотний розрахунок (backsolve, breakback, writeback), що дозволяє розрахувати необхідні зміни детальних осередків при зміні агрегованого значення. Це інструмент аналізу «що-якщо» (what-if), тобто. для відтворення різних варіантів подій при плануванні.

Приклади продуктів: Microsoft PerformancePint, Oracle EPB, OFA, Oracle Hyperion Planning, SAP SEM, Cognos Enterprise Planning, Geac.

Фінансова консолідація.

Консолідація даних згідно з міжнародними стандартами обліку, беручи до уваги частки володіння, різні валюти та внутрішні обороти – актуальне завдання у зв'язку з вимогами контролюючих органів (SOX, Basel II), що посилюються, і виходом компаній на IPO. OLAP технології дозволяють прискорити розрахунок консолідованих звітів та підвищити прозорість всього процесу.

Приклади продуктів Oracle FCH, Oracle Hyperion FM, Cognos Controller.

Сховища даних та On-Line Analytical Processing (OLAP) технології
є важливими елементами підтримки прийняття бізнес-рішень, які все частіше стає невід'ємною частиною будь-якої галузі. Застосування OLAP технологій як інструмент для бізнес-аналітики дає більше контролю та своєчасного доступу до стратегічної.
інформації, що сприяє ефективному ухваленню рішень.
Це надає можливість для моделювання реальних прогнозів та ефективніше використання ресурсів. OLAP дозволяє організації оперативніше реагувати на вимоги ринку.

Список літератури:

1. Erik Thomsen. OLAP Solutions: Building Multidimensional Information Systems Second Edition. Wiley Computer Publishing John Wiley & Sons, Inc., 2002.

2. OLAP council white paper, http://www.olapcouncil.org/research/whtpaply.htm

3. Gerd Stumme та Bernhard Ganter. Formal Concept Analysis _ Mathematical Foundations.

Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче

Студенти, аспіранти, молоді вчені, які використовують базу знань у своєму навчанні та роботі, будуть вам дуже вдячні.

Розміщено на http://www.allbest.ru/

Курсова робота

з дисципліни: Бази даних

Тема: ТехнологіяOLAP

Виконав:

Чижиков Олександр Олександрович

Вступ

1. Класифікація OLAP-продуктів

2. OLAP-клієнт - OLAP-сервер: "за" та "проти"

3. Ядро системи OLAP

3.1 Принципи побудови

Висновок

Список використаних джерел

Програми

Уведення

Важко знайти в комп'ютерному світі людину, яка хоча б на інтуїтивному рівні не розуміла, що таке бази даних і навіщо вони потрібні. На відміну від традиційних реляційних СУБД, концепція OLAP не така широко відома, хоча загадковий термін "куби OLAP" чули, напевно, майже всі. Що таке OnLine Analytical Processing?

OLAP - це окремо взятий програмний продукт, не мова програмування і навіть конкретна технологія. Якщо постаратися охопити OLAP у всіх його проявах, це сукупність концепцій, принципів і вимог, які у основі програмних продуктів, полегшують аналітикам доступом до даних. Незважаючи на те, що з таким визначенням навряд чи хтось не погодиться, сумнівно, щоб воно хоч на йоту наблизило нефахівців до розуміння предмета. Тому у своєму прагненні до пізнання OLAP краще йти іншим шляхом. Для початку треба з'ясувати, навіщо аналітикам треба якось спеціально полегшувати доступ до даних.

Справа в тому, що аналітики – це особливі споживачі корпоративної інформації. Завдання аналітика – знаходити закономірності у великих масивах даних. Тому аналітик не звертатиме уваги на окремо взятий факт, йому потрібна інформація про сотні та тисячі подій. До речі, один із суттєвих моментів, що призвів до появи OLAP – продуктивність та ефективність. Уявімо, що відбувається, коли аналітику необхідно отримати інформацію, а кошти OLAP на підприємстві відсутні. Аналітик самостійно (що малоймовірно) або за допомогою програміста робить відповідний SQL-запит і отримує дані, що цікавлять, у вигляді звіту або експортує їх в електронну таблицю. Проблем при цьому виникає безліч. По-перше, аналітик змушений займатися не своєю роботою (SQL-програмуванням) або чекати, коли за нього завдання виконають програмісти - все це негативно позначається на продуктивності праці, підвищується інфарктно-інсультний рівень і таке інше. По-друге, один-єдиний звіт або таблиця, як правило, не рятує гігантів думки та батьків російського аналізу – і всю процедуру доведеться повторювати знову і знову. По-третє, як ми вже з'ясували, аналітики з дрібниць не питають - їм потрібно все й одразу. Це означає (хоча техніка і йде вперед семимильними кроками), що сервер корпоративної реляційної СУБД, до якого звертається аналітик, може замислитися глибоко та надовго, заблокувавши інші транзакції.

Концепція OLAP з'явилася саме для вирішення таких проблем. Куби OLAP є, по суті, мета-звіти. Розрізаючи мета-звіти (куби, тобто) за вимірами, аналітик отримує, фактично, цікаві його " звичайні " двовимірні звіти (це обов'язково звіти у звичайному розумінні цього терміна - йдеться про структури даних із такими самими функціями). Переваги кубів очевидні – дані необхідно запросити з реляційної СУБД лише один раз – при побудові куба. Оскільки аналітики, як правило, не працюють з інформацією, яка доповнюється та змінюється "на льоту", сформований куб є актуальним протягом досить тривалого часу. Завдяки цьому не лише виключаються перебої в роботі сервера реляційної СУБД (немає запитів з тисячами та мільйонами рядків відповідей), а й різко підвищується швидкість доступу до даних для самого аналітика. Крім того, як уже зазначалося, продуктивність підвищується за рахунок підрахунку проміжних сум ієрархій та інших агрегованих значень у момент побудови куба.

Звичайно, за підвищення у такий спосіб продуктивності треба платити. Іноді кажуть, що структура даних просто "вибухає" - куб OLAP може займати в десятки і навіть сотні разів більше місця, ніж вихідні дані.

Тепер, коли ми трохи розібралися в тому, як працює і для чого служить OLAP, варто все ж таки дещо формалізувати наші знання та дати критерії OLAP вже без синхронного перекладу на звичайну людську мову. Ці критерії (загалом числом 12) були сформульовані 1993 року Є.Ф. Коддім - творцем концепції реляційних СУБД та, за сумісництвом, OLAP. Безпосередньо їх ми розглядати не будемо, оскільки пізніше їх переробили на так званий тест FASMI, який визначає вимоги до продуктів OLAP. FASMI – це абревіатура від назви кожного пункту тесту:

Fast (швидкий).Ця властивість означає, що система повинна забезпечувати відповідь на запит користувача за п'ять секунд; при цьому більшість запитів обробляються в межах однієї секунди, а найскладніші запити повинні бути оброблені в межах двадцяти секунд. Останні дослідження показали, що користувач починає сумніватися в успішності запиту, якщо він займає більше тридцяти секунд.

Analysis (аналітичний).Система повинна справлятися з будь-яким логічним та статистичним аналізом, характерним для бізнес-додатків, та забезпечує збереження результатів у вигляді, доступному для кінцевого користувача. Кошти аналізу можуть включати процедури аналізу часових рядів, розподілу витрат, конверсії валют, моделювання змін організаційних структур та інших.

Shared (розділений).Система має надавати широкі можливості розмежування доступу до даних та одночасної роботи багатьох користувачів.

Multidimensional (багатомірний).Система повинна забезпечувати концептуально багатовимірне подання даних, включаючи повну підтримку багатьох ієрархій.

Information (інформація).Потужність різних програмних продуктів характеризується кількістю вхідних даних, що обробляються. Різні OLAP-системи мають різну потужність: передові OLAP-рішення можуть оперувати принаймні в тисячу разів великою кількістю даних у порівнянні з найменш потужними. При виборі OLAP-інструменту слід враховувати низку факторів, включаючи дублювання даних, необхідну оперативну пам'ять, використання дискового простору, експлуатаційні показники, інтеграцію з інформаційними сховищами тощо.

1. Класифікація OLAP-продуктів

Отже, суть OLAP полягає в тому, що вихідна для аналізу інформація подається у вигляді багатовимірного куба, і забезпечується можливість довільно маніпулювати нею та отримувати необхідні інформаційні розрізи – звіти. При цьому кінцевий користувач бачить куб як багатовимірну динамічну таблицю, яка автоматично підсумовує дані (факти) у різних розрізах (вимірюваннях), і дозволяє інтерактивно керувати обчисленнями та формою звіту. Виконання цих операцій забезпечується OLAP-машиною (або машиною OLAP-обчислень).

На сьогоднішній день у світі розроблено безліч продуктів, що реалізують OLAP технології. Щоб легше було орієнтуватись серед них, використовують класифікації OLAP-продуктів: за способом зберігання даних для аналізу та за місцем знаходження OLAP-машини. Розглянемо докладніше кожну категорію продуктів OLAP.

Почну з класифікації за способом зберігання даних. Нагадаю, що багатовимірні куби будуються на основі вихідних та агрегатних даних. І вихідні та агрегатні дані для кубів можуть зберігатися як у реляційних, так і багатовимірних базах даних. Тому в даний час застосовуються три способи зберігання даних: MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) та HOLAP (Hybrid OLAP). Відповідно, OLAP-продукти за способом зберігання даних поділяються на три аналогічні категорії:

1.У випадку MOLAP, вихідні та агрегатні дані зберігаються в багатовимірній БД або в багатовимірному локальному кубі.

2.В ROLAP-продуктах вихідні дані зберігаються в реляційних БД або плоских локальних таблицях на файл-сервері. Агрегатні дані можуть поміщатися у службові таблиці тієї ж БД. Перетворення даних з реляційної БД на багатовимірні куби відбувається за запитом OLAP-кошти.

3.У разі використання HOLAP архітектури вихідні дані залишаються в реляційній базі, а агрегати розміщуються у багатовимірній. Побудова OLAP-куба виконується на запит OLAP-засобу на основі реляційних та багатовимірних даних.

Наступна класифікація – за місцем розміщення OLAP-машини. За цією ознакою OLAP-продукти поділяються на OLAP-сервери та OLAP-клієнти:

У серверних OLAP-засобах обчислення та зберігання агрегатних даних виконуються окремим процесом – сервером. Клієнтська програма отримує лише результати запитів до багатовимірних кубів, які зберігаються на сервері. Деякі OLAP-сервери підтримують зберігання даних лише в реляційних базах, деякі лише в багатовимірних. Багато сучасних OLAP-серверів підтримують усі три способи зберігання даних: MOLAP, ROLAP та HOLAP.

OLAP-клієнт влаштований по-іншому. Побудова багатовимірного куба та OLAP-обчислення виконуються у пам'яті клієнтського комп'ютера. OLAP-клієнти також поділяються на ROLAP та MOLAP. А деякі можуть підтримувати обидва варіанти доступу до даних.

У кожного з цих підходів є свої "плюси" та "мінуси". Всупереч поширеній думці про переваги серверних засобів перед клієнтськими, в цілому ряді випадків застосування OLAP-клієнта для користувачів може виявитися ефективнішим та вигіднішим за використання OLAP-сервера.

2. OLAP-клієнт - OLAP-сервер: "за" та "проти"

При побудові інформаційної системи OLAP-функціональність можна реалізувати як серверними, і клієнтськими OLAP-средствами. На практиці вибір є результатом компромісу експлуатаційних показників та вартості програмного забезпечення.

Обсяг даних визначається сукупністю наступних характеристик: кількість записів, кількість вимірювань, кількість елементів вимірювання, довжина вимірювань та кількість фактів. Відомо, що OLAP-сервер може обробляти більші обсяги даних, ніж OLAP-клієнт за рівної потужності комп'ютера. Це тим, що OLAP-сервер зберігає на жорстких дисках багатовимірну базу даних, що містить заздалегідь обчислені куби.

Клієнтські програми в момент виконання OLAP-операцій виконують до неї запити SQL-подібною мовою, отримуючи не весь куб, а його фрагменти, що відображаються. OLAP-клієнт у момент роботи повинен мати в оперативній пам'яті весь куб. У разі ROLAP-архітектури, необхідно попередньо завантажити в пам'ять весь масив даних, що використовується для обчислення куба. Крім того, при збільшенні числа вимірювань, фактів або елементів вимірювання кількість агрегатів зростає в геометричній прогресії. Таким чином, обсяг даних, які обробляє OLAP-клієнт, знаходиться в прямій залежності від обсягу оперативної пам'яті ПК користувача.

Проте зауважимо, більшість OLAP-клієнтів забезпечують виконання розподілених обчислень. Тому під кількістю оброблюваних записів, що обмежує роботу клієнтського OLAP-кошти, розуміється не обсяг первинних даних корпоративної БД, а розмір агрегованої вибірки з неї. OLAP-клієнт генерує запит до СУБД, в якому описуються умови фільтрації та алгоритм попереднього угруповання первинних даних. Сервер знаходить, групує записи та повертає компактну вибірку для подальших обчислень OLAP. Розмір цієї вибірки може бути в десятки і сотні разів менший за обсяг первинних, не агрегованих записів. Отже, потреба такого OLAP-клієнта у ресурсах ПК суттєво знижується.

Крім того, кількість вимірювань накладає обмеження можливості людського сприйняття. Відомо, що середня людина може одночасно оперувати 3-4, максимум 8 вимірами. При більшій кількості вимірювань у динамічній таблиці сприйняття інформації суттєво не може. Цей фактор слід враховувати при попередньому розрахунку оперативної пам'яті, яка може бути потрібна OLAP-клієнту.

Довжина вимірювань також впливає розмір адресного простору OLAP-засобу, зайнятого при обчисленні OLAP-куба. Чим довше виміру, тим більше ресурсів потрібно для виконання попереднього сортування багатовимірного масиву, і навпаки. Тільки короткі виміри у вихідних даних - ще один аргумент на користь OLAP-клієнта.

Ця характеристика визначається двома розглянутими вище факторами: обсягом даних і потужністю комп'ютерів. При зростанні кількості, наприклад вимірювань, продуктивність всіх OLAP-засобів знижується за рахунок значного збільшення кількості агрегатів, але при цьому темпи зниження різні. Продемонструємо цю залежність на графіку.

Схема 1. Залежність продуктивності клієнтських та серверних OLAP-засобів від збільшення обсягу даних

Швидкісні характеристики сервера OLAP менш чутливі до зростання обсягу даних. Це пояснюється різними технологіями обробки запитів користувачів OLAP-сервером та OLAP-клієнтом. Наприклад, при операції деталізації OLAP-сервер звертається до даних, що зберігаються, і "витягує" дані цієї "гілки". OLAP-клієнт же обчислює весь набір агрегатів у момент завантаження. Однак до певного обсягу даних продуктивність серверних та клієнтських засобів є порівнянною. Для OLAP-клієнтів, що підтримують розподілені обчислення, область сумісності продуктивності може поширюватися на обсяги даних, що покривають потреби в OLAP-аналізі величезної кількості користувачів. Це підтверджують результати внутрішнього тестування MS OLAP Server та OLAP-клієнта "Контур Стандарт". Тест виконаний на ПК IBM PC Pentium Celeron 400 МГц, 256 Mb для вибірки в 1 мільйон унікальних (тобто агрегованих) записів із 7 вимірами, що містять від 10 до 70 членів. Час завантаження куба в обох випадках не перевищує 1 секунди, а виконання різних OLAP-операцій (drill up, drill down, move, filter та ін) виконується за соті частки секунди.

Коли обсяг вибірки перевищить обсяг оперативної пам'яті, починається обмін (swapping) з диском і продуктивність OLAP-клієнта різко падає. Тільки з цього моменту можна говорити про перевагу сервера OLAP.

Слід пам'ятати, що точка перелому визначає межу різкого подорожчання OLAP-рішення. Для кожного конкретного користувача ця точка легко визначається за тестами продуктивності OLAP-клієнта. Такі тести можна отримати у компанії-розробника.

Крім того, вартість серверного рішення OLAP зростає при збільшенні кількості користувачів. Справа в тому, що OLAP-сервер виконує обчислення для всіх користувачів на одному комп'ютері. Відповідно, чим більша кількість користувачів, тим більше оперативної пам'яті та процесорної потужності. Таким чином, якщо обсяги даних, що обробляються, лежать в області порівнянної продуктивності серверних і клієнтських систем, то за інших рівних умов, використання OLAP-клієнта буде вигідніше.

Використання OLAP-сервера в "класичній" ідеології передбачає розвантаження даних реляційних СУБД на багатовимірну БД. Вивантаження виконується за певний період, тому дані сервера OLAP не відображають стан на поточний момент. Цього недоліку позбавлені лише OLAP-сервери, які підтримують ROLAP-режим роботи.

Аналогічним чином, ціла низка OLAP-клієнтів дозволяє реалізувати ROLAP-і Desktop-архітектуру з прямим доступом до БД. Це забезпечує аналіз вихідних даних у режимі on-line.

OLAP-сервер надає мінімальні вимоги до потужності клієнтських терміналів. Об'єктивно, вимоги OLAP-клієнта вищі, т.к. він здійснює обчислення в оперативній пам'яті ПК користувача. Стан парку апаратних засобів конкретної організації - найважливіший показник, що має бути врахований під час виборів OLAP-средства. Але і тут є свої "плюси" та "мінуси". OLAP-сервер не використовує величезну обчислювальну потужність сучасних комп'ютерів. У випадку, якщо організація вже має парк сучасних ПК, неефективно застосовувати їх лише як термінали, що відображають, і в той же час робити додаткові витрати на центральний сервер.

Якщо потужність комп'ютерів користувачів "залишає бажати кращого", OLAP-клієнт працюватиме повільно або не зможе працювати зовсім. Купівля одного потужного сервера може виявитися дешевшою за модернізацію всіх ПК.

Тут корисно взяти до уваги тенденції у розвитку апаратного забезпечення. Оскільки обсяги даних для аналізу є практично константою, стабільне зростання потужності ПК буде призводити до розширення можливостей OLAP-клієнтів і витіснення ними OLAP-серверів в сегмент дуже великих баз даних.

При використанні OLAP-сервера через мережу на ПК клієнта передаються лише дані для відображення, тоді як OLAP-клієнт отримує весь обсяг даних первинної вибірки.

Тому там, де застосовується OLAP-клієнт, мережевий трафік буде вищим.

Але, при застосуванні OLAP-сервера операції користувача, наприклад, деталізація, породжують нові запити до багатовимірної бази, отже, нову передачу даних. Виконання OLAP-операцій OLAP-клієнтом проводиться в оперативній пам'яті і, відповідно, не викликає нових потоків даних в мережі.

Також слід зазначити, що сучасне мережне апаратне забезпечення забезпечує високий рівень пропускної спроможності.

Тому в переважній більшості випадків аналіз БД "середніх" розмірів за допомогою OLAP-клієнта не гальмуватиме роботу користувача.

Вартість OLAP-сервера досить висока. Сюди слід плюсувати вартість виділеного комп'ютера і постійні витрати на адміністрування багатовимірної бази. Крім того, впровадження та супровід OLAP-сервера вимагає від персоналу достатньо високої кваліфікації.

Вартість OLAP-клієнта на порядок нижча за вартість OLAP-сервера. Адміністрування та додаткового технічного обладнання під сервер не потрібні. До кваліфікації персоналу під час запровадження OLAP-клієнта високих вимог не пред'являється. OLAP-клієнт може бути впроваджений значно швидше за OLAP-сервер.

Розробка аналітичних додатків за допомогою клієнтських OLAP-засобів – процес швидкий і не вимагає спеціальної підготовки виконавця. Користувач, який знає фізичну реалізацію бази даних, може розробити аналітичну програму самостійно, без залучення ІТ-фахівця. При використанні OLAP-сервера необхідно вивчити дві різні системи, іноді від різних постачальників, - для створення кубів на сервері, і для розробки клієнтської програми. OLAP-клієнт надає єдиний візуальний інтерфейс для опису кубів і налаштування до них інтерфейсів користувача.

Розглянемо процес створення OLAP-додатка за допомогою клієнтського інструментального засобу.

Схема 2. Створення OLAP-додатку за допомогою ROLAP-засобу клієнта

Принцип роботи ROLAP-клієнтів – попередній опис семантичного шару, за яким ховається фізична структура вихідних даних. У цьому джерелами даних може бути: локальні таблиці, РСУБД. Список джерел даних, що підтримуються, визначається конкретним програмним продуктом. Після цього користувач може самостійно маніпулювати зрозумілими об'єктами в термінах предметної області для створення кубів і аналітичних інтерфейсів.

Принцип роботи клієнта OLAP-сервера інший. В OLAP-сервері під час створення кубів користувач маніпулює фізичними описами БД.

При цьому в самому кубі створюються описи користувача. Клієнт OLAP-сервера налаштовується лише на куб.

Пояснимо принцип роботи ROLAP-клієнта на прикладі створення динамічного звіту про продаж (див. схему 2). Нехай вихідні дані для аналізу зберігаються у двох таблицях: Sales та Deal.

При створенні семантичного шару джерела даних - таблиці Sales і Deal - описуються зрозумілими кінцевому користувачеві термінами і перетворюються на "Продукти" та "Угоди". Поле "ID" з таблиці "Продукти" перейменовується на "Код", а "Name" - на "Товар" тощо.

Потім створюється бізнес-об'єкт "Продаж". Бізнес-об'єкт – це плоска таблиця, на основі якої формується багатовимірний куб. При створенні бізнес-об'єкта таблиці "Продукти" та "Угоди" поєднуються по полю "Код" товару. Оскільки для відображення у звіті не потрібні всі поля таблиць - бізнес-об'єкт використовує лише поля "Товар", "Дата" та "Сума".

Далі на базі бізнес-об'єкта створюється OLAP-звіт. Користувач вибирає бізнес-об'єкт та перетягує його атрибути в області колонок або рядків таблиці звіту. У нашому прикладі на базі бізнес-об'єкта "Продажі" створено звіт із продажу товарів за місяцями.

Під час роботи з інтерактивним звітом користувач може задавати умови фільтрації та угруповання такими ж простими рухами "мишею". У цей момент ROLAP-клієнт звертається до даних у кеші. Клієнт OLAP-сервера генерує новий запит до багатовимірної бази даних. Наприклад, застосувавши у звіті про продаж фільтр по товарах, можна отримати звіт про продаж цікавих для нас товарів.

Усі настройки OLAP-програми можуть зберігатися у виділеному репозиторії метаданих, у додатку або в системному репозиторії багатовимірної бази даних. Реалізація залежить від програмного продукту.

Отже, в яких випадках застосування OLAP-клієнта для користувачів може виявитися ефективнішим та вигіднішим за використання OLAP-сервера?

Економічна доцільність застосування OLAP-сервера виникає, коли обсяги даних дуже великі та непосильні для OLAP-клієнта, інакше більш виправдане застосування останнього. У цьому випадку OLAP-клієнт поєднує у собі високі характеристики продуктивності та низьку вартість.

Потужні ПК аналітиків - ще один аргумент на користь OLAP-клієнтів. При застосуванні сервера OLAP ці потужності не використовуються. Серед переваг OLAP-клієнтів можна назвати таке:

Витрати на впровадження та супровід OLAP-клієнта істотно нижчі, ніж витрати на OLAP-сервер.

При використанні OLAP-клієнта з вбудованою машиною передача даних через мережу проводиться один раз. Під час виконання OLAP-операцій нових потоків даних не породжується.

Налаштування ROLAP-клієнтів спрощено за рахунок виключення проміжної ланки - створення багатовимірної бази.

3. Ядро системи OLAP

3.1 Принципи побудови

додаток клієнтський ядро ​​дані

З уже сказаного, ясно, що механізм OLAP є на сьогодні одним із популярних методів аналізу даних. Є два основні підходи до вирішення цього завдання. Перший називається Multidimensional OLAP (MOLAP) - реалізація механізму з допомогою багатовимірної бази даних за сервера, а другий Relational OLAP (ROLAP) - побудова кубів " на льоту " з урахуванням SQL запитів до реляційної СУБД. Кожен із цих підходів має свої плюси та мінуси. Їхній порівняльний аналіз виходить за рамки цієї роботи. Тут буде описано лише реалізацію ядра настільного ROLAP модуля.

Таке завдання виникло після застосування системи ROLAP, побудованої на основі компонентів Decision Cube, що входять до складу Borland Delphi. На жаль, використання цього набору компонентів показало низьку продуктивність великих обсягах даних. Гостроту цієї проблеми можна знизити, намагаючись відсікти якнайбільше даних перед подачею їх для побудови кубів. Але цього не завжди досить.

В Інтернеті та пресі можна знайти багато інформації про OLAP системи, але практично ніде не сказано про те, як це влаштовано всередині.

Схема роботи:

Загальну схему роботи настільної системи OLAP можна представити наступним чином:

Схема 3. Робота настільної системи OLAP

Алгоритм роботи наступний:

1.Отримання даних у вигляді плоскої таблиці або результату виконання запиту SQL.

2.Кешування даних та перетворення їх до багатовимірного куба.

3. Відображення побудованого куба за допомогою крос-таблиці або діаграми і т.п. У загальному випадку до одного куба може бути підключена довільна кількість відображень.

Розглянемо як така система може бути влаштована усередині. Почнемо ми це з того боку, який можна подивитися та помацати, тобто з відображень. Відображення, що використовуються в OLAP системах, найчастіше бувають двох видів – крос-таблиці та діаграми. Розглянемо крос-таблицю, яка є основним та найбільш поширеним способом відображення куба.

На наведеному нижче малюнку жовтим кольором відображені рядки і стовпці, що містять агреговані результати, світло-сірим кольором відзначені осередки, в які потрапляють факти і темно-сірим осередки, що містять дані розмірностей.

Таким чином, таблицю можна розділити на такі елементи, з якими ми і працюватимемо надалі:

Заповнюючи матрицю з фактами, ми маємо діяти так:

На підставі даних про вимірювання визначити координати елемента, що додається в матриці.

Визначити координати стовпців і рядків підсумків, на які впливає елемент, що додається.

Додати елемент у матрицю та відповідні стовпці та рядки підсумків.

При цьому потрібно відзначити те, що отримана матриця буде сильно розрідженою, чому її організація у вигляді двовимірного масиву (варіант, що лежить на поверхні) не тільки нераціональна, але, швидше за все, і неможлива у зв'язку з великою розмірністю цієї матриці, для зберігання якої не не вистачить жодного обсягу оперативної пам'яті. Наприклад, якщо наш куб містить інформацію про продаж за один рік, і якщо в ньому буде всього 3 виміри - Клієнти (250), Продукти (500) і Дата (365), то ми отримаємо матрицю фактів наступних розмірів: кількість елементів = 250 х 500 х 365 = 45 625 000. І це при тому, що заповнених елементів у матриці може бути лише кілька тисяч. Причому чим більше кількість вимірювань, тим більш розрідженою буде матриця.

Тому для роботи з цією матрицею потрібно застосувати спеціальні механізми роботи з розрідженими матрицями. Можливі різні варіанти організації розрідженої матриці. Вони досить добре описані в літературі з програмування, наприклад, у першому томі класичної книги "Мистецтво програмування" Дональда Кнута.

Розглянемо тепер, як можна визначити координати факту, знаючи відповідні виміри. Для цього докладніше розглянемо структуру заголовка:

При цьому можна легко знайти спосіб визначення номерів відповідного осередку та підсумків, у які він потрапляє. Тут можна запропонувати кілька підходів. Один з них – це використання дерева для пошуку відповідних осередків. Це дерево може бути збудовано при проході за вибіркою. Крім того, можна легко визначити аналітичну рекурентну формулу для обчислення необхідної координати.

Дані, що зберігаються в таблиці, необхідно перетворити для їх використання. Так, з метою підвищення продуктивності при побудові гіперкуба, бажано знаходити унікальні елементи, що зберігаються в стовпцях, що є вимірами куба. Крім того, можна проводити попереднє агрегування фактів для записів, що мають однакові значення розмірності. Як було зазначено вище, нам важливі унікальні значення, що у полях вимірів. Тоді для їх зберігання можна запропонувати таку структуру:

Схема 4. Структура збереження унікальних значень

При використанні такої структури ми значно знижуємо потребу пам'яті. Що досить актуально, т.к. Для збільшення швидкості роботи бажано зберігати дані в оперативній пам'яті. Крім того, зберігати можна лише масив елементів, а їх значення вивантажувати на диск, так як вони будуть нам потрібні лише при виведенні крос-таблиці.

Описані вище ідеї були покладені в основу створення бібліотеки компонентів CubeBase.

Схема 5. Структура бібліотеки компонентів CubeBase

TСubeSource здійснює кешування та перетворення даних у внутрішній формат, а також попереднє агрегування даних. Компонент TСubeEngine здійснює обчислення гіперкуба та операції з ним. Фактично він є OLAP-машиною, що здійснює перетворення плоскої таблиці в багатовимірний набір даних. Компонент TCubeGrid виконує виведення на екран крос-таблиці та керування відображенням гіперкуба. TСubeChart дозволяє побачити гіперкуб у вигляді графіків, а компонент TСubePivote керує роботою ядра куба.

Отже, мною було розглянуто архітектуру та взаємодію компонентів, які можуть бути використані для побудови OLAP машини. Тепер розглянемо докладніше внутрішній пристрій компонентів.

Першим етапом роботи системи буде завантаження даних та перетворення їх у внутрішній формат. Закономірним буде питання - а навіщо це треба, адже можна просто використовувати дані із плоскої таблиці, переглядаючи її при побудові зрізу куба. Щоб відповісти це питання, розглянемо структуру таблиці з погляду OLAP машини. Для OLAP системи колонки таблиці можуть бути фактами, або вимірами. При цьому логіка роботи з цими колонками буде різною. У гіперкубі виміри фактично є осями, а значення вимірів - координатами цих осях. При цьому куб буде заповнений сильно нерівномірно - будуть поєднання координат, яким не відповідатимуть жодні записи та будуть поєднання, яким відповідає кілька записів у вихідній таблиці, причому перша ситуація зустрічається частіше, тобто куб буде схожий на всесвіт - порожній простір, в окремих місцях якого зустрічаються скупчення точок (фактів). Таким чином, якщо ми при початковому завантаженні даних зробимо переагрегування даних, тобто об'єднаємо записи, які мають однакові значення вимірювань, розрахувавши при цьому попередні агреговані значення фактів, то надалі нам доведеться працювати з меншою кількістю записів, що підвищить швидкість роботи та зменшить вимоги до обсягу оперативної пам'яті.

Для побудови зрізів гіперкуба нам потрібні такі можливості - визначення координат (фактично значення вимірів) для записів таблиці, і навіть визначення записів, мають конкретні координати (значення вимірів). Розглянемо як можна реалізувати ці можливості. Для зберігання гіперкуба найпростіше використовувати базу даних свого внутрішнього формату.

Схематично перетворення можна представити так:

Схема 6. Перетворення бази даних внутрішнього формату на нормалізовану базу даних

Тобто, замість однієї таблиці ми отримали нормалізовану базу даних. Взагалі нормалізація знижує швидкість роботи системи, - можуть сказати фахівці з баз даних, і в цьому вони будуть безумовно праві, у разі коли нам треба отримати значення для елементів словників (у нашому випадку значення вимірювань). Але справа в тому, що нам ці значення на етапі побудови зрізу взагалі не потрібні. Як було зазначено вище, нас цікавлять лише координати у нашому гіперкубі, тому визначимо координати для значень вимірів. Найпростішим буде перенумерувати значення елементів. Для того, щоб у межах одного виміру нумерація була однозначною, попередньо відсортуємо списки значень вимірів (словники, висловлюючись термінами БД) в алфавітному порядку. Крім того, перенумеруємо і факти, причому факти переагреговані. Отримаємо таку схему:

Схема 7. Перенумерація нормалізованої БД визначення координат значень вимірювань

Тепер залишилося лише зв'язати елементи різних таблиць між собою. Теоретично реляційних баз даних здійснюється з допомогою спеціальних проміжних таблиць. Нам достатньо кожного запису в таблицях вимірювань поставити у відповідність список, елементами якого будуть номери фактів, при формуванні яких використовувалися ці вимірювання (тобто визначити всі факти, що мають однакове значення координати, що описується цим виміром). Для фактів відповідно до кожного запису поставимо у відповідність значення координат, за якими вона розташована в гіперкубі. Надалі скрізь під координатами запису гіперкубі будуть розумітися номери відповідних записів у таблицях значень вимірювань. Тоді для нашого гіпотетичного прикладу отримаємо наступний набір, що визначає внутрішнє уявлення гіперкуба:

Схема 8. Внутрішнє уявлення гіперкуба

Таке буде у нас внутрішнє уявлення гіперкуба. Так як ми робимо його не для реляційної бази даних, то як поля зв'язку значень вимірювань використовуються просто поля змінної довжини (в РБД таке зробити ми б не змогли, так як там кількість колонок таблиці визначено заздалегідь).

Можна було б спробувати використовувати для реалізації гіперкуба набір часових таблиць, але цей метод забезпечить дуже низьку швидкодію (приклад - набір компонентів Decision Cube), тому будемо використовувати свої структури зберігання даних.

Для реалізації гіперкубу нам необхідно використовувати структури даних, які забезпечать максимальну швидкодію та мінімальні витрати оперативної пам'яті. Очевидно, що основними у нас будуть структури для зберігання словників та таблиці фактів. Розглянемо завдання, які має виконувати словник із максимальною швидкістю:

перевірка наявності елемента у словнику;

додавання елемента до словника;

пошук номерів записів, що мають конкретне значення координати;

пошук координати за значенням виміру;

пошук значення виміру за його координатою.

Для реалізації цих вимог можна використовувати різні типи та структури даних. Наприклад, можна використовувати масиви структур. У реальному випадку до цих масивів необхідні додаткові механізми індексації, які дозволять підвищити швидкість завантаження даних та отримання інформації.

Для оптимізації роботи гіперкуба необхідно визначити те, які завдання необхідно вирішувати в першочерговому порядку, і за якими критеріями треба домагатися підвищення якості роботи. Головним для нас є підвищення швидкості роботи програми, при цьому бажано, щоб був потрібний невеликий обсяг оперативної пам'яті. Підвищення швидкодії можливе за рахунок запровадження додаткових механізмів доступу до даних, наприклад, запровадження індексування. На жаль, це збільшує накладні витрати оперативної пам'яті. Тому визначимо які операції нам необхідно виконувати з найбільшою швидкістю. І тому розглянемо окремі компоненти, реалізують гиперкуб. Ці компоненти мають два основні типи - вимірювання та таблиця фактів. Для вимірювання типовим завданням буде:

додавання нового значення;

визначення координати за значенням виміру;

визначення значення координати.

При додаванні нового значення елемента нам необхідно перевірити, чи є ми вже таке значення, і якщо є, то не додавати нове, а використовувати наявну координату, інакше необхідно додати новий елемент і визначити його координату. Для цього необхідний спосіб швидкого пошуку наявності потрібного елемента (крім того, таке завдання виникає і при визначенні координати значення елемента). Для цього оптимальним буде використання хешування. При цьому оптимальною структурою буде використання хеш-дерев, у яких зберігатимемо посилання на елементи. При цьому елементами будуть рядки словника виміру. Тоді структуру значення виміру можна представити так:

PFactLink = ^TFactLink;

TFactLink = record

FactNo: integer; // Індекс факту в таблиці

TDimensionRecord = record

Value: string; // Значення виміру

Index: integer; // значення координати

FactLink: PFactLink; // покажчик початку списку елементів таблиці фактів

І в хеш-дереві зберігатимемо посилання на унікальні елементи. Крім того, нам необхідно вирішити задачу зворотного перетворення – по координаті визначити значення виміру. Для забезпечення максимальної продуктивності слід використовувати пряму адресацію. Тому можна використовувати ще один масив, індекс у якому є координатою вимірювання, а значення – посилання на відповідний запис у словнику. Однак можна вчинити простіше (і заощадити при цьому на пам'яті), якщо відповідним чином упорядкувати масив елементів так, щоб індекс елемента був його координатою.

Організація ж масиву, що реалізує список фактів, не становить особливих проблем через його просту структуру. Єдине зауваження буде таке, що бажано розраховувати всі способи агрегації, які можуть знадобитися і які можна розраховувати інкрементно (наприклад, сума).

Отже, ми описали спосіб зберігання даних як гіперкуба. Він дозволяє сформувати набір точок у багатовимірному просторі на основі інформації, що знаходиться у сховищі даних. Для того, щоб людина могла мати можливість роботи з цими даними, їх необхідно подати у вигляді, зручному для обробки. При цьому як основні види подання даних використовуються зведена таблиця та графіки. Причому обидва ці способи фактично є проекції гіперкуба. Для того, щоб забезпечити максимальну ефективність при побудові уявлень, відштовхуватимемося від того, що являють собою ці проекції. Почнемо розгляд зі зведеної таблиці, як із найважливішою для аналізу даних.

Знайдемо способи реалізації такої структури. Можна виділити три частини, з яких складається зведена таблиця: це заголовки рядків, заголовки стовпців і таблиця агрегованих значень фактів. Найпростішим способом представлення таблиці фактів буде використання двовимірного масиву, розмірність якого можна визначити, побудувавши заголовки. На жаль, найпростіший спосіб буде найнеефективнішим, тому що таблиця буде сильно розрідженою, і пам'ять витрачатиметься вкрай неефективно, внаслідок чого можна буде будувати лише дуже малі куби, оскільки пам'яті інакше може не вистачити. Таким чином, нам необхідно підібрати для зберігання інформації таку структуру даних, яка забезпечить максимальну швидкість пошуку/додавання нового елемента та водночас мінімальну витрату оперативної пам'яті. Цією структурою будуть так звані розріджені матриці, про які докладніше можна прочитати у Кнута. Можливі різні методи організації матриці. Для того, щоб вибрати відповідний нам варіант, розглянемо спочатку структуру заголовків таблиці.

Заголовки мають чітку ієрархічну структуру, тому природно буде припустити їх зберігання використовувати дерево. При цьому схематично структуру вузла дерева можна зобразити так:

Додаток С

При цьому значення вимірювання логічно зберігати посилання на відповідний елемент таблиці вимірювань багатовимірного куба. Це дозволить скоротити витрати пам'яті для зберігання зрізу та прискорити роботу. Як батьківські та дочірні вузли також використовуються посилання.

Для додавання елемента в дерево необхідно мати інформацію про його місцезнаходження в гіперкубі. Як таку інформацію треба використовувати його координату, яка зберігається у словнику значень виміру. Розглянемо схему додавання елемента дерево заголовків зведеної таблиці. При цьому як вихідну інформацію використовуємо значення координат вимірювань. Порядок, у якому ці виміри перераховані, визначається необхідним способом агрегування та збігається з рівнями ієрархії дерева заголовків. В результаті роботи необхідно отримати список стовпців або рядків зведеної таблиці, які необхідно здійснити додавання елемента.

додатокD

Як вихідні дані визначення цієї структури використовуємо координати вимірів. Крім того, для визначеності, будемо вважати, що ми визначаємо стовпець, що цікавить нас, в матриці (як будемо визначати рядок розглянемо трохи пізніше, так як там зручніше застосовувати інші структури даних, причина такого вибору також див. нижче). Як координати візьмемо цілі числа - номери значень вимірювань, які можна визначити так, як описано вище.

Отже, після виконання цієї процедури отримаємо масив посилань на стовпці розрідженої матриці. Тепер необхідно виконати всі дії з рядками. Для цього всередині кожного стовпця необхідно знайти потрібний елемент та додати туди відповідне значення. Для кожного з вимірів у колекції необхідно знати кількість унікальних значень та власне набір цих значень.

Тепер розглянемо, у якому вигляді необхідно уявити значення всередині стовпців - тобто як визначити потрібний рядок. Для цього можна використати декілька підходів. Найпростішим було б уявити кожен стовпець у вигляді вектора, але оскільки він буде сильно розрідженим, то пам'ять витрачатиметься вкрай неефективно. Щоб уникнути цього, застосуємо структури даних, які забезпечать більшу ефективність представлення розріджених одновимірних масивів (векторів). Найпростішим буде звичайний список, одно- чи двозв'язковий, проте він неекономічний з погляду доступу до елементів. Тому використовуватимемо дерево, яке забезпечить швидший доступ до елементів.

Наприклад, можна використовувати таке саме дерево, як і для стовпців, але тоді довелося б для кожного стовпця заводити своє власне дерево, що призведе до значних накладних витрат пам'яті та часу обробки. Вчинимо трохи хитрішим - заведемо одне дерево для зберігання всіх вимірювань, що використовуються в рядках комбінацій, яке буде ідентично вищеописаному, але його елементами будуть не вказівники на рядки (яких немає як таких), а їх індекси, причому самі значення індексів нас не цікавлять і використовуються тільки як унікальні ключі Потім ці ключі використовуватимемо для пошуку потрібного елемента всередині стовпця. Самі ж стовпці найпростіше уявити як звичайного двійкового дерева. Графічно отриману структуру можна представити так:

Схема 9. Зображення зведеної таблиці як двійкового дерева

Для визначення відповідних номерів рядків можна використовувати таку саму процедуру, як і описана вище процедура визначення стовпців зведеної таблиці. При цьому номери рядків є унікальними в межах однієї зведеної таблиці та ідентифікують елементи векторів, що є стовпцями зведеної таблиці. Найбільш простим варіантом генерації цих номерів буде ведення лічильника та інкремент його на одиницю при додаванні нового елемента до дерева заголовків рядків. Самі ці вектори стовпців найпростіше зберігати у вигляді двійкових дерев, де як ключ використовується значення номера рядка. Крім того, можливе також використання хеш-таблиць. Так як процедури роботи з цими деревами детально розглянуті в інших джерелах, зупинятися на цьому не будемо і розглянемо загальну схему додавання елемента в стовпець.

У узагальненому вигляді послідовність дій додавання елемента в матрицю можна описати так:

1.Визначити номери рядків, до яких додаються елементи

2.Визначити набір стовпців, до яких додаються елементи

3.Для всіх стовпців знайти елементи з потрібними номерами рядків і додати до них поточний елемент (додавання включає в себе приєднання потрібної кількості значень фактів та обчислення агрегованих значень, які можна визначити інкрементально).

Після виконання цього алгоритму отримаємо матрицю, що є зведеною таблицею, яку нам було необхідно побудувати.

Тепер кілька слів про фільтрацію при побудові зрізу. Найпростіше її здійснити якраз на етапі побудови матриці, тому що на цьому етапі є доступ до всіх необхідних полів і, крім того, здійснюється агрегація значень. При цьому, під час отримання запису з кешу, перевіряється її відповідність умовам фільтрації, і у разі недотримання запису відкидається.

Оскільки описана вище структура повністю описує зведену таблицю, завдання її візуалізації буде тривіальна. При цьому можна використовувати стандартні компоненти таблиці, які є практично у всіх програмних засобах під Windows.

Першим продуктом, що виконує запити OLAP, був Express (компанія IRI). Проте, сам термін OLAP було запропоновано Едгаром Коддом, «батьком реляційних БД». А робота Кодда фінансувалася Arbor, компанією, що випустила свій власний OLAP-продукт – Essbase (пізніше куплений Hyperion, яка у 2007 р. була поглинена компанією Oracle) – роком раніше. Інші добре відомі OLAP продукти включають Microsoft Analysis Services (раніше називалися OLAP Services, частина SQL Server), Oracle OLAP Option, DB2 OLAP Server від IBM (фактично, EssBase з доповненнями від IBM), SAP BW, продукти Brio, BusinessObjects, Cognos, MicroStrategy та інших виробників.

З технічної точки зору, представлені на ринку продукти поділяються на "фізичний OLAP" та "віртуальний". У першому випадку є програма, що виконує попередній розрахунок агрегатів, які потім зберігаються в спеціальну багатовимірну БД, що забезпечує швидке вилучення. Прикладами таких продуктів є Microsoft Analysis Services, Oracle OLAP Option, Oracle/Hyperion EssBase, Cognos PowerPlay. У другому випадку дані зберігаються в реляційних СУБД, а агрегати можуть не існувати взагалі або створюватися на перший запит у СУБД або кеші аналітичного ПЗ. Приклади таких продуктів – SAP BW, BusinessObjects, Microstrategy. Системи, що мають у своїй основі "фізичний OLAP", забезпечують стабільно кращий час відгуку на запити, ніж системи "віртуальний OLAP". Постачальники систем "віртуальний OLAP" заявляють про більшу масштабованість їх продуктів щодо підтримки дуже великих обсягів даних.

У цій роботі мені хотілося б детальніше розглянути продукт компанії BaseGroup Labs – Deductor.

Deductor є аналітичною платформою, тобто. основою створення закінчених прикладних рішень. Реалізовані в Deductor технології дозволяють на основі єдиної архітектури пройти всі етапи побудови аналітичної системи: від створення сховища даних до автоматичного підбору моделей та візуалізації отриманих результатів.

Склад системи:

Deductor Studio – аналітичне ядро ​​платформи Deductor. У Deductor Studio включений повний набір механізмів, що дозволяє отримати інформацію з довільного джерела даних, провести весь цикл обробки (очищення, трансформація даних, побудова моделей), відобразити отримані результати найзручнішим чином (OLAP, таблиці, діаграми, дерева рішень...) та експортувати результати.

Deductor Viewer є робочим місцем для кінцевого користувача. Програма дозволяє мінімізувати вимоги до персоналу, т.к. всі необхідні операції виконуються автоматично за допомогою підготовлених раніше сценаріїв обробки, немає необхідності замислюватися про спосіб отримання даних та механізми їх обробки. Користувачеві Deduсtor Viewer необхідно тільки вибрати звіт, що цікавить.

Deductor Warehouse - багатовимірне крос-платформне сховище даних, що акумулює всю необхідну для аналізу предметної галузі інформацію. Використання єдиного сховища дозволяє забезпечити зручний доступ, високу швидкість обробки, несуперечність інформації, централізоване зберігання та автоматичну підтримку всього аналізу даних.

4. Client-Server

Deductor Server призначений для віддаленої аналітичної обробки. Він надає можливість автоматично "проганяти" дані через існуючі сценарії на сервері, так і перенавчати наявні моделі. Використання Deductor Server дозволяє реалізувати повноцінну триланкову архітектуру, де він виконує функцію сервера додатків. Доступ до сервера забезпечується за допомогою Deductor Client.

Принципи роботи:

1. Імпорт даних

Аналіз будь-якої інформації в Deductor починається з імпорту даних. В результаті імпорту дані наводяться до виду, придатного для подальшого аналізу за допомогою всіх механізмів, що є в програмі. Природа даних, формат, СУБД та інше немає значення, т.к. механізми роботи з усіма уніфіковані.

2. Експорт даних

Наявність механізмів експорту дозволяє пересилати отримані результати до сторонніх додатків, наприклад, передавати прогноз продажу до системи для формування замовлення на поставку або розмістити підготовлений звіт на корпоративному веб-сайті.

3. Обробка даних

Під обробкою в Deductor мається на увазі будь-яка дія, пов'язана з деяким перетворенням даних, наприклад, фільтрація, побудова моделі, очищення та інше. Власне, у цьому блоці і виробляються найважливіші з погляду аналізу дії. Найбільш істотною особливістю механізмів обробки, реалізованих Deductor, є те, що отримані в результаті обробки дані можна знову обробляти будь-яким з доступних системі методів. Таким чином, можна будувати як завгодно складні сценарії обробки.

4. Візуалізація

Візуалізувати дані в Deductor Studio (Viewer) можна будь-якому етапі обробки. Система самостійно визначає, яким способом вона може це зробити, наприклад, якщо буде навчена нейронна мережа, крім таблиць і діаграм, можна переглянути граф нейромережі. Користувачеві необхідно вибрати потрібний варіант зі списку та налаштувати кілька параметрів.

5. Механізми інтеграції

У Deductor не передбачено засобів введення даних – платформа орієнтована виключно на аналітичну обробку. Для використання інформації, що зберігається у різнорідних системах, передбачено гнучкі механізми імпорту-експорту. Взаємодія може бути організована за допомогою пакетного виконання, роботи в режимі OLE сервера та звернення до Deductor Server.

6. Тиражування знань

Deductor дозволяє реалізувати одну з найважливіших функцій будь-якої аналітичної системи - підтримку процесу тиражування знань, тобто. забезпечення можливості співробітникам, які не знаються на методиках аналізу та способах отримання того чи іншого результату, отримувати відповідь на основі моделей підготовлених експертом.

Звиключення

У цій роботі було розглянуто таку галузь сучасних інформаційних технологій, як системи аналізу даних. Проаналізовано основний інструмент аналітичної обробки інформації – OLAP – технології. Докладно розкрито суть поняття OLAP та значення OLAP-систем у сучасному бізнес-процесі. Детально описано структуру та процес роботи ROLAP-сервера. Як приклад реалізації даних OLAP - технологій наведено аналітичну платформу Deductor. Подана документація розроблена та відповідає вимогам.

OLAP-технології – це потужний інструмент обробки даних у реальному часі. OLAP-сервер дозволяє організовувати та подавати дані в розрізі різних аналітичних напрямків та перетворює дані на цінну інформацію, яка допомагає компаніям приймати більш обґрунтовані рішення.

Використання OLAP-систем забезпечує стабільно високий рівень продуктивності та масштабованості, підтримуючи обсяги даних розміром у кілька гігабайт, доступ до яких можуть отримати тисячі користувачів. З допомогою OLAP-технологий доступом до інформації здійснюється у часі, тобто. обробка запитів тепер не уповільнює процес аналізу, забезпечуючи його оперативність та ефективність. Візуальні інструменти адміністрування дозволяють розробляти та впроваджувати навіть найскладніші аналітичні програми, роблячи цей процес простим та швидким.

Подібні документи

Основа концепції OLAP (On-Line Analytical Processing) – оперативна аналітична обробка даних, особливості її використання на клієнті та на сервері. Загальна характеристика основних вимог до OLAP-систем, а також способів зберігання даних у них.

реферат, доданий 12.10.2010


OLAP: загальна характеристика, призначення, цілі, завдання. Класифікація OLAP продуктів. Принципи побудови системи OLAP, бібліотека компонентів CubeBase. Залежність продуктивності клієнтських та серверних OLAP-коштів від збільшення обсягу даних.

курсова робота , доданий 25.12.2013


Вічне зберігання даних. Сутність та значення засобу OLAP (On-line Analytical Processing). Бази та сховища даних, їх характеристика. Структура, архітектура зберігання даних, постачальники. Декілька порад щодо підвищення продуктивності OLAP-кубів.

контрольна робота , доданий 23.10.2010


Побудова систем аналізу даних. Побудова алгоритмів проектування OLAP-куба та створення запитів до зведеної таблиці. OLAP-технологія багатовимірного аналізу даних. Забезпечення користувачів інформацією для ухвалення управлінських рішень.

курсова робота , доданий 19.09.2008


Основні відомості про OLAP. Оперативна аналітична обробка даних. Класифікація продуктів OLAP Вимоги до засобів оперативної аналітичної обробки. Використання багатовимірних БД у системах оперативної аналітичної обробки, їх переваги.

курсова робота , доданий 10.06.2011


Розробка підсистем аналізу веб-сайту за допомогою Microsoft Access та Olap-технологій. Теоретичні аспекти розробки системи аналізу даних в інформаційній системі музичного порталу. Olap-технології у підсистемі аналізу об'єкта дослідження.

курсова робота , доданий 06.11.2009


Розгляд OLAP-засобів: класифікація вітрин та сховищ інформації, поняття куба даних. Архітектура системи підтримки ухвалення рішень. Програмна реалізація системи "Abitura". Створення Web-звіту за допомогою технологій Reporting Services.

курсова робота , доданий 05.12.2012


Сховище даних, принципи організації. Процеси роботи із даними. OLAP структура, технічні аспекти багатовимірного зберігання даних. Integration Services, заповнення сховищ та вітрин даних. Можливості систем із використанням технологій Microsoft.

курсова робота , доданий 05.12.2012


Побудова схеми сховища даних торговельного підприємства. Опис схем відносин сховища. Відображення інформації про товар. Створення OLAP-куба для подальшого аналізу інформації. Розробка запитів, що дають змогу оцінити ефективність роботи супермаркету.

контрольна робота , доданий 19.12.2015


Призначення сховищ даних. Архітектура SAP BW. Побудова аналітичної звітності на основі OLAP-кубів у системі SAP BW. Основні відмінності між сховищем даних та системою OLTP. Огляд функціональних галузей BEx. Створення запиту у BEx Query Designer.

Мета доповіді

У цій доповіді йтиметься про одну з категорій інтелектуальних технологій, які є зручним аналітичним інструментом – OLAP-технологіями.

Мета доповіді: розкрити та висвітлити 2 питання: 1) поняття OLAP та їх прикладне значення у фінансовому управлінні; 2) реалізація OLAP-функціональності у програмних рішеннях: відмінності, можливості, переваги, недоліки.

Відразу хочу відзначити, що OLAP – це універсальний інструмент, який може бути використаний у будь-якій прикладній галузі, а не лише у фінансах (як це може бути зрозуміло з назви доповіді), що потребує аналізу даних різними методами.

Управління фінансами

Управління фінансами - область, в якій як ні в якій іншій важливий аналіз. Будь-яке фінансово-управлінське рішення виникає як результат певних аналітичних процедур. Сьогодні управління фінансами набуває значної ролі для успішного функціонування підприємства. Незважаючи на те, що фінансовий менеджмент є допоміжним процесом на підприємстві, він потребує особливої ​​уваги, оскільки помилкові фінансово-управлінські рішення можуть призвести до великих втрат.

Управління фінансами спрямоване на забезпечення підприємства фінансовими ресурсами у необхідних обсягах, у потрібний час та у потрібному місці з метою отримання максимального ефекту від їх використання шляхом оптимального розподілу.

Мабуть, важко визначити рівень максимальної ефективності використання ресурсів, але в будь-якому випадку,

Фінансовий директор завжди повинен знати:

• скільки фінансових ресурсів є?
• звідки надходитимуть кошти та в яких обсягах?
• куди вкладати ефективніше і чому?
• і в які моменти часу все це потрібно робити?
• скільки потрібно забезпечення нормальної діяльності підприємства?

Щоб отримувати обґрунтовані відповіді на ці питання необхідно мати, аналізувати та знати як аналізувати досить велику кількість показників діяльності. Крім того, ФУ охоплює величезну кількість областей: аналіз грошових потоків (руху коштів), аналіз активів та пасивів, аналіз прибутковості, маржинальний аналіз, аналіз рентабельності, асортиментний аналіз.

Знання

Тому ключовим фактором ефективності процесу управління фінансами є наявність знань:

• Особисті знання у предметній галузі (можна сказати теоретико-методологічні), включаючи досвід, інтуїцію фінансиста/фінансового директора
• Загальні (корпоративні) знання або систематизована інформація про факти здійснення фінансових операцій на підприємстві (тобто інформація про минулий, сучасний та майбутній стан підприємства, представлена ​​в різних показниках та вимірах)

Якщо перше лежить у сфері дій цього фінансиста (або директора з персоналу, який наймав цього працівника), то друге має цілеспрямовано створюватись на підприємстві спільними зусиллями працівників фінансових та інформаційних служб.

Що є зараз

Однак зараз на підприємствах типова парадоксальна ситуація: інформація є, її дуже багато, надто багато. Але вона перебуває у хаотичному стані: неструктурована, неузгоджена, розрізнена, не завжди достовірна та часто помилкова, її практично неможливо знайти та отримати. Проводиться тривала і найчастіше марна генерація гір фінансової звітності, яка незручна фінансового аналізу, важка сприйняття, оскільки створюється задля внутрішнього управління, а надання зовнішнім контролюючим органам.

За результатами дослідження, проведеного фірмою ReutersСеред 1300 міжнародних менеджерів, 38% опитаних стверджують, що витрачають багато часу, намагаючись знайти потрібну інформацію. Виходить, що висококваліфікований фахівець витрачає високооплачуване час не так на аналіз даних, але в збір, пошук і систематизацію необхідної цього аналізу інформації. У той же час менеджери зазнають важкого завантаження даними, які часто не мають жодного відношення до справи, що знову-таки знижує ефективність їх роботи. Причина такої ситуації: надлишок інформації та брак знань.

Що треба робити

Інформація має перетворюватися на знання. Для сучасного бізнесу цінна інформація, її систематичне придбання, синтез, обмін, використання – це свого роду валюта, але для того, щоб її отримувати, необхідно керувати інформацією, як будь-яким бізнес-процесом.

Ключем до управління інформацією є доставка необхідної інформації у належному вигляді зацікавленим особам у межах організації у конкретний час. Мета такого управління полягає в тому, щоб допомогти людям краще працювати разом, використовуючи зростаючі обсяги інформації.

Інформаційні технології в даному випадку виступають засобом, за допомогою якого можна було б систематизувати інформацію на підприємстві, надати певним користувачам до неї доступ і дати їм інструментальні засоби для перетворення цієї інформації на знання.

Базові поняття OLAP-технологій

OLAP-технології (від англ. On-Line Analytical Processing) - це назва не конкретного продукту, а цілої технології оперативного аналізу багатовимірних даних, накопичених у сховищі. Для того, щоб зрозуміти сутність OLAP, необхідно розглянути традиційний процес отримання інформації для прийняття рішень.

Традиційна система підтримки прийняття рішень

Тут, звичайно, теж може бути багато варіантів: повний інформаційний хаос або найбільш типова ситуація, коли на підприємстві існують оперативні системи, за допомогою яких реєструються факти здійснення певних операцій та їх зберігання в базах даних. Для отримання даних з баз для аналітичних цілей побудована система запитів певних вибірок даних.

Але такий спосіб підтримки прийняття рішень позбавлений гнучкості та має багато недоліків:

• використовується дуже мала кількість даних, які можуть бути корисними для прийняття рішень
• іноді створюються складні багатосторінкові звіти, у тому числі реально використовуються 1-2 рядки (інше – про всяк випадок) – інформаційне навантаження
• повільна реакція процесу на зміни: якщо необхідне нове подання даних, запит має бути формально описаний і закодований програмістом, тільки потім виконаний. Час очікування: годинник, дні. А можливе рішення необхідне зараз, негайно. Адже після отримання нової інформації, виникне нове питання (уточнююче)

Якщо звіти по запитах подаються в одновимірному форматі, то проблеми бізнесу зазвичай багатовимірні та багатогранні. Якщо потрібно отримати ясну картину бізнесу компанії, необхідно аналізувати дані в різних розрізах.

Багато компаній створюють прекрасні реляційні бази даних, ідеально розклавши по поличках гори інформації, яка не використовується, яка сама по собі не забезпечує ні швидкої, ні достатньо грамотної реакції на ринкові події. ТАК – реляційні БД були, є і будуть найбільш підходящою технологією для зберігання корпоративних даних. Йдеться не про нову технологію БД, а, швидше, про інструментальні засоби аналізу, що доповнюють функції існуючих СУБД і досить гнучкі, щоб передбачити та автоматизувати різні види інтелектуального аналізу, притаманні OLAP.

Розуміння OLAP

Що надає OLAP?

• Розвинені інструменти доступу до даних сховища
• Динамічне інтерактивне маніпулювання даними (обертання, консолідації або деталізації)
• Наочне візуальне відображення даних
• Швидкість – аналіз здійснюється у реальному режимі часу
• Багатовимірне подання даних - одночасний аналіз низки показників з кількох вимірів

Для отримання ефекту від використання OLAP-технологій необхідно: 1) розуміти сутність самих технологій та їх можливості; 2) чітко визначитися, які процеси необхідно аналізувати, якими показниками вони будуть характеризуватись і в яких вимірах їх доцільно бачити, тобто створити модель аналізу.

Базові поняття, якими оперують OLAP-технології, такі:

Багатовимірність

Для розуміння багатовимірності даних, спочатку слід подати таблицю, що відображає, наприклад, виконання витрат підприємства з економічних елементів та бізнес-одиницям.

Ці дані представлені у двох вимірах:

• стаття
• бізнес-одиниця

Ця таблиця не інформативна, оскільки показує продаж за один якийсь проміжок часу. Для різних часових періодів, аналітикам доведеться зіставляти кілька таблиць (за кожен період часу):

На малюнку видно 3-й вимір, Час, на додаток до перших двох. (Стаття, бізнес-одиниця)

Інший спосіб показати багатовимірні дані - це уявити їх у формі куба:

OLAP-куби дозволяють аналітикам отримувати дані на різних зрізах для отримання відповідей на питання, які ставить бізнес:

• Які витрати у яких бізнес-одиницях критичні?
• Як змінюються витрати бізнес-одиниць у часі?
• Як змінюються статті витрат у часі?

Відповіді на такі питання необхідні для прийняття управлінських рішень: про скорочення певних статей витрат, вплив на їхню структуру, виявлення причин змін витрат у часі, відхилень від плану та їх ліквідація – оптимізація їхньої структури.

У цьому прикладі розглянуто лише 3 виміри. Важко зобразити більше 3-х вимірів, але це працює так само, як і у випадку з трьома вимірами.

Зазвичай OLAP-додатки дозволяють отримувати дані по 3 і більше вимірів, наприклад, можна додати ще один вимір – План-Факт, Категорія витрат: прямі, непрямі, Замовлення, Місяці. Додаткові вимірювання дозволяють отримувати більше аналітичних зрізів та забезпечують відповіді на питання з кількома умовами.

Ієрархічність

OLAP також дозволяє аналітикам організовувати кожен вимір у вигляді ієрархії, що складається з груп та підгруп та підсумкових значень, що відображають показник по всій організації – найбільш логічний спосіб аналізувати бізнес.

Наприклад, витрати доцільно згрупувати ієрархічно:

OLAP дозволяє аналітикам отримати дані загальному зведеному показнику (на самому верхньому рівні), а потім деталізувати до нижнього та наступного за ним рівня, і таким чином відкрити точну причину зміни показника.

Дозволяючи аналітикам використовувати кілька вимірів у кубі даних, з можливістю ієрархічно побудованих вимірів, OLAP дозволяє отримати картину бізнесу, яка не стиснута структурою інформаційного сховища.

Зміна напрямів аналізу у кубі (обертання даних)

Як правило, оперують поняттями: вимірювання, задані в стовпцях, рядках (їх може бути кілька), інші формують зрізи, зміст таблиці формують розмірності (продажу, витрати, кошти)

Як правило, OLAP дозволяють змінювати орієнтацію вимірювань куба, тим самим представляючи дані в різних уявленнях.

Відображення даних куба залежить від:

• орієнтації вимірів: які виміри задані у рядках, стовпцях, зрізах;
• груп показників, виділених у рядках, стовпцях, зрізах.
• Зміна вимірювань лежить у діях користувача.

Таким чином, OLAP дозволяє проводити різні види аналізу та розуміти їх взаємозв'язки їх результатів.

• Аналіз відхилень – аналіз виконання плану, що доповнюється факторним аналізом причин відхилень шляхом деталізації показників.
• Аналіз залежностей: OLAP дозволяє виявляти різні залежності між різними змінами, наприклад при видаленні з асортименту пива протягом перших двох місяців виявилося падіння продажів вобли.
• Зіставлення (порівняльний аналіз). Порівняння результатів зміни показника у часі, для заданої групи товарів, у різних регіонах та інших.
• Аналіз динаміки дозволяє виявити певні тенденції зміни показників у часі.

Оперативність: можна сказати, що в основу OLAP покладено закони психології: можливість обробки інформаційних запитів у реальному часі - в темпі процесу аналітичного осмислення даних користувачем.

Якщо з реляційної бази даних можна вважати близько 200 записів на секунду і записати 20, то хороший OLAP-сервер, використовуючи розрахункові рядки та стовпці, може консолідувати 20 000-30 000 осередків (еквівалентно одному запису в реляційній базі даних) за секунду.

Наочність: Слід підкреслити, що OLAP надає розвинені засоби графічного представлення даних кінцевому користувачеві. Людський мозок здатний сприймати та аналізувати інформацію, яка представлена ​​у вигляді геометричних образів, в обсязі на кілька порядків більшому, ніж інформацію, представлену в алфавітно-цифровому вигляді. приклад: Нехай Вам потрібно знайти знайоме обличчя на одній із ста фотографій Я вважаю, що цей процес займе у Вас не більше хвилини. А тепер уявіть собі, що замість фотографій Вам запропонують сто словесних описів тих самих осіб. Думаю, що Вам взагалі не вдасться вирішити запропоноване завдання.

Простота: Головною особливістю цих технологій є те, що вони орієнтовані на використання не фахівцем у галузі інформаційних технологій, не експертом-статистиком, а професіоналом у прикладній галузі – менеджером кредитного відділу, менеджером бюджетного відділу, нарешті, директором. Вони призначені для спілкування аналітика із проблемою, а не з комп'ютером.

Незважаючи на великі можливості OLAP (крім того, ідея порівняно давня – 60-ті роки) реальне застосування практично не зустрічається на наших підприємствах. Чому?

• відсутня інформація або не зрозумілі можливості
• звичка мислити двовимірно
• ціновий бар'єр
• надмірна технологічність статей, присвячених OLAP: відлякують незвичні терміни – OLAP, «розкопка та зрізи даних», «нерегламентовані запити», «виявлення суттєвих кореляцій»

Наш підхід та західний до застосування OLAP

Крім того, ми також маємо специфічне розуміння прикладної корисності OLAP навіть при розумінні його технологічних можливостей.

Наші та російські автори різних матеріалів, присвячених OLAP, висловлюють таку думку щодо корисності OLAP: більшість сприймає OLAP як такий інструмент, який дозволяє розгортати та згортати дані просто та зручно, здійснюючи маніпуляції, які приходять аналітику в голову в процесі аналізу. Чим більше «зрізів» та «розрізів» даних аналітик бачить, тим більше у нього ідей, які, у свою чергу, для перевірки вимагають нових і нових «зрізів». Це не правильно.

В основі західного розуміння корисності OLAP лежить методологічна модель аналізу, яку необхідно закласти під час проектування OLAP-рішень. Аналітик не повинен грати з OLAP-кубом і безцільно змінювати його вимірювання та рівні деталізації, орієнтацію даних, графічне відображення даних (а це дійсно займає!), а чітко розуміти, які уявлення йому потрібні, в якій послідовності та навіщо (звичайно, елементи відкриттів» тут можуть бути, але це не основний елемент корисності OLAP).

Прикладне використання OLAP

• Бюджет
• Рух грошових коштів

Одна з найблагодатніших галузей застосування OLAP-технологій. Недаремно жодна сучасна система бюджетування не вважається завершеною без наявності у її складі OLAP-інструментарію для аналізу бюджету. Більшість бюджетних звітів легко будуються з урахуванням OLAP-систем. При цьому звіти відповідають дуже широку гаму питань: аналіз структури витрат і доходів, порівняння витрат за певними статтями в різних підрозділів, аналіз динаміки і тенденцій витрат на певні статті, аналіз собівартості та прибутку.

OLAP дозволить аналізувати приходи та відтоки коштів у розрізі бізнес-операцій, контрагентів, валют та часу з метою їх оптимізації потоків.

• Фінансова та управлінська звітність (з аналітикою, яка необхідна керівництву)
• Маркетинг
• Balanced Scorecard
• Аналіз прибутковості

За наявності відповідних даних можна знайти різну програму OLAP-технології.

OLAP -продукти

У цьому розділі мова йде про OLAP як про програмне рішення.

Загальні вимоги до OLAP-продуктів

Є багато шляхів реалізації OLAP додатків, то жодна конкретна технологія не повинна бути обов'язковою, або навіть рекомендованою. За різних умов і обставин один підхід може бути кращим за інший. Техніка реалізації включає багато різних патентованих ідей, якими так пишаються постачальники: різновиди архітектури клієнт-сервер, аналіз часових рядів, об'єктна орієнтація, оптимізація зберігання даних, паралельні процеси і т. д. Але ці технології не можуть бути частиною визначення OLAP.

Є характеристики, які мають дотримуватися у всіх OLAP-продуктах (якщо це OLAP-продукт), у яких і полягає ідеал технології. Це 5 ключових визначень, які характеризують OLAP (так званий тест FASMI): Швидкий Аналіз Розділеної Багатомірної інформації.

• Швидкий(FAST) – означає, що система має забезпечувати видачу більшості відповідей користувачам у межах приблизно п'яти секунд. Навіть якщо система попередить, що процес триватиме суттєво довше, користувачі можуть відволіктися і втратити думку, при цьому якість аналізу страждає. Таку швидкість не просто досягти з великою кількістю даних, особливо, якщо потрібні спеціальні обчислення «на льоту». Постачальники вдаються до широкого розмаїття методів, щоб досягти цієї мети, включаючи спеціалізовані форми зберігання даних, великі попередні обчислення, або ж посилюючи апаратні вимоги. Однак повністю оптимізованих рішень на сьогоднішній день немає. На перший погляд може здаватися дивним, що при отриманні звіту за хвилину, на який нещодавно були потрібні дні, користувач дуже швидко починає нудьгувати під час очікувань, і проект виявляється набагато менш успішним, ніж у разі миттєвої відповіді, навіть ціною менш детального аналізу.
• Розділяєтьсяозначає, що система дає можливість виконувати всі вимоги захисту даних та реалізовувати розподілений та одночасний доступ до даних для різних рівнів користувачів. Система має бути здатна обробити численні зміни даних своєчасним, безпечним способом. Це головна слабкість багатьох OLAP продуктів, які мають тенденцію припускати, що у всіх додатках OLAP потрібне лише читання, і надають спрощені засоби захисту.
• Багатовимірною- Ключова вимога. Якби необхідно було визначити OLAP одним словом, вибрали б його. Система має забезпечити багатовимірне концептуальне подання даних, включаючи повну підтримку для ієрархій та множинних ієрархій, оскільки це визначає найбільш логічний спосіб аналізувати бізнес. Мінімальна кількість вимірювань, які мають бути оброблені, не встановлюється, оскільки це також залежить від програми, і більшість продуктів OLAP має достатню кількість вимірювань для тих ринків, на які вони націлені. І знову ж таки ми не визначаємо, яка основна технологія бази даних повинна використовуватися, якщо користувач отримує дійсно багатовимірне концептуальне подання інформації. Ця особливість - серцевина OLAP
• Інформація.Необхідна інформація має бути отримана там, де вона необхідна, незалежно від її обсягу та місця зберігання. Однак багато залежить від програми. Потужність різних продуктів вимірюється в термінах того, скільки вхідних даних вони можуть обробляти, але не скільки гігабайт можуть зберігати. Потужність продуктів дуже різна - найбільші OLAP продукти можуть оперувати принаймні в тисячу разів великою кількістю даних у порівнянні з найменшими. З цього приводу слід враховувати багато факторів, включаючи дублювання даних, необхідну оперативну пам'ять, використання дискового простору, експлуатаційні показники, інтеграцію з інформаційними сховищами тощо.
• Аналізозначає, що система може справлятися з будь-яким логічним та статистичним аналізом, характерним для даної програми, та забезпечує його збереження у вигляді, доступному для кінцевого користувача. Користувач повинен мати можливість задавати нові спеціальні обчислення як частину аналізу без програмування. Тобто всі необхідні функціональні можливості аналізу повинні забезпечуватись інтуїтивним способом для кінцевих користувачів. Кошти аналізу можуть включати певні процедури, типу аналізу часових рядів, розподілу витрат, валютних переказів, пошуку цілей та інших. Такі можливості широко відрізняються серед продуктів, залежно від цільової орієнтації.

Іншими словами, ці 5 ключових визначень – це цілі, на досягнення яких орієнтовані OLAP-продукти.

Технологічні аспекти OLAP

OLAP система включає певні компоненти. Існують різні схеми їхньої роботи, які той чи інший продукт може реалізувати.

Компоненти OLAP-систем (з чого складається OLAP-система?)

Як правило, OLAP-система включає наступні компоненти:

• Джерело даних
  Джерело, з якого беруться дані для аналізу (сховище даних, база даних оперативних облікових систем, набір таблиць, комбінації перерахованого).
• OLAP-сервер
  Дані з джерела переносяться або копіюються на OLAP-сервер, де вони систематизуються і готуються для швидшого після формування відповідей на запити.
• OLAP-клієнт
  Інтерфейс користувача до OLAP-сервера, в якому оперує користувач

Слід зазначити, що не всі компоненти є обов'язковими. Існують настільні OLAP-системи, що дозволяють аналізувати дані, що зберігаються безпосередньо на комп'ютері користувача, і не потребують сервера OLAP.

Проте який елемент обов'язковий це джерело даних: наявність даних – це важливе питання. Якщо вони є, у будь-якому вигляді, як Excel-таблиця, у базі даних облікової системи, у вигляді структурованих звітів філій ІТ-фахівець зможе інтегрувати з OLAP-системою безпосередньо або з проміжним перетворенням. Для цього OLAP системи мають спеціальні інструменти. Якщо цих даних немає, або вони мають недостатню повноту та якість, OLAP не допоможе. Тобто OLAP – це лише надбудова над даними, а якщо їх немає, вони стають марною річчю.

Більшість даних для OLAP-програм виникають в інших системах. Однак, у деяких програмах (наприклад, для планування або бюджетування), дані можуть створюватися безпосередньо в програмах OLAP. Коли дані надходять з інших програм, зазвичай необхідно, щоб дані зберігалися в окремій, дублюючій формі для OLAP-додатка. Тому доцільно створювати сховища даних.

Слід зазначити, що термін "OLAP" нерозривно пов'язаний з терміном "сховище даних" (Data Warehouse). Сховище даних - це предметно-орієнтоване, прив'язане до часу і збори даних, що незмінюються, для підтримки процесу прийняття керуючих рішень. Дані до сховища потрапляють з оперативних систем (OLTP-систем), призначених для автоматизації бізнес-процесів, сховище може поповнюватися з допомогою зовнішніх джерел, наприклад статистичних звітів.

Незважаючи на те, що вони містять свідомо надмірну інформацію, яка і так є в базах або файлах оперативних систем, сховища даних необхідні тому, що:

• розрізненість даних, зберігання їх у форматах різних СУБД;
• підвищується продуктивність отримання даних
• якщо на підприємстві всі дані зберігаються на центральному сервері БД (що буває вкрай рідко), аналітик напевно не розбереться в їх складних, часом заплутаних структурах
• складні аналітичні запити до оперативної інформації гальмують поточну роботу компанії, надовго блокуючи таблиці та захоплюючи ресурси сервера
• можливість здійснити очищення та узгодження даних
• аналізувати дані оперативних систем безпосередньо неможливо або дуже важко;

Завдання сховища - надати «сировину» для аналізу в одному місці та у простій, зрозумілій структурі. Тобто концепція Сховищ Даних - це концепція аналізу даних, скоріш це концепція підготовки даних для аналізу. Вона передбачає реалізацію єдиного інтегрованого джерела даних.

OLAP-продукти: архітектури

При використанні OLAP-продуктів важливими є 2 питання: як і де зберігатиі оброблятидані. Залежно від цього, як реалізуються 2 цих процесу розрізняють архітектури OLAP. Існує 3 способи зберігання даних для OLAP та 3 способи обробки цих даних. Багато виробників пропонують кілька варіантів, деякі намагаються довести, що їхній підхід – єдиний найрозумніший. Це, звісно, ​​абсурд. Однак зовсім небагато продуктів можуть оперувати більш, ніж в одному режимі якісно.

Варіанти зберігання даних OLAP

Зберігання в даному контексті означає зміст даних у стані, що постійно оновлюється.

• Реляційні бази даних: це типовий вибір, якщо підприємстві облікові даних зберігаються в РБД. У більшості випадків дані слід зберігати в денормалізованій структурі (найприйнятніша схема «зірка»). Нормалізована база даних не прийнятна через дуже низьку продуктивність виконання запитів при формуванні агрегованих величин для OLAP (часто підсумкові дані зберігаються в агрегованих таблицях).
• Файли баз даних на клієнтському комп'ютері (кіоски або вітрини даних): ці дані можуть заздалегідь розповсюджуватися або створюватися за запитами клієнтських комп'ютерів.

Багатомірні бази даних: припускають, що дані зберігаються у багатовимірній базі даних на сервері. Вона може включати дані, витягнуті та підсумовані з інших систем і реляційних баз даних, файлів кінцевих користувачів та ін. У більшості випадків, багатовимірні бази даних зберігаються на диску, але деякі продукти дозволяють використовувати і оперативну пам'ять, обчислюючи найчастіше використовувані дані на льоту ». Дуже у малій кількості продуктів, заснованих на багатовимірних базах даних, можливе множинне редагування даних, багато продуктів дозволяють одиночну зміну, але множинне читання даних, тоді як інші обмежуються лише читанням.

Ці три місця зберігання даних мають різні можливості за обсягами зберігання, і вони розташовані в порядку, що знижується за можливостями. Вони також мають різні характеристики продуктивності при реалізації запитів: реляційні бази даних працюють набагато повільніше, ніж останні два варіанти.

Варіанти обробки OLAP-даних

Існує 3 тих же варіанти обробки даних:

• Використання SQL: цей варіант звичайно використовується при зберіганні даних в РБД. Однак SQL не дозволяє здійснювати багатовимірні обчислення одним запитом, тому потрібно написання складних SQL-запитів для того, щоб досягти не більше ніж звичайну багатовимірну функціональність. Однак це не зупиняє розробників спроб. У більшості випадків вони виконують обмежену кількість відповідних обчислень на SQL з результатами, які можна отримати і при багатовимірній обробці даних або з клієнтської машини. Можливе також використання оперативної пам'яті, яка може зберігати дані, використовуючи більш ніж один запит: це кардинально покращило відгук.
• Багатовимірна обробка на клієнті: клієнтський OLAP-продукт здійснює обчислення самостійно, але така обробка доступна лише в тому випадку, якщо користувачі мають відносно потужні ПК.

Багатовимірна обробка на сервері: це популярне місце для здійснення багатовимірних обчислень у клієнт-серверних OLAP-додатках, що використовується у багатьох продуктах. Продуктивність зазвичай висока, тому що більшість обчислень вже виконано. Однак це потребує великого дискового простору.

Матриця OLAP-архітектур

Відповідно шляхом поєднань варіантів зберігання/обробка можна отримати матрицю архітектур OLAP-систем. Відповідно, теоретично може існувати 9 поєднань цих способів. Однак, оскільки 3 з них позбавлені здорового глузду, то насправді існує лише 6 варіантів зберігання та обробки OLAP-даних.

Варіанти зберігання багатовимірних даних Варіанти багатовимірної обробки даних	Реляційна база даних	Серверна багатовимірна база даних	Клієнтський комп'ютер
	Cartesis Magnitude
Багатовимірна серверна обробка	Crystal Holos (ROLAP mode) IBM DB2 OLAP Server CA EUREKA:Strategy Informix MetaCube Speedware Media/MR Microsoft Analysis Services Oracle Express (ROLAP mode) Pilot Analysis Server Applix iTM1	Crystal Holos Comshare Decision Hyperion Essbase Oracle Express Speedware Media/M Microsoft Analysis Services PowerPlay Enterprise Server Pilot Analysis Server Applix iTM1
Багатовимірна обробка на клієнтському комп'ютері	Oracle Discoverer Informix MetaCube	Dimensional Insight Hyperion Enterprise	Cognos PowerPlay Personal Express iTM1 Perspectives

Оскільки саме зберігання визначає обробку, то прийнято групувати за варіантами зберігання, тобто:

• ROLAP-продукти у секторах 1, 2, 3
• Настільний OLAP – в секторі 6

MOLAP-продукти – у секторах 4 та 5

HOLAP-продукти (дозволяють як багатовимірний, так і реляційний варіант зберігання даних) – у 2 та 4 (виділені курсивом)

Категорії OLAP-продуктів

Існує понад 40 OLAP-постачальників, хоча всіх їх не можна вважати конкурентами, тому що вони можливості їх дуже відрізняються і, фактично, працюють вони в різних ринкових сегментах. Вони можуть бути згруповані в 4 важливі категорії, в основі відмінності яких лежать поняття: функціональність складна - функціональність проста, продуктивність - дискове простір. Зручно зобразити категорії у вигляді квадрата, оскільки це чітко показує взаємозв'язку з-поміж них. Відмінна риса кожної з категорій представлена ​​з його боку, а подібності коїться з іншими – на сусідніх сторонах, отже, категорії на протилежних сторонах – принципово хороші.

	Особливості	Переваги	Недоліки	Представники
Прикладний OLAP	Закінчені додатки, з багатою функціональністю. Майже всі вимагають багатовимірної бази даних, хоча деякі працюють і з реляційною. Багато з цієї категорії додатків спеціалізовані, наприклад, продаж, провадження, банківська справа, бюджетування, фінансова консолідація, аналіз продажів	Можливість інтеграції з різними програмами Високий рівень функціональності Високий рівень гнучкості та масштабованості	Складність програми (необхідність навчання користувача) Висока вартість	Hyperion Solutions Crystal Decisions Information Builders
	В основі продукту лежить нереляційна структура даних, що забезпечує багатовимірне зберігання, обробку та подання даних. Дані у процесі аналізу вибираються виключно з багатовимірної структури. Незважаючи на високий рівень відкритості, постачальники схиляють покупців купувати їхній же інструментарій	Висока продуктивність (швидкі обчислення сумарних показників та різні багатовимірні перетворення за будь-яким із вимірювань). Середній час відповіді на нерегламентований аналітичний запит при використанні багатовимірної БД зазвичай на 1-2 порядки менше, ніж у разі РБД Високий рівень відкритості: велика кількість продуктів, з якими можлива інтеграція Легко справляються із завданнями включення до інформаційної моделі різноманітних вбудованих функцій, проведення користувачем спеціалізованого аналізу тощо.	Необхідність великого дискового простору для зберігання даних (через надмірність даних, що зберігаються). Це вкрай неефективне використання пам'яті - за рахунок денормалізації та попередньо виконаної агрегації обсяг даних у багатовимірній базі відповідає у 2.5-100 разів меншому обсягу вихідних деталізованих даних. У будь-якому випадку MOLAP не дозволяє працювати з великими базами даних. Реальна межа - база об'ємом 10-25 гігабайт Потенційна можливість «вибуху» бази даних – несподіване, різке, непропорційне зростання її обсягів Відсутність гнучкості за необхідності модифікації структур даних. Будь-яка зміна у структурі вимірювань майже завжди потребує повної перебудови гіперкубу. Для багатовимірних БД, в даний час відсутні єдині стандарти на інтерфейс, мови опису та маніпулювання даними	Hyperion (Essbase)
DOLAP (Desktop OLAP)	Клієнтські OLAP-продукти, які досить легко впровадити та вимагають низьких витрат у розрахунку на одне місце Йдеться про таку аналітичну обробку, де гіперкуби малі, розмірність їх невелика, потреби скромні, і для такої аналітичної обробки достатньо персональної машини на робочому столі. Мета виробників цього ринку - автоматизація сотень і тисяч робочих місць, але користувачі повинні робити досить простий аналіз. Покупців часто орієнтують купувати більше робочих місць, ніж це потрібно	Хороша інтеграція з базами даних: багатовимірними, реляційними Можливість здійснення комплексних покупок, що знижує вартість проектів впровадження Простота використання програм	Дуже обмежена функціональність (не порівняти у цьому плані зі спеціалізованими продуктами) Дуже обмежена потужність (малі обсяги даних, невелика кількість вимірювань)	Cognos (PowerPlay) Business Objects Crystal Decisions
	Це найменший сектор ринку. Детальні дані залишаються там, де вони були спочатку - у реляційній БД; деякі агрегати зберігаються у тій же БД у спеціально створених службових таблицях	Чи здатні працювати з дуже великими обсягами даних (економічне зберігання) Передбачають розрахований на багато користувачів режим роботи, в тому числі і в режимі редагування, а не тільки читання Більш високий рівень захисту даних та гарні можливості розмежування прав доступу Можливе часте внесення змін до структури вимірювань (не вимагають фізичної реорганізації БД)	Низька продуктивність значно програють за швидкістю відгуку багатовимірним (відгук на складні запити вимірюється в хвилинах або навіть годинах, ніж у секундах). Це зручніші будівельники звітів, ніж інтерактивні аналітичні інструменти Складність продуктів. Вимагають значних витрат на обслуговування спеціалістами з інформаційних технологій. Для забезпечення продуктивності, порівнянної з MOLAP, реляційні системи вимагають ретельного опрацювання схеми бази даних та налаштування індексів, тобто великих зусиль з боку адміністраторів БД Дорогі для впровадження Обмеження SQL залишаються реальністю, що не дозволяє реалізувати в РСУБД багато вбудованих функцій, що легко забезпечуються в системах, заснованих на багатовимірному поданні даних.	Information Advantage Informix (MetaCube)

Слід зазначити, що споживачі гібридних продуктів, які дозволяють вибирати режим ROLAP та MOLAP, таких як Microsoft Analysis Services, OracleExpress, Crystal Holos, IBM DB2 OLAPServer, майже завжди вибирають режим MOLAP.

Кожна з представлених категорій має свої сильні та слабкі сторони, немає єдино оптимального вибору. Вибір впливає на 3 важливі аспекти: 1) продуктивність; 2) дисковий простір для зберігання даних; 3) можливості, функціональність та особливо на масштабованість OLAP-рішення. При цьому необхідно враховувати обсяги даних, потужність техніки, потреби користувачів і шукати компроміс між швидкодією і надмірністю дискового простору, зайнятого базою даних, простою і багатофункціональністю.

Класифікація Сховищ Даних відповідно до обсягу цільової БД

Недоліки OLAP

Як і будь-яка технологія OLAP також має свої недоліки: високі вимоги до апаратного забезпечення, підготовки та знань адміністративного персоналу та кінцевих користувачів, високі витрати на реалізацію проекту впровадження (як грошові, так і тимчасові, інтелектуальні).

Вибір OLAP-продукту

Правильно вибрати OLAP продукт складно, але дуже важливо, якщо ви хочете, щоб проект не провалився.

Як видно, відмінності продуктів лежать у багатьох сферах: функціональних, архітектурних, технічних. Деякі продукти дуже обмежені у налаштуваннях. Деякі створені для спеціалізованих предметних галузей: маркетинг, продаж, фінанси. Є продукти для загальних цілей, у яких не закладено прикладне використання, які мають бути досить гнучкими. Як правило, такі продукти дешевші, ніж спеціалізовані, але тут більше витрати на впровадження. Спектр OLAP-продуктів дуже широкий - від найпростіших засобів побудови зведених таблиць та діаграм, що входять до складу офісних продуктів, до засобів аналізу даних та пошуку закономірностей, вартість яких становить десятки тисяч доларів.

Як і в будь-якій іншій галузі, у сфері OLAP не може існувати однозначних рекомендацій щодо вибору інструментальних засобів. Можна лише загострити увагу на низці ключових моментів та зіставити запропоновані можливості програмного забезпечення з потребами організації. Важливо одне: не обдумавши добре те, як ви збираєтеся використовувати OLAP-інструменти, ви ризикуєте нажити собі сильний «головний біль».

У процесі вибору необхідно розглянути 2 питання:

• оцінити потреби та можливості підприємства
• оцінити пропозицію, що існує на ринку, важливі також і тенденції розвитку

Потім усе це зіставити і, власне, зробити вибір.

Оцінка потреб

Не можна зробити раціональний вибір продукту без розуміння того, навіщо він використовуватиметься. Багато компаній хочуть отримати "найкращий виріб" без чіткого розуміння, як воно має використовуватися.

Для того, щоб проект був успішно реалізований, фінансовий директор повинен як мінімум грамотно сформулювати перед керівником та спеціалістами служби автоматизації свої побажання та вимоги. Безліч проблем виникає через недостатню підготовленість та поінформованість для вибору OLAP, фахівці з ІТ та кінцеві користувачі відчувають труднощі спілкування вже тільки тому, що маніпулюють при розмові різними поняттями та термінами і висувають суперечливі переваги. Потрібна узгодженість у цілі в рамках компанії.

Деякі фактори стали очевидними після ознайомлення з оглядом категорій OLAP-продуктів, а саме:

Технічні аспекти

• Джерела даних: корпоративне сховище даних, OLTP-система, табличні файли, реляційні бази даних. Можливість ув'язування OLAP-інструментарію з усіма СУБД, що використовуються в організації. Як показує практика, інтеграція різнорідних продуктів у стійко діючу систему - одне з найважливіших питань, та її вирішення часом може бути пов'язані з великими проблемами. Необхідно розібратися, наскільки легко і надійно можна інтегрувати кошти OLAP з існуючими в організації СУБД. Важливо також оцінити можливості інтеграції не тільки з джерелами даних, але й з іншими додатками, які, можливо, знадобиться експортувати дані: електронна пошта, офісні програми
• Мінливість даних, що враховуються
• Платформа сервера: NT, Unix, AS/400, Linux - але не слід наполягати, щоб задані специфікацією OLAP продукти виконувалися на сумнівних або вмираючих платформах, які Ви все ще використовуєте
• Стандарти клієнтської частини та браузера
• Розгортається архітектура: локальна мережа та модемний зв'язок PC, високошвидкісний клієнт/сервер, intranet, extranet, Internet
• Міжнародні особливості: багатовалютна підтримка, багатомовні операції, колективне використання даних, локалізація, ліцензування, оновлення Windows

Обсяги вхідної інформації, які є та які з'являться у майбутньому

Користувачі

• Сферу застосування: аналіз продажів/маркетингу, складання бюджету/планування, аналіз показників діяльності, аналіз бухгалтерських звітів, якісний аналіз, фінансовий стан, формування аналітичних матеріалів (звітів)
• Число користувачів та їх розміщення, вимоги до поділу прав доступу до даних та функцій, секретність (конфіденційність) інформації
• Вигляд користувача: вище керівництво, фінанси, маркетинг, HR, продаж, виробництво і т.д.
• Досвід користувача. Рівень кваліфікації користувача. Розглянути питання проведення навчання. Дуже важливо, щоб клієнтська OLAP-додаток була такою, щоб користувачі відчували себе впевнено та могли ефективно її використовувати.

Ключові особливості: потреба у зворотному записі даних, розподілені обчислення, складні валютні перетворення, потреби у друку звітів, інтерфейс електронної таблиці, складність логіки програми, необхідна розмірність, типи аналізу: статистичний, пошук мети, аналіз «що якщо»

Впровадження

• Хто займатиметься впровадженням та експлуатацією: зовнішні консультанти, внутрішня служба ІТ або кінцеві користувачі
• Бюджет: програмне забезпечення, апаратні засоби, послуги, передачі даних. Пам'ятайте, що оплата ліцензій OLAP-продукту – це лише невелика частина загальної вартості проекту. Впровадження та апаратні витрати можуть бути більшими, ніж плата за ліцензію, а тривала підтримка, експлуатація та витрати адміністрації майже напевно значно більші. І якщо Ви прийняли неправильне рішення купівлі невідповідного продукту тільки тому, що воно дешевше, остаточно Ви можете мати вищу загальну вартість проекту через вищі витрати на обслуговування, адміністрацію та/або апаратні витрати при тому, що ймовірно, Ви отримаєте нижчий рівень ділових вигод. При прикидці загальних витрат не забудьте з'ясувати такі питання: Наскільки широкий вибір джерел для впровадження, навчання та підтримки? Чи потенційний загальний фонд (службовців, підрядників, консультантів) схильний до зростання чи скорочення? Наскільки широко можна використовувати свій виробничий професійний досвід?

Незважаючи на те, що вартість аналітичних систем навіть сьогодні залишається досить високою, а методології та технології реалізації таких систем знаходяться ще на стадії їх становлення, вже сьогодні економічний ефект, що забезпечується ними, істотно перевищує ефект від традиційних оперативних систем.

Ефект від правильної організації, стратегічного та оперативного планування розвитку бізнесу важко заздалегідь оцінити у цифрах, але очевидно, що він у десятки і навіть сотні разів може перевершити витрати на реалізацію таких систем. Однак не слід і помилятися. Ефект забезпечує не сама система, а люди з нею працюють. Тому не зовсім коректні декларації на кшталт: «система Сховищ Даних та OLAP-технологій допомагатиме менеджеру приймати правильні рішення». Сучасні аналітичні системи є системами штучного інтелекту і вони можуть ні допомогти, ні перешкодити у прийнятті рішення. Їхня мета своєчасно забезпечити менеджера всією інформацією необхідною для прийняття рішення у зручному вигляді. А яка інформація буде запитана і яке рішення буде прийнято на її основі, залежить тільки від конкретної людини, яка її використовує.

Залишається сказати тільки одне, ці системи можуть допомогти вирішити багато бізнес-проблеми і можуть мати позитивний ефект, що далеко йде. Залишається тільки чекати, хто першим усвідомлює переваги цього підходу і виявиться попереду інших.