Аналітичні системи OLAP. OLAP у фінансовому управлінні Olap є технологією

У циклі статей «Введення до баз даних», що публікувався останнім часом (див. Комп'ютерПрес №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' або назву іншої країни, можна знову виконати цей запит і отримати інше число. Виконавши цю процедуру з усіма країнами, ми отримаємо наступний набір даних (наведений нижче фрагмент):

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

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

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

Такий набір даних називається зведеною таблицею (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:

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

Третій із розглянутих вище запитів має вже три параметри за умови 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

У 1993 році основоположник реляційного підходу до побудови баз даних Едгар Кодд з партнерами (Edgar Codd, математик та стипендіат IBM), опублікували статтю, ініційовану компанією "Arbor Software" (сьогодні це найвідоміша компанія "Hyperion Solutions"), озаглавлену "Обе аналітичної обробки) для користувачів-аналітиків", у якій сформульовано 12 особливостей технології OLAP, які згодом були доповнені ще шістьма. Ці положення стали основним змістом нової та дуже перспективної технології.

Основні особливості технології OLAP (Basic):

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

Спеціальні особливості (Special):

• обробка неформалізованих даних;
• збереження результатів OLAP: зберігання їх окремо від вихідних даних;
• виключення відсутніх значень;
• обробка відсутніх значень.

Особливості подання звітів (Report):

• гнучкість формування звітів;
• стандартна продуктивність звітів;
• автоматичне налаштування фізичного рівня вилучення даних.

Управління вимірами (Dimension):

• універсальність вимірів;
• необмежену кількість вимірювань та рівнів агрегації;
• необмежену кількість операцій між розмірностями.

Історично склалося так, що сьогодні термін "OLAP" має на увазі не тільки багатовимірний погляд на дані з боку кінцевого користувача, але й багатовимірне представлення даних у цільовій БД. Саме з цим пов'язана поява як самостійні терміни "Реляційний OLAP" (ROLAP) і "Багатомірний OLAP" (MOLAP).

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

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

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

Рис. 6.14.Елементарний OLAP-куб

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

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

Рис. 6.15.

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

В даний час швидкий розвиток отримав напрямок, званий динамічним моделюванням (Dynamic Simulation), що повною мірою реалізує зазначений вище принцип FASMI.

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

Рис. 6.16.Аналітична ІС вилучення, обробки даних та подання інформації

У таблиці 6.3 наведено порівняльні характеристики статичного та динамічного аналізу.

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

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

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

Схема роботи

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

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

1. Отримання даних у вигляді плоскої таблиці або результату виконання запиту SQL.
2. Кешування даних та перетворення їх до багатовимірного куба.
3. Відображення збудованого куба за допомогою крос-таблиці або діаграми тощо. В загальному випадку, до одного куба може бути підключена довільна кількість відображень.

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

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

Крос-таблиця

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

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

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

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

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

Кількість елементів = 250 х 500 х 365 = 45 625 000

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

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

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

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

Підготовка данних

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

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

Бібліотека компонентів CubeBase

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

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

Порівняння продуктивності

Цей набір компонент показав набагато вищу швидкодію, ніж Decision Cube. Так, на наборі з 45 тис. записів компоненти Decision Cube зажадали 8 хв. на побудову зведеної таблиці. CubeBase здійснив завантаження даних за 7сек. та побудова зведеної таблиці за 4 сек. При тестуванні на 700 тис. записів Decision Cube ми не дочекалися відгуку протягом 30 хвилин, після чого зняли завдання. CubeBase здійснив завантаження даних за 45 сік. та побудова куба за 15 сек.

На обсягах даних у тисячі записів CubeBase відпрацьовував у десятки разів швидше за Decision Cube. На таблицях у сотні тисяч записів – у сотні разів швидше. А висока продуктивність – один із найважливіших показників OLAP систем.

Основні характеристики сховищ даних.

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

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

• багатовимірне представлення даних;
• підтримка складних розрахунків;
• правильний облік фактор часу.

Переваги OLAP:

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

OLAP та OLTP. Характеристики та основні відмінності

Правила Кодду для OLAP систем

У 1993 році Кодд опублікував працю під назвою "OLAP для користувачів-аналітиків: якою вона має бути". У ньому він виклав основні концепції оперативної аналітичної обробки та визначив 12 правил, яким мають задовольняти продукти, що надають можливість виконання оперативної аналітичної обробки.

1. Концептуальне багатовимірне уявлення. OLAP -модель має бути багатовимірною у своїй основі. Багатовимірна концептуальна схема або уявлення користувача полегшують моделювання і аналіз так само, втім, як і обчислення .
2. Прозорість. Користувач може отримати всі необхідні дані з OLAP-машини, навіть не підозрюючи, звідки вони беруться. Незалежно від того, є OLAP-продукт частиною засобів користувача чи ні, цей факт має бути непомітним для користувача. Якщо OLAP надається клієнт-серверними обчисленнями, цей факт також, по можливості, повинен бути невидимий для користувача. OLAP повинен надаватися в контексті істинно відкритої архітектури, дозволяючи користувачеві, де б він не знаходився, зв'язуватися за допомогою аналітичного інструменту із сервером. На додаток до цього прозорість повинна досягатися і при взаємодії аналітичного інструменту з гомогенним та гетерогенним середовищами БД.
3. Доступність. OLAP повинен надавати свою власну логічну схемудля доступу в гетерогенному середовищі БД та виконувати відповідні перетворення для надання даних користувачеві. Понад те, необхідно заздалегідь подбати у тому, де як, і які типи фізичної організації даних справді використовуватимуться. OLAP -система повинна виконувати доступ тільки до дійсно потрібних даних, а не застосовувати загальний принцип "кухонної вирви", який тягне за собою непотрібне введення.
4. Постійна продуктивністьрозробки звітів . Продуктивністьформування звітів не має суттєво падати зі зростанням кількості вимірювань та розмірів бази даних.
5. Клієнт-серверна архітектура. Потрібно, щоб продукт був не тільки клієнт-серверним, але й щоб серверний компонент був досить інтелектуальним для того, щоб різні клієнти могли підключатися з мінімумом зусиль і програмування.
6. Загальна багатовимірність. Усі виміри мають бути рівноправними, кожен вимір має бути еквівалентним і в структурі, і в операційних можливостях. Щоправда, допускаються додаткові операційні можливості окремих вимірювань (мабуть, мається на увазі час), але такі додаткові функції мають бути надані будь-якому виміру. Не повинно бути так, щоб базові структури даних, обчислювальні чи звітні формати були властиві якомусь одному виміру.
7. Динамічне керування розрідженими матрицями. OLAP системи повинні автоматично налаштовувати свою фізичну схему залежно від типу моделі, обсягів даних та розрідженості бази даних.
8. Розрахована на багато користувачів підтримка . OLAP-інструмент повинен надавати можливості спільного доступу(запиту та доповнення), цілісності та безпеки.
9. Необмежені перехресні операції. Усі види операцій мають бути дозволені будь-яких вимірів.
10. Інтуїтивна маніпуляція даними. Маніпулювання даними здійснювалося за допомогою прямих дій над осередками в режимі перегляду без використання меню та множинних операцій.
11. Гнучкі можливості отримання звітів. Вимірювання мають бути розміщені у звіті так, як це потрібно користувачеві.
12. Необмежена

У 1993 році основоположник реляційного підходу до побудови баз даних Едгар Кодд з партнерами (Edgar Codd, математик і стипендіат IBM), опублікували статтю, ініційовану компанією "Arbor Software" (сьогодні це найвідоміша компанія "Hyperion Solutions"), озаглавлену "Обе аналітичної обробки) для користувачів-аналітиків", у якій сформульовано 12 особливостей технології OLAP, які згодом були доповнені ще шістьма. Ці положення стали основним змістом нової та дуже перспективної технології.

Основні особливості технології OLAP (Basic):

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

Спеціальні особливості( Special ):

• обробка неформалізованих даних;
• збереження результатів OLAP: зберігання їх окремо від вихідних даних;
• виключення відсутніх значень;
• обробка відсутніх значень.

Особливості подання звітів(Report):

• гнучкість формування звітів;
• стандартна продуктивність звітів;
• автоматичне налаштування фізичного рівня вилучення даних.

Управління вимірами(Dimension):

• універсальність вимірів;
• необмежену кількість вимірювань та рівнів агрегації;
• необмежену кількість операцій між розмірностями.

Історично склалося так, що сьогодні термін "OLAP" має на увазі не тільки багатовимірний погляд на дані з боку кінцевого користувача, але й багатовимірне представлення даних у цільовій БД. Саме з цим пов'язана поява як самостійні терміни "Реляційний OLAP"(ROLAP) та "Багатомірний OLAP"(MOLAP).

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

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

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

Рис. 6.14.

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

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

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

В даний час швидкий розвиток отримав напрям, званий динамічним моделюванням(Dynamic Simulation), що повною мірою реалізує зазначений вище принцип FASMI.

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

У таблиці 6.3 наведено порівняльні характеристики статичного та динамічного аналізу.

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

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

Ключові питання "Скільки продано?", "На яку суму продано?" розширюються в міру ускладнення бізнесу та накопичення історичних даних до деякої множини факторів, або розрізів: ".. у Санкт-Петербурзі, в Москві, на Уралі, в Сибіру ...", ".. у минулому кварталі, в порівнянні з нинішнім", " ..від постачальника А проти постачальником Б…" тощо.

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

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

Час. Як правило, це кілька періодів: Рік, Квартал, Місяць, Декада, Тиждень, День. Багато інструментів OLAP автоматично обчислюють старші періоди з дати і обчислюють результати по них.

Категорія товару. Категорій може бути кілька, вони відрізняються для кожного виду бізнесу: Сорт, Модель, Вид упаковки та ін. Якщо продається тільки один товар або асортимент дуже невеликий, то категорія не потрібна

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

Регіон. Залежно від глобальності бізнесу можна на увазі Континент, Група країн, Країна, Територія, Місто, Район, Вулиця, Частина вулиці. Звичайно, якщо є лише одна торгова точка, то цей вимір відсутній.

Продавець. Цей вимір також залежить від структури та масштабів бізнесу. Тут може бути: Філія, Магазин, Дилер, Менеджер з продажу. У деяких випадках вимір відсутній, наприклад, коли продавець не впливає на обсяги збуту, магазин лише один і так далі.

Покупець. У деяких випадках, наприклад, у роздрібній торгівлі, покупець знеособлений та вимір відсутня, в інших випадках інформація про покупця є, і вона важлива для продажу. Цей вимір може містити назву фірми-покупця або безліч угруповань і характеристик клієнтів: Галузь, Група підприємств, Власник і так далі. Аналіз структури продажів для виявлення найважливіших складових у розрізі, що цікавить. Для цього зручно використовувати, наприклад, діаграму типу "Пиріг" у складних випадках, коли досліджується відразу 3 виміри - "Стовпці". Наприклад, у магазині "Комп'ютерна техніка" за квартал продаж комп'ютерів склали $100000, фототехніки -$10000, витратних матеріалів - $4500. Висновок: оборот магазину залежить великою мірою від продажу комп'ютерів (насправді, можливо, витратні матеріали необхідні для продажу комп'ютерів, але це вже аналіз внутрішніх залежностей).

Аналіз динаміки ( регресійний аналіз- Виявлення трендів). Виявлення тенденцій, сезонних коливань. Наочно динаміку відображає графік типу "Лінія". Наприклад, обсяги продажів продуктів компанії Intel протягом року знижувалися, а обсяги продажів Microsoft зростали. Можливо, покращився добробут середнього покупця, або змінився імідж магазину, а з ним і склад покупців. Потрібно провести коригування асортименту. Інший приклад: протягом 3 років узимку знижується обсяг продажу відеокамер.

Аналіз залежностей(Кореляційний аналіз). Порівняння обсягів продажу різних товарів у часі для виявлення необхідного асортименту – "корзини". Для цього зручно використовувати графік типу "Лінія". Наприклад, при видаленні з асортименту принтерів протягом перших двох місяців виявилося падіння продажів картриджів із порошком.