Інтелектуальна обробка інформаціїits.kpi.ua/subjects/45/Documents/IntelektObtInform.pdf · Перегляд перетинів куба ... Створити

1

Міністерство освіти і науки України

Національний технічний університет України

"Київський політехнічний інститут"

Інтелектуальна обробка інформації до виконання лабораторних робіт

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

"Інформаційні мережі зв’язку"

Затверджено Методичною радою НТУУ "КПІ"

Київ

НТУУ "КПІ"

2009

2

ЗМІСТ

Лабораторна робота 1 Робота з Mi c ros o f t Vi su a l S t ud io 20 05 .................................. 3

Лабораторна робота 2 Робота з MS Excel, як із клієнтом Analysis Server……………….19

Короткі теоретичні відомості .................................................................................................. 32

1.Теоретичні основи аналітичної обробки інформації ......................................................... 33

1.1.Способи аналітичної обробки даних ................................................................................ 33

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

1.3.Вимоги до засобів оперативної аналітичної обробки ..................................................... 36

1.4. Загальний аналіз OLAP ..................................................................................................... 39

1.5. Багатомірне подання в OLAP ........................................................................................... 41

1.6."Розрізування" куба ............................................................................................................ 42

1.7.Мітки .................................................................................................................................... 43

1.8.Ієрархії і рівні ...................................................................................................................... 43

1.9.Архітектура OLAP-додатків .............................................................................................. 45

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

1.11.Багатомірний OLAP (MOLAP) ........................................................................................ 47

1.13.Інтелектуальний аналіз даних ......................................................................................... 51

1.14.Інтеграція OLAP й ІАД .................................................................................................... 52

1.15.Критерії оцінки існуючих продуктів .............................................................................. 54

3

Лабораторна робота 1

Робота з Microsoft Visual Studio2005

1. Ціль роботи

Метою роботи є вивчення роботи з вимірами в Microsof t

Visual Studio2005 , їхн іх типів і настроювання їхн іх

властивостей .

2. Склад робочого місця

2.1. Устаткування: IBM-сумісний персональний комп'ютер (ПК, з

мінімальними вимогами: 128Мб байт ОЗУ, 4.5 Гб байт ПЗУ, процесор РІІІ).

2 .2 . Програмне забезпечення : операційна система Windows

Server 2003 , MS SQL Server 2005 , Microsof t Visual Studio2005.

3. Методичні вказівки по роботі з Microsoft Visual Studio2005

Створення багатомірних баз даних й опис джерел даних

В данні ї роботі розглянемо створення багатомірного

OLAP-куба на п ідставі сховища даних Northwind _Mar t , це

сховище містить таблицю факт ів Sales_Fac t і таблиці вимір ів

Employee_Dim, Cus tomer_Dim, Product_Dim, Time_Dim,

Sh ipper_Dim.

Робота виконується в Microsof t Visua l S tud io2005 з

встановленною службою Analys i s Serv ices .

Основоним об’єктом є проект . Для створення якого

необхідно вибрати пункт з меню Файл – Создать - Проект

служб SSAS. Також у відповідному меню слід ввести імя та

місце збереження проекту.

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

створення яких в ідбувається вибором пункт New Database . . . з

контекстного меню елемента , що відповідає OLAP -серверу.

(Рис . 1 ) та введеням необхідних данних.

Перед створенням OLAP-кубів, необхідно описати джерела вихідних

даних для них. Для опису джерела даних існує в контекстно му

меню елемента Источники данных пункт Создать источник

данных. . .

Для коректної роботи поля стандартної діалогової панелі Data Link

Properties треба :

провайдер даних - OLE DB Provider for SQL Server,

4

сервер - ім'я SQL Server, встановленого на машині інструктора

правильно вибрана база вихідних даних.

Рис. 1. Створення джерела даних

Створення колективних вимірів типу «дата/час»

Для створення будь-яких вимірів можна використовувати майстер

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

Новое измерение/Мастер з контекстного меню елемента

Измерения .

Далі у відповідних діалогових вікнах необхідно відповісти на питання

майстра створення вимірів.

a. У першу чергу вибрати , на п ідставі чого буде

створено вимір : з використан ням джерела данних чи

н і .

b . Ім 'я таблиці , що служить джерелом даних для

створюваного виміру (Рис . 2) :

5

c.

Рис. 2. Вибір таблиці для створення виміру

Ієрархія даних у вимірах, заснованих на даних типу «дата/час»,

підкоряється певним стандартним правилам — адже час виміряється в роках,

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

ми аналізуємо. Тому виміри в OLAP-засобах звичайно діляться на стандартні

(не відносні) і тимчасові.

2. у д іалоговій панелі вибр ати відповідність часовим

вимірам та типам данних. (Рис . 3) .

6

Рис. 3 . Створення виміру типу «дата /час»

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

якщо є необхідність, створити ієрархію у вимірі й задати її ім'я. Справа

в тому, що при необхідності можна створити ще один вимір,

заснований на тих же даних, з тим же ім'ям, але з іншою ієрархією,

наприклад Year, Week, Day; у цьому випадку отримаємо різне подання

тих самих даних.

4. Створення виміру закінчується запуском редактора вимірів. У ньому

при необхідності можна внести зміни в структуру виміру, наприклад

додавши додаткові рівні або властивості членів виміру. Якщо

планується аналізувати залежність продажів від дня тижня або

порівнювати продажі у вихідні, святкові й будні дні, можна перенести

в у відповідний розділ відповідні атрибути (Рис. 4).

7

Рис . 4 . Редактор измерений

Створення регулярного виміру

Колективний вимір створимо за допомогою редактора вимірів. Запустити

його можна за допомогою команди Новое измерение/Мастер з

контекстного меню елемента Измерения . Цей вимір відноситься до

- Стандартное измерение ( замість Измерения времени )

В діалоговій панелі виберемо відповідну Product_Dim.

Та у редакторі вимірів створимо ієрархії і перенесемо мишею відповідні

імена полів у ліву частину редактора вимірів. Далі необхідно вибрани

властивості членів виміру певного рівня, вибором полів

Збережемо створений вимір , з вказанням імені (Рис . 5 ) .

8

Рис. 5. Створення регулярного виміру в Dimension Editor

Створення виміру з незбалансованою ієрархією

Створений вимір буде містити географічні відомості. Такі виміри є типовими

для створення так званих нерівних (ragged) ієрархій — часні випадки

незбалансованих (unbalanced) ієрархій. Як відомо, адміністративно-

територіальний поділ у різних країнах здійснюється за різними правилами: у

деяких країнах є регіони, штати, адміністративні округи, а в деяких досить

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

можуть бути відсутні.

Для створення виміру, заснованому на поданні сховища даних послідовність

дій подібна до попереднього прикладу.

Незбалансовані ієрархії звичайно базуються на приховуванні членів виміру,

що містять надлишкові відомості.

Виберемо такий рівень в редакторі вимірів і сторінці Свойства

виберемо Дополнительно , установимо властивість

HideMember I f рівним Paren tName . У цьому випадку вс і члени

цього р івня , що містять поля р івн і батьківськім , будуть

сховані (Рис . 6) .

9

Рис. 6. Незбалансована ієрархія

Створення виміру типу «батько-нащадок»

Зазвичай виміри , що містять в ідомо сті про адмін істративну

п ідпорядкованість сп івробітників , містять ще один тип

незбалансованих і єрархій — і єрархі ї типу «батько -

нащадок» (paren t -ch i ld ) . Такі і єрархі ї нерідко засновані на

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

ключем. Вихідна та блиця Employees бази даних Northwind

дійсно містить в ідомості про адмін істративну

п ідпорядкованість сп івробітників ( і має в ідповідний

зовнішній ключ)

Створимо вимір за допомогою майстра. У його відповідній

д іалоговій панелі виберемо опцію Данное измерение

содержит связи типа «родители – потомки» между

атрибутами . Далі вкажемо поле Repor t s_To — як

Родильский атрибут (Рис. 7).

10

Рис. 7. Визначення параметрів ієрархії «батько-нащадок»

Створимо ієрархію в цьому вимір і . У результат і ми

одержимо і єрархію , показану на Рис . 8 .

Рис. 8. Ієрархія «батько-нащадок»

11

Створення опису куба.Створення OLAP-кубів

Як і вимір , куб можна створити за допомогою відповідного

майстра або безпосередньо в редакторі куб ів . Як приклад

створимо куб , заснований на готовому схов ищі даних і що

використовує створені виміри .

Запустити майстер створення кубів командою Создать куб з

контекстного меню елемента Кубы .

Зняти в ідмітку для автоматичної побудови

Вибрати колективн і виміри , використан і у цьому кубі . (Рис . 9 )

Рис. 9 Вибір мір куба

Вибрати таблицю фактів для майбутнього куб у .

З таблиці фактів варто вибрати одне або к ілька полів , на

основі яких обчислюються міри куба (тобто поля , дан і яких

п ідлягають п ідсумовуванню або обробці за допомогою інших

агрегатних функцій) (Рис . 10) .

12

Рис. 10 . Вибір мір куба

Таким чином, ми визначили метадані куба. По закінченні роботи майстри

буде запущений редактор кубів, у якому при необхідності можна внести

виправлення у визначення куба, наприклад додати або видалити виміри й

міри, створити обчислюють значения, що, і т.д. (Рис. 11).

Рис. 11. Редактор кубів

13

Створення обчислюваних виразів

Спробуємо додати до куба (результата попередніх лабораторных робіт)

обчислюванні значения, тобто значення, які не зберігаються в самому кубі, а

обчислюються «на льоту». Типовим прикладом такого значення може бути

додатковий захід, обчислена на основі вже наявних. При обчисленнях можна

використати як функції з бібліотеки, що входить до складу Analysis Services,

так і вирази VBA, а також власні бібліотеки функцій (останні варто

зареєструвати в Analysis Services).

Для створення вираз ів , що обчислюють, треба вибрати розд іл

Вычисление для куба

На панелі інструменті вибрати Создать вычиляемый елемент .у

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

вимірів й їхніх рівнів, мір, імена функцій. (Рис. 12).

Рис. 12. Редактор виразів, що обчислюють

У результаті одержано ще одну міру . Тепер можна зберегти визначення

куба, вибравши пункт меню Файл/Сохранить .

14

Створення багатомірного сховища даних

Агрегати — це заздалегідь обчислені агрегатні дані, що відповідають

осередкам куба. Чим їх більше, тим швидше виконуються запити до

багатомірного сховища й тим більше об’єм самого сховища. Тому в

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

розумний баланс між компактністю й продуктивністю.

Для визначення к ількості агрегат ів й їхнього обчислення

треба запустити Создание статистичесхих схем в пункте

Куб — для створення багатомірного сховища.

У першій діалоговій панелі вказати спосіб зберігання даних — MOLAP,

ROLAP або HOLAP.

Вибрати, яка повинна бути продуктивність при виконанні запитів (або

майбутній максимальний об’єм сховища).

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

продуктивності від об’єму сховища (Рис. 13).

Рис. 13. Визначення кількості агрегатів

15

Далі необхідно обчислити самі агрегатні дані. Це можна зробити як у тому

ж майстрі створення сховища, так й у редакторі кубів (Рис. 14).

Рис. 14. Обчислення агрегатних даних

Тепер, коли куб готовий, можна переглянути його у редакторі кубів (для

цього потр ібно вибрати закладку Обзор та добавити

в ідповідні праметри , Рис . 15) .

16

Рис. 15. Перегляд перетинів куба

У редакторі кубів ми можемо переглядати різн і двомірні

перетини куба , переміщаючи імена вимір ів на горизонтальну

й вертикальну осі , а також приховуючи й розкриваючи рівні .

Це найпростіший з і способів перегляду кубів .

4. Завдання на роботу

1. Підготуватися до опитування за матеріалом лекцій та короткими

теоретичними даними.

2. Створити проект, назвавши його за номером бригади та

виконуючими студентами.

3. Створити багатомірну базу даних на основі Northwind_Mart та

описати джерело даних.

4. Створити вимір на підставі Time_Dim. Задати ієрархію: YQMDW

5. Зберегти внесені зміни.

6. Створити колективний вимір на підставі таблиці Product_Dim з

дома рівнями ієрархії— CategoryName, ProductName. Та

властивостями членів виміру рівня ProductName виберемо поля

SupplierName й ListUnitPrice.

7. Створити незбалансований вимір на підставі таблиці

CustomerView_Dim з ієрархіями Country, Region1, City,

17

CompanyName. В розділі Member Properties рівня Company Name

мають бути поля Contact Name й Contact Title. Рівень Region1 з

властивістю HideMember I f рівним Paren tName

8. Створити вимір „Батько - нащадок” на підставі таблиці

Employee_Dim з полем Repor t s_To - Родильский

атрибут .

9. Створити куб з вимірами Employee , Time , Product й

Customer . Таблиця фактів - Sa l es_Fac t , поля (на основі

яких обчислюються міри куба ) : Line I t em Tota l , Line

I t em Quant i t y й Line I t em Discount

10. Створити вираз , що обчислюють , Discounted Total. Вираз

[Measures].[Line Item Total] - [Measures].[Line Item Discount]

11. Визначити кільк ість агрегат ів .

12. Обчислити агрегатні дані.

13. Продемонструвати готовий куб викладачу.

14. Підготувати звіт з скріншотами.

5.Контрольні запитання

1. Як ви розумієте OLAP?

2. Які переваги OLAP перед ІСК?

3. Які мінуси OLAP?

4. Правила оцінки програмних продуктів класу OLAP.

5. Що таке стійка продуктивність?

6. Що таке вимір і для чого він використовується?

7. Що таке часний вимір?

8. Що таке колективний вимір?

9. Що таке ієрархія?

10. Які відмінності між регулярними та часними вимірами?

11. Поясніть термін OLAP - куб?

12. Як взаємодіють між собою мітки ієрархія?

13. Яким чином ієрархії впливають на продуктивність OLAP -

систем?

18

14. Як реалізувати подання географічних даних не

використовуючи незбалансованих ієрархій?

15. Обґрунтуйте віднесення ієрархії типу «батько-нащадок» до

незбалансованих ієрархій?

16. Як реалізується багатомірність в OLAP-додатках?

17. Для чого використовують колективні виміри?

18. В чому різниця між OLAP i ROLAP?

19. Які особливості ієрархії „батько-нащадок”?

20. Яка можлива розмірність OLAP - куба?

21. Який процес формування кубів ?

22. Накресліть приклад куба та представте його у вигляді таблиці?

23. Що необхідно для створення кубів?

24. Які особливості при використанні обчислюваних виразів?

25. Дайте характеристику MOLAP?

26. Дайте характеристику ROLAP?

27. Дайте характеристику HOLAP?

28. Для чого проводиться обрахунок кількості агрегатів?

29. Які особливості схеми зірки?

19

Лабораторна робота 2

Робота з MS Excel , як і з клієнтом Analys i s Server .

1 . Мета робот и

Метою роботи є вивчення роботи з Excel , як і з клієнтом

Analys i s Server .

2 . Склад робочого місця

2 .1 . Устаткування : IBM-сумісний персональний комп 'ютер

(ПК, з мінімальними вимогами: 128Мб байт ОЗУ, 4.5 Гб байт ПЗУ, процесор

РІІІ) .

2 .2 . Програмне забезпечення : операційна система Windows

Windows Se rver 2003 , MS SQL Server 2005 , Microsof t Visua l

S tud io2005 .

3. Методичні вказівки по роботі з MS Excel

Створення зведеної таблиці з даними OLAP-кубів

Розглянемо створення зведеної таблиці, що містить дані готового OLAP-

куба.

Для цього запустимо Microsoft Excel і з меню Данные виберемо

Сводная таблица .

Після цього управліннябуде передано майстрові. У першій діалоговій панелі

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

зовнішнє джерело даних. Вкажемо, що це за джерело, нажавши кнопку

Получить данные у наступній діалоговій панелі, що приведе до запуску

додатка Microsoft Query.

Виберемо закладку Кубы OLAP й, якщо в операційній системі ще немає

опису відповідного джерела даних, створимо його (Рис. 1).

20

Рис. 1. Опис джерела даних

У процесі створення джерела даних укажемо його ім'я, виберемо OLE DB-

провайдер (у нашому випадку — Microsof t OLE DB Prov ider fo r

Analys i s Serv ices 9 .0 , оскільки ми використовуємо Microsof t SQL

Server 2005) і натиснемо на кнопку Связь (Рис. 2).

21

Рис. 2. Вибір провайдера даних

Далі вводимо імя сервера , див . Рис . 3 .

Рис. 3. Вибір OLAP-сервера

22

Наступний крок - виберемо ім'я багатомірної бази даних, у якій

зберігається OLAP-куб (Рис. 4).

Рис. 4. Вибір багатомірної бази даних

Визначивши джерело даних, виберемо куб, що ми будемо відображати у

зведеній таблиці (Рис. 5).

Рис. 5. Вибір куба для відображення у зведеній таблиці

23

Після цього можна натиснути кнопку OK. У результаті ми одержимо

порожню зведену таблицю, вид якої в Excel показаний на Рис. 6.

Рис. 6. Зведена таблиця в Excel

Для подальших маніпуляцій нам буде потрібно панель інструментів

PivotTable. У випадку з Excel 2000 користуватися нею зручніше, якщо вона

не закріплена з краю вікна Excel, а вільно переміщається по екрану, у

противному випадку деякі потрібні нам елементи цієї панелі виявляться

недоступні.

Слід зазначити, що, коли фокус введення перебуває на самій зведеній таблиці

(для чого досить клацнути по ній мишею), панель PivotTable в Excel 2000

містить кнопки з назвами вимірів і мір куба. Відзначимо, що вони

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

на кнопці, їх можна побачити на спливаючих підказках.

При зсуві фокуса введення в інше місце аркуша ці кнопки зникають.

В Excel 2002 діалогова панель PivotTable виглядає інакше — вона не містить

кнопок з іменами вимірів і мір. Їхній список подається в окремій панелі

PivotTable Field List (Рис. 7).

24

Рис. 7. Зведена таблиця в Excel 2002

Тепер нам необхідно визначити, які з мір ми хочемо відобразити у

зведеній таблиці. Для цього досить перенести мишею кнопку (у випадку

Excel 2002 — відповідний елемент зі списку) з найменуванням потрібної

міри в область даних (Data Area; на Рис. 7 вона позначена написом Drop

Data Items Here). Результат цієї маніпуляції представлений на Рис. 8.

Рис. 8. Вибір міри для відображення у зведеній таблиці

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

рядків, стовпців і сторінок (іноді останні називаються фільтрами). У

загальному випадку зведена таблиця є тривимірної, і можна вважати, що

третій вимір розташований перпендикулярно екрану, а ми спостерігаємо

перетини, паралельні площини екрана й обумовлені тим, яка «сторінка»

обрана для відображення. Здійснити фільтрацію можна шляхом

25

перетаскування мишею відповідних кнопок з панелі інструментів

PivotTable (у випадку Excel 2002 — відповідних елементів з панелі

PivotTable Field List) на області рядків, стовпців і сторінок зведеної

таблиці — Row Area, Column Area й Page Area. Результат цієї маніпуляції

показаний на Рис. 9.

Рис. 9. Готова зведена таблиця

Отже, ми відобразили у зведеній таблиці Excel вміст OLAP-куба. Тепер цим

відображенням можна маніпулювати.

Маніпуляція відображенням даних у зведеній таблиці. Створення

зведених діаграм з даними OLAP-кубів

Для виведення більш докладних даних, пов'язані з одним зі членів одного з

відображуваних вимірів, можна двічі клацнути по осередку із цим значенням

і відобразити члени наступного рівня даного виміру (ця операція називається

drill-down). Результат подвійного кліку на осередку A5, показане на Рис. 10.

26

Рис. 10. Результат операції drill-down

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

зведеній таблиці, варто вибрати осередок з ім'ям відповідного виміру

(наприклад, осередок A4) і натиснути на панелі інструментів PivotTable

кнопку Show Detail (Рис. 11).

Рис. 11. Відображення наступного рівня ієрархії виміру

Для ручного визначення, які члени виміру повинні бути відображені у

зведеній таблиці; для цього можна натиснути кнопку висновку

відповідного списку, що випадає, у правій частині осередку з ім'ям виміру

(Рис. 12).

27

Рис. 12. Вибір відображуваних членів виміру

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

окремий додатковий вимір Data. За замовчуванням воно розташовується

на осі рядків, але може бути перенесено й на вісь стовпців (Рис. 13).

Рис. 13. Відображення декількох мір у зведеній таблиці

Якщо у зведеній таблиці залишити тільки одну міру, перенесши, що

залишилися назад на панель інструментів PivotTables, вимір Data зникне.

Відзначимо, що за допомогою одного з доступних в Excel шаблонів

оформлення можна змінити оформлення зведеної таблиці.

28

Для зміни інших параметрів відображення даних у зведеній таблиці. треба

вибрати на панелі інструментів PivotTables пункти меню PivotTable | Table

Options або PivotTable | Field Settings.

При необхідності в Excel можна побудувати зведену діаграму,

синхронізовану зі зведеною таблицею.

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

PivotTables й, якщо потрібно, відредагувати зовнішній вигляд діаграми (Рис.

14).

Рис. 14. Зведена діаграма з даними OLAP-куба

Відзначимо, що за допомогою панелей інструментів PivotTable й PivotTable

FieldList, а також, що випадають списків, на осях і легенді можна управляти

відображенням даних на зведеній діаграмі, наприклад виконувати операцію

drill-down; при цьому зведена таблиця буде мінятися синхронно з діаграмою.

Створення локальних OLAP-кубів

Щоб створити локальний OLAP-куб на основі серверного куба, треба на

панелі інструментів PivotTables вибрати пункт меню PivotTable | Offline

OLAP в Excel 2002 (в Excel 2000 йому відповідав пункт меню PivotTable |

Client-Server Settings) і нажати кнопку Create offline data file (Рис. 15; в Excel

2000 — Create Local Cube).

29

Рис. 15. Діалогова панель Offline OLAP Settings

Далі варто вибрати виміри і їхні рівні, а також міри, які будуть присутні в

локальному кубі (Рис. 16).

Рис. 16. Вибір визмірів і мір для локального куба

Крім вибору вимірів, їхніх рівнів і мір можна внести й інші обмеження в

набір даних, що буде втримуватися в локальному кубі, вибравши набір

членів змін, що беруть участь у його формуванні (Рис. 17).

30

Рис. 17. Вибір членів измірений для локального куба

Зберегти локальний куб у файлі з розширенням *.cub. Відзначимо, що цей

файл є відокремленим: його можна переглядати на будь-якому комп'ютері,

оснащеному як Microsoft Excel 2002, так й Microsoft Excel 2000, незалежно

від наявності на ньому Microsoft SQL Server Analysis Services або їхньої

клієнтської частини.

4. Завдання на роботу

1. Підготуватися до опитування за матеріалом лекцій та короткими

теоретичними даними.

2. Отримати данні з створенного кубу в зведену таблицю.

3. Перенести на Лист поля згідно номеру варіанта

4. Вивести по 10 осередків кожного з полів.

5. Побудувати діаграму на основі отриманих даних.

6. Продемонструвати зв’язок таблиці та осередків.

7. Створити локальний куб, вибравши міри вказані для даного

варіанту.

8. Продемонструвати готовий куб викладачу.

9. Підготувати звіт з скріншотами.

31 №

варіанта 1 2 3 4 5 6 7 8

поля

сторінок адреса

назва

компанії місто країна

контактна

особа регіон день тижня місяць

поля

стовпців місто адреса

назва

компанії місто країна

контактна

особа регіон

день

тижня

поля

стрічок 1

назва

компанії місто адреса

назва

компанії регіон країна

контактна

особа тиждень

поля

стрічок 2

день

тижня квартал

день

тижня рік

день

тижня

назва

компанії місяць квартал

елементи

данних

line item

total

line item

quantily

line item

discount

line item

total

line item

quantily

line item

total

обчислюваний

елемент

line item

total

5.Контрольні запитання

1. Який з компонентів Microsoft Office, призначений для

створення OLAP-клієнтів?

2. Який компонент, що може бути використаний для перегляду

OLAP-кубів в Microsoft Office?

3. Що таке PivotTable List ?

4. За якими критеріями оцінюють існуючі продукти?

5. Які особливості роботи в Microsoft Office?

6. Який з компонентів Microsoft Office, призначений для

створення OLAP-клієнтів?

7. Який компонент, що може бути використаний для перегляду




10. Які особливості роботи в Microsoft Office?

11. Які особливості створення кубів в Microsoft Office,?

12. Який компонент, що може бути використаний для створення




15. Як зберегти куб в Excel?

32

Вступ

Сучасний рівень розвитку апаратних і програмних засобів з певного

часу уможливив повсюдне ведення баз даних оперативної інформації на

різних рівнях управління. У процесі своєї діяльності промислові

підприємства, корпорації, відомчі структури, органи державної влади й

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

потенційні можливості по викорнистанню корисної аналітичної

інформації, на основі якої можна виявляти приховані тенденції,

вибудовувати стратегію розвитку, знаходити нові рішення.

В останні роки у світі оформився ряд нових концепцій зберігання й

аналізу корпоративних даних:

1) Сховища даних, або Склади даних (Data Warehouse) [15, 5];

2) Оперативна аналітична обробка (On-Line Analytical Processing, OLAP)

[11, 6, 10];

3) Інтелектуальний аналіз даних - ІАД(Data Mining)[17,19,23,3].

Технології OLAP тісно пов'язані з технологіями побудови Data

Warehouse і методами інтелектуальної обробки - Data Mining. Тому

найкращим варіантом є комплексний підхід до їхнього впровадження.

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

уваги надзвичайну вагу проблеми належноі підготовки студентів ІТ-

спеціальностей з цього предмету.

Зокрема комплексний підхід до розробки, організації та проведення

лабораторних робіт по данному курсу.

В світлі вище зазначенного доцільно використання програмних

продуктів з максимально широким спектром застосування та різних

способів реалізації.

33

1.Теоретичні основи аналітичної обробки інформації

1.1.Способи аналітичної обробки даних

Для того щоб існуючі сховища даних сприяли прийняттю

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

в потрібній формі, тобто він повинен мати розвинені інструменти доступу

до даних сховища і їхньої обробки.

Дуже часто інформаційно-аналітичні системи, створені з розрахунку на

безпосереднє використання особами, що приймають рішення, виявляються

надзвичайно прості в застосуванні, але жорстко обмежені у

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

Інформаційними Системами Керівника (ІСК), або Executive Information

Systems (EIS) [3]. Вони містять у собі визначені безліч запитів й, будучи

достатніми для повсякденного огляду, нездатні відповісти на всі питання

до наявних даних, які можуть виникнути при прийнятті рішень.

Результатом роботи такої системи, як правило, є багатосторінкові звіти,

після ретельного вивчення яких в аналітика з'являється нова серія питань.

Однак кожен новий запит, непередбачений при проектуванні такої

системи, повинен бути спочатку формально описаний, закодований

програмістом і тільки потім виконаний. Час очікування в такому випадку

може становити години й дні, що не завжди прийнятно. Таким чином,

зовнішня простота статичних СППР, за яку активно бореться більшість

замовників інформаційно-аналітичних систем, обертається

катастрофічною втратою гнучкості.

Динамічні СППР орієнтовані на обробку нерегламентованих (ad hoc)

запитів аналітиків до даних. Найбільше грунтовно вимоги до таких систем

розглянув E. F. Codd у статті [11], що поклала основу концепції OLAP.

Робота аналітиків із цими системами полягає в інтерактивній

послідовності формування запитів і вивчення їхніх результатів.

Але динамічні СППР можуть діяти не тільки в області оперативної

аналітичної обробки (OLAP); підтримка прийняття управлінських рішень

на основі накопичених даних може виконуватися в трьох базових сферах

[21].

1. Сфера деталізованих даних. Це область дії більшості систем,

націлених на пошук інформації. У більшості випадків реляційні СУБД

відмінно справляються з виникаючими завданнями. Загальновизнаним

стандартом мови маніпулювання реляційними даними є SQL.

Інформаційно-пошукові системи, що забезпечують інтерфейс кінцевого

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

34

використовуватися як надбудови як над окремими базами даних

транзакційних систем, так і над загальним сховищем даних.

2. Сфера агрегованних показників. Комплексний погляд на зібрану в

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

подання й багатомірний аналіз є завданнями систем оперативної

аналітичної обробки даних (OLAP) [11, 10, 6]. Тут можна орієнтуватися на

спеціальні багатомірні СУБД [6], або залишатися в рамках реляційних

технологій. В іншому випадку заздалегідь агрегованні дані можна збирати

в БД зіркоподібного виді, або агрегація інформації може вироблятися «з

льоту», у процесі сканування деталізованих таблиць реляційної БД.

3. Сфера закономірностей. Інтелектуальна обробка проводиться

методами інтелектуального аналізу даних (ІАД, Data Mining) [19, 25],

головними завданнями яких є пошук функціональних і логічних

закономірностей у накопиченій інформації, побудова моделей і правил, які

пояснюють знайдені аноРисії і/або прогнозують розвиток деяких процесів.

Деякі автори [21] виділяють в окрему область аналіз відхилень

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

біржових курсів). Як приклад можна навести статистичний аналіз

динамічних рядів. Частіше цей тип аналізу відносять до сфери

закономірностей.

Повна структура інформаційно-аналітичної системи, побудованої на

основі сховища даних, показана на Рис. 1. У конкретних реалізаціях окремі

компоненти цієї схеми часто відсутні.

Рис. 1. Повна структура корпоративної інформаційно-аналітичної

системи (ІАС)

35

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

В основі концепції OLAP лежить принцип багатомірного подання

даних. В 1993 році в статті [11] E. F. Codd розглянув недоліки реляційної

моделі, у першу чергу вказавши на неможливість "поєднувати,

переглядати й аналізувати дані з погляду множинності вимірів, тобто

самим зрозумілим для корпоративних аналітиків способом", і визначив

загальні вимоги до систем OLAP, що розширюють функціональність

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

характеристик.

У великій кількості публікацій абревіатурою OLAP позначається не

тільки багатомірний погляд на дані, але й зберігання самих даних у

багатомірній БД [6]. Загалом, це неправильно, оскільки сам Кодд

відзначає, що "Реляційні БД були, є й будуть найбільш підходящою

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

новій технології БД, а, скоріше, у засобах аналізу, що доповнюють функції

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

види інтелектуального аналізу, властиві OLAP". Така плутанина приводить

до протиставлень на зразок "OLAP або ROLAP", що не зовсім коректно,

оскільки ROLAP (реляційний OLAP) на концептуальному рівні підтримує

OLAP-функціональність. Кращим здається використання для OLAP на

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

в [4, 9].

По Кодду, багатомірне концептуальне подання (multi-dimensional

conceptual view) являє собоюобою множинну перспективу, що складається

з декількох незалежних вимірів, уздовж яких можуть бути проаналізовані

певні сукупності даних. Одночасний аналіз по декількох вимірах

визначається як багатомірний аналіз. Кожен вимір включає напрямок

консолідації даних, що складаються із серії послідовних рівнів

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

агрегації даних по відповідному виміру. Так, вимір Виконавець може

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

"підприємство - підрозділ - відділ - службовець". Вимір Час може навіть

включати два напрямки консолідації - "рік - квартали - місяць - день" й

"тиждень - день", оскільки рахунок часу по місяцях і по тижнях

несумісний. У цьому випадку стає можливим довільний вибір бажаного

рівня деталізації інформації з кожного з вимірів.

Операція спуску (drilling down) відповідає рухові від вищих щаблів

консолідації до нижчих; а операція підйому (rolling up) означає рух від

нижчих рівнів до вищого (Рис. 2).

36

Рис. 2. Виміри і напрямки консолідації даних

1.3.Вимоги до засобів оперативної аналітичної обробки

Кодд визначив 12 правил, яким повинен задовольняти програмний

продукт класу OLAP (табл. 1).

Таблиця 1 Правила оцінки програмних продуктів класу OLAP

1.

Багатомірне

концептуальне

подання даних

(Multi-Dimensional

Conceptual View)

Концептуальне подання моделі даних у

продукті OLAP повинне бути багатомірним

по своїй природі, тобто дозволяти

аналітикам виконувати інтуїтивні операції

"аналізу вздовж і поперек" ("slice and dice"),

обертання (rotate) і розміщення (pivot)

напрямків консолідації.

2. Прозорість

(Transparency)

Користувач не повинен знати про те, які

конкретні засоби використаються для

зберігання й обробки даних, як дані

організовані й звідки беруться.

3. Доступність

(Accessibility)

Аналітик повинен мати можливость

виконувати аналіз у рамках загальної

концептуальної схеми, але при цьому дані

можуть залишатися під управлінням старої

СУБД, будучи при цьому прив'язаними до

загальної аналітичної моделі. Тобто

інструментарій OLAP повинен накладати

свою логічну схему на фізичні масиви

даних, виконуючи всі перетворення, що

вимагаються для забезпечення єдиного,

погодженого й цілісного погляду

користувача на інформацію.

37

Таблиця 1(продовження) Правила оцінки програмних продуктів класу

OLAP

4. Стійка

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

(Consistent Reporting

Performance)

Зі збільшенням числа вимірів і розмірів

бази даних аналитики не повинні

зіштовхнутися з зменшенням

продуктивності. Стійка продуктивність

необхідна для підтримки простоти

використання OLAP для кінцевого

користувача.

5. Клієнт - серверна

архітектура (Client-

Server Architecture)

Більша частина даних, що вимагають

оперативної аналітичної обробки,

зберігається в мэйнфреймових системах, а

використовується персональними

комп'ютерами. Тому одна з вимог є

здатність продуктів OLAP працювати в

середовищі клієнт-сервер. Головною ідеєю

є те, що серверний компонент інструмента

OLAP поповинен бути досить

інтелектуальним і мати здатність

вибудовувати загальну концептуальну

схему на основі узагальнення й

консолідації різних логічних і фізичних

схем корпоративних баз даних для

забезпечення ефекту прозорості.

6. Рівноправність

вимірів (Generic

Dimensionality)

Всі виміри даних повинні бути рівноправні.

Додаткові характеристики можуть бути

надані окремим вимірам. Базова структура

даних, формули й формати звітів не

повинні опиратися на якийсь один вимір.

7. Динамічна обробка

розріджених матриць

(Dynamic Sparse

Matrix Handling)

Інструмент OLAP повинен забезпечувати

оптимальну обробку розріджених матриць.

Швидкість доступу повинна зберігатися не

залежно від розташування осередків даних

і бути постійною величиною для моделей,

що мають різне число вимірів і різну

розрідженість даних.

38

Таблиця 1(продовження) Правила оцінки програмних продуктів класу

OLAP

8. Підтримка

багатокористувацького

режиму (Multi-User

Support)

Часто кілька аналітиків потребують

працювати одночасно з однією

аналітичною моделлю або

створювати різні моделі на основі

одних корпоративних даних.

Інструмент OLAP поповинен

надавати їм конкурентний доступ,

забезпечувати цілісність і захист

даних.

9. Необмежена підтримка

кроссвимірних операцій

(Unrestricted Cross-

dimensional Operations)

Обчислення й маніпуляція даними

по будь-якому числу вимірів не

повинна забороняти або обмежувати

будь-які відношення між осередками

даних. Перетворення, що вимагають

довільного визначення, повинні

задаватися на функціонально повній

формульній мові.

10. Інтуїтивне маніпулювання

даними (Intuitive Data

Manipulation)

Переорієнтація напрямків

консолідації, деталізація даних у

колонках і рядках, агрегація й інші

маніпуляції, властиві структурі

ієрархії напрямків консолідації,

повинні виконуватися в

максимально зручному, природному

й комфортному

користувальницькому інтерфейсі.

11. Гнучкий механізм

генерації звітів (Flexible

Reporting)

Повинні підтримуватися різні

способи візуалізації даних, тобто

звіти повинні представлятися в

будь-якій можливій формі.

12. Необмежена кількість

вимірів і рівнів агрегації

(Unlimited Dimensions and

Aggregation Levels)

Рекомендується дозвіл в кожному

серйозному OLAP інструменті як

мінімум п'ятнадцяти, а краще

двадцяти, вимірів в аналітичній

моделі. Більше того, кожен із цих

вимірів повинне допускати

практично необмежену кількість

певним користувачем рівнів

агрегації по будь-якому напрямку

консолідації.

39

Набір цих вимог, що послужили фактичним визначенням OLAP,

варто розглядати як рекомендаційний, а конкретні продукти оцінювати по

ступені наближення до ідеально повної відповідності всім вимогам.

1.4. Загальний аналіз OLAP

OLAP - це не окремо взятий програмний продукт, не мова

програмування й навіть не конкретна технологія. OLAP - це сукупність

концепцій, принципів і вимог, що лежать в основі програмних продуктів,

що полегшують аналітикам доступ до даних. Для розуміння OLAP

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

даних.

Справа в тому, що аналитики - це особливі споживачі корпоративної

інформації. Завдання аналітика - знаходити закономірності у великих

масивах даних. Тому аналітик не буде звертати уваги на окремо взяті

факти, що в четвер четвертого числа контрагентові Чернову була

продана партія чорного чорнила - йому потрібна інформація про сотні й

тисячі подібних подій. Одиночні факти в базі даних можуть зацікавити,

приміром, бухгалтера або начальника відділу продажу, у компетенції якого

є ця угода. Аналітикові одного запису мало - йому, приміром, можуть

знадобитися всі довори даної філії або представництва за місяць, рік.

Заодно аналітик відкидає непотрібні йому подробиці як ИНН покупця,

його точної адреси й номіра телефону, індексу контракту й тому

подібного. У тойже час дані, які потрібні аналітикові для роботи,

обов'язково містять числові значення - це обумовлено самою сутністю його

діяльності.

Тому аналітикові потрібно багато вибіркових даних, а також носять

характер "набір атрибутів - число". Останнє означає, що аналітик працює

з таблицями наступного типу:

40

Таблиця 2 Приклад аналізованої таблиці

Аргентина Гумові вироби 1990 217

Бразилія Побутова електроніка 1988 313



Бразилія Гумові вироби 1988 515



Венесуела Побутова електроніка 1988 94



Венесуела Гумові вироби 1988 153



Тут "Країна", "Товар", "Рік" є атрибутами, а "Обсяг продажів" - тім

самим числовим значенням. Завданням аналитика - виявлення стійких

взаємозв'язків між атрибутами й числовими параметрами.З таблиці, можна

помітити, що її легко можна перевести в три виміри: по одній з осей

відкладемо країни, по іншій - товари, по третій - роки. Значення в цьому

тривимірному масиві будуть відповідні об’єми продаж.

Рис. 2. Приклад куба

Тривимірне подання таблиці. Сірим сегментом показано, що для

Аргентини в 1988 році даних немає

Саме так такий тривимірний масив у термінах OLAP і називається

кубом. Хоча, з погляду строгої математики кубом такий масив буде далеко

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

бути однаковим, а в кубів OLAP такого обмеження немає. Проте,

незважаючи на ці деталі, термін "куби OLAP" через свою стислість й

образність став загальноприйнятим. Куб OLAP зовсім не обов'язково

41

повинен бути тривимірним. Він може бути й двох-, і багатомірним -

залежно від завдання. Особливо маститим аналітикам може знадобитися

порядка 20 вимірів - і серйозні OLAP-продукти саме на таку кількість і

розраховані. Більше прості персональні додатки підтримують близько 6

вимірів.

1.5. Багатомірне подання в OLAP

У якості мір у тривимірному кубі, зображеному на Рис. 3, використані

суми продажів, а як виміри - година, товар і магазин. Виміри представлені

на певних рівнях угруповання: товари групуються по категоріях, магазини

- по країнах, а дані про годину здійснення операцій - по місяцях. Трохи

пізніше розглянемо рівні угруповання (ієрархії) докладніше.

Рис. 3. Приклад куба

Зокрема в Microsoft SQL Server Analysis Services виміри діляться на

колективні (shared dimensions) і часні (private dimensions).

Колективні виміри — це виміри, які можуть бути використані одночасно в

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

заснований на стандартних даних, застосовуваних при аналізі різних

предметних областей. Типовим прикладом створення таких вимірів може

бути, наприклад, список співробітників компанії. Колективні виміри

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

багатомірній базі даних й є чи вони там взагалі.

Приватні виміри належать конкретному кубу й створюються разом з ним.

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

одній конкретній предметній області.

42

1.6."Розрізування" куба

Навіть тривимірний куб складно відобразити на екрані комп'ютера так,

щоб були видні значення зацікавлених мір. Для візуалізації даних, що

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

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

стовпців.

Двовимірне подання куба можна одержати, "розрізавши" його поперек

однієї або декількох осей (вимірів): ми фіксуємо значення всіх вимірів,

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

осі таблиці (заголовки стовпців) представлено один вимір, у вертикальній

(заголовки рядків) - інше, а в осередках таблиці - значення мір. При цьому

набір мір фактично розглядається як один з вимірів - або вибираємо для

показу одну міру (і тоді можемо розмістити в заголовках рядків і стовпців

два виміри), або показуємо кілька мір (і тоді одну з осей таблиці займуть

назви мір, а іншу - значення єдиного "нерозрізаного" виміру).

На Рис. 4 зображений двовимірний зріз куби для однієї міри - Unit Sales

(продане штук) і двох "нерозрізаних" вимірів - Store (Магазин) і Година

(Time).

Рис. 4. Двовимірний зріз куба для однієї міри

На Рис. 5 представлено лише один "нерозрізаний" вимір - Store, Але тут

відображаються значення декількох мір - Unit Sales (продано штук), Store

Sales (витрати продаж) і Store Cost (витрати магазина).

Рис. 5. Двовимірний зріз куба для декількох мір

Двовимірне подання куба можливо й тоді, коли "нерозрізаними"

залишаються й більше двох вимірів. При цьому на осях зрізу (рядках і

стовпцях) будуть розміщені два або більше виміри - див. Рис. 6.

43

Рис. 6. Двовимірний зріз куба з декількома вимірами на одній осі

1.7.Мітки

Значення, "відкладенні" уздовж вимірів, називаються членами або

мітками (members). Мітки використаються як для "розрізування" куба, так і

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

"нерозрізаним", нас цікавлять не всі значення, а їхня підмножина,

наприклад три міста з декількох десятків. Значення міток відображаються

у двовимірному поданні куба як заголовки рядків і стовпців.

1.8.Ієрархії і рівні

Мітки можуть поєднуватися в ієрархії, що складаються з одного або

декількох рівнів (levels). Наприклад, мітки виміру "Магазин" (Store)

природно поєднуються в ієрархію з рівнями:

All (Світ)

Country (Країна)

State (Штат)

City (Місто)

Store (Магазин).

Відповідно до рівнів ієрархії обчислюються агрегатні значення,

наприклад обсяг продажів для USA (рівень "Country") або для штату

California (рівень "State"). В одному вимірі можна реалізувати більше

однієї ієрархії - скажемо, для часу {Рік, Квартал, Місяць, День} й {Рік,

Тиждень, День}.

Повинні бути заповнені далеко не всі елементи куба: якщо немає

інформації про продажі гумових виробів в Аргентині в 1988 році, значення

у відповідному осередку просто не буде визначено. Зовсім необов'язково

також, щоб додаток OLAP зберігав дані неодмінно в багатомірній

структурі, щоб для користувача ці дані виглядали саме так. До речі саме

44

спеціальним способам компактного зберігання багатомірних даних,

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

використання пам'яті.

Один з істотних моментів, які привели до появи OLAP - продуктивність

й ефективність. Уявимо , що відбувається, коли аналітикові необхідно

одержати інформацію, а засоби OLAP на підприємстві відсутні. Аналітик

самостійно (що малоймовірно) або за допомогою програміста робить

відповідний SQL-запити й одержує дані, що цікавлять, у вигляді звіту або

експортує їх в електронну таблицю. При цьому виникає безліч проблем.

По-перше, аналітик змушений займатися не своєю роботою (SQL-

програмуванням) або чекати, коли за нього завдання виконають

програмісти - все це негативно позначається на продуктивності праці,

підвищуються «штурмівщина», «інфарктно-інсультний рівень» і так далі.

По-друге, один-єдиний звіт або таблиця, як правило, не рятує «гигантов

мысли и отцов руского анализу» - і всю процедуру треба повторювати

знову й знову.

По-третє, як вже з'ясувано, аналитики по -трохи не запитують - їм

потрібно всі й відразу. Це означає (хоча техніка і йде вперед швидкими

кроками), що сервер корпоративної реляційної СУБД, до якого звертається

аналітик, може «задуматься» глибоко й надовго, заблокувавши інші

транзакції.

Концепція OLAP з'явилася саме для вирішення подібних проблем.

Куби OLAP являють собою, по суті, мітки-звіти. Розрізаючи позначки-

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

його "звичайні" двовимірні звіти (це не обов'язково звіти у звичайному

розумінні цього терміна - мова йде про структури даних з такими ж

функціями). Переваги кубів очевидні - дані необхідно запросити з

реляційної СУБД усього один раз - при побудові куба. Оскільки

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

змінюється "на льоту", сформований куб є актуальним протягом досить

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

сервера реляційної СУБД (немає запитів з тисячами й мільйонами рядків

відповідей), але й різко підвищується швидкість доступу до даних для

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

підвищується й за рахунок підрахунку проміжних сум ієрархій й інших

агрегованних значень у момент побудови куба. Тобто, якщо спочатку наші

дані містили інформацію про денний виторг по конкретному товару в

окремо взятому магазині, то при формуванні куба OLAP-додаток рахує

підсумкові суми для різних рівнів ієрархій (тижнів і місяців, міст і країн).

Звичайно, за підвищення таким способом продуктивності треба

платити. Як говорять, що структура даних просто "вибухає" - куб OLAP

може займати в десятки, і навіть сотні разів більше місця, ніж вихідні дані.

45

1.9.Архітектура OLAP-додатків

Все, що говорилося вище про OLAP, по суті, відносилось до

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

компетенції ні кінцевого користувача, ні розробників інструмента, яким

клієнт користується.

Багатомірність в OLAP-додатках може бути розділена на три рівні:

Багатомірне подання даних - засобу кінцевого користувача, що

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

багатомірного подання абстрагована від фізичної структури даних і

сприймає дані як багатомірні.

Багатомірна обробка - засіб (мова) формулювання багатомірних запитів

(традиційна реляційна мова SQL тут виявляється непридатна) і процесор,

що вміє обробити й виконати такий запит.

Багатомірне зберігання - засобу фізичної організації даних, що

забезпечують ефективне виконання багатомірних запитів.

Перші два рівні в обов'язковому порядку присутні у всіх OLAP-

засобах. Третій рівень, хоча і є широко розповсюдженим, не обов'язковий,

тому що дані для багатомірного подання можуть витягатися й зі звичайних

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

транслює багатомірні запити в SQL-запити, які виконуються реляційною

СУБД.

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

багатомірного подання даних, OLAP-клієнт (наприклад, Pivot Tables в

Excel 2000 фірми Microsoft або ProClarity фірми Knosys), або багатомірну

серверну СУБД, OLAP-сервер (наприклад, Oracle Express Server або

Microsoft OLAP Services).

Сфера багатомірної обробки звичайно вбудований в OLAP-клієнт й/або

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

компонент Pivot Table Service фірми Microsoft.

46

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

У цей час на ринку присутня велика кількість продуктів, які в тій або

іншій мірі забезпечують функціональність OLAP. Близько 30 найбільш

відомих перераховані в списку[26]. Забезпечуючи багатомірне

концептуальне подання з боку користувацького інтерфейсу до вихідної

бази даних, всі продукти OLAP діляться на три класи по типу вихідної БД.

1. Перші системи оперативної аналітичної обробки (наприклад, Essbase

компанії Arbor Software [11], Oracle Express Server компанії Oracle [6])

віносились до класу MOLAP, тобто могли працювати тільки зі своїми

власними багатомірними базами даних. Які ґрунтуються на патентованих

технологіях для багатомірних СУБД й є самими дорогими. Ці системи

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

серверного компонента, власний інтегрований клієнтський інтерфейс, або

використають для зв'язку з користувачем зовнішні програми роботи з

електронними таблицями. Для обслуговування таких систем потрібен

спеціальний штат співробітників, що займаються установкою, супроводом

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

2. Системи оперативної аналітичної обробки реляційних даних (ROLAP)

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

формі [13, 14, 22], забезпечуючи перетворення інформації в багатомірну

модель через проміжні метаданні. До цього класу відносяться DSS Suite

компанії MicroStrategy, MetaCube компанії Informix, DecisionSuite компанії

Information Advantage й інші. Програмний комплекс Инфовизор [1],

розроблений у Росії, в Івановському державному енергетичному

університеті, також є системою цього класу. ROLAP-системи добре

пристосовані для роботи з великими сховищами. Подібно системам

MOLAP, які вимагають значних витрат на обслуговування фахівцями з

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

роботи.

3. Гібридні системи (Hybrid OLAP, HOLAP) розроблені з метою

поєднання достоїнств і мінімізації недоліків, властивим попереднім

класам. До цього класу відноситься Media/MR компанії Speedware [9]. За

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

відповіді MOLAP з постійним доступом до реальних данних, властивим

ROLAP.

Крім перерахованих існує ще один клас - інструменти генерації запитів

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

зовнішніми засобами, що виконують такі функції. Це добре розвинені

системи здійснюють вибірку даних з вихідних джерел, перетворюють їх і

поміщають у динамічну багатомірну БД, що функціонує на клієнтській

47

станції кінцевого користувача. Основними представниками цього класу є

BusinessObjects одноіменної компанії [18], BrioQuery компанії Brio

Technology [7] й PowerPlay компанії Cognos [7].

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

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

дані організовані не у формі реляційних таблиць, а у вигляді

впорядкованих багатомірних масивів:

1) гіперкубів (всі збережені в БД осередки повинні мати однакову

вимірність, тобто перебувати в максимально повному базисі вимірів)

2) полікубів (кожна змінна зберігається із власним набором вимірів, і

всі пов'язані із цим складності обробки перекладаються на внутрішні

механізми системи).

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

обробки має наступні переваги.

1. У випадку використання багатомірних СУБД пошук і вибірка даних

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

погляді на реляційну базу даних, тому що багатомірна база даних

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

оптимізований доступ до запитуваних осередків.

2. Багатомірні СУБД легко справляються із завданнями включення в

інформаційну модель різноманітних вбудованих функцій, тоді як

об'єктивно існуючі обмеження мови SQL роблять виконання цих завдань

на основі реляційних СУБД досить складним, а іноді й неможливим.

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

1. Багатомірні СУБД не дозволяють працювати з великими базами даних.

До того ж за рахунок денормалізації й попередньо виконаної агрегації

обсяг даних у багатомірній базі, як правило, відповідає (по оцінці Кодда

[11]) в 2.5-100 разів меншому обсягу вихідних деталізованих даних.

2. Багатомірні СУБД у порівнянні з реляційними дуже неефективно

використають зовнішню пам'ять. У переважній більшості випадків

інформаційний гіперкуб є сильно розрідженим, а оскільки дані

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

видалити тільки за рахунок вибору оптимального порядку сортування, що

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

навіть у цьому випадку проблема вирішується тільки частково. Крім того,

оптиРисьний з погляду зберігання розріджених даних порядок сортування

швидше за все не буде збігатися з порядком, що найчастіше

48

використається в запитах. Тому в реальних системах доводити шукати

компроміс між швидкодією й надмірністю дискового простору, зайнятого

базою даних.

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

наступних умовах.

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

декількох гігабайт), тобто рівень агрегації даних досить високий.

2. Набір інформаційних вимірів стабільний (оскільки будь-яка зміна в

їхній структурі майже завжди вимагає повної перебудови гіперкуба).

3. Час відповіді системи на нерегламентовані запити є найбільш

критичним параметром.

4. Потрібне широке використання складних вбудованих функцій для

виконання кроссмірних обчислень над осередками гіперкуба, у тому числі

можливість написання користувацьких функцій.

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

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

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

1. У більшості випадків корпоративні сховища даних реалізуються

засобами реляційних СУБД, і інструменти ROLAP дозволяють робити

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

критичним параметром, як у випадку MOLAP.

2. У випадку змінної розмірності задачи, коли зміни в структуру вимірів

доводиться вносити досить часто, ROLAP системи з динамічним поданням

розмірності є оптиРисьним рішенням, тому що в них такі модифікації не

вимагають фізичної реорганізації БД.

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

даних і можливості розмежування прав доступу.

Головний недолік ROLAP у порівнянні з багатомірними СУБД - менша

продуктивність. Для забезпечення продуктивності, порівнянної з MOLAP,

реляційні системи вимагають ретельного пророблення схеми бази даних і

настроювання індексів, тобто більших зусиль із боку адміністраторів БД.

Тільки при використанні зіркоподібних схем продуктивність гарно

настроєних реляційних систем може бути наближена до продуктивності

систем на основі багатомірних баз даних.

Опису схеми зірки (star schema) і рекомендаціям з її застосування

повністю присвячені роботи [14, 22, 16]. Її ідея полягає в тому, що є

таблиці для кожного виміру, а всі факти розміщенні в одній таблиці,

49

індексовану множинним ключем, складеним із ключів окремих вимірів

(Рис. 7). Кожен промінь схеми зірки задає, у термінології Кодда, напрямок

консолідації даних по відповідному вимірі.

Рис. 7. Приклад схеми "зірки"

У складних завданнях з багаторівневими вимірами має сенс звернутися

до розширень схеми зірки - схемі сузір'я (fact constellation schema) і схемі

сніжинки (snowflake schema) [22]. У цих випадках окремі таблиці фактів

створюються для можливих сполучень рівнів узагальнень різних вимірів

(Рис. 8). Це дозволяє досягти кращої продуктивності, але часто приводить

до надмірності даних і до значних ускладнень у структурі бази даних, у

якій виявляється величезна кількість таблиць фактів.

Рис. 8. Приклад схеми "сніжинки" (фрагмент для одного виміру)

Збільшення числа таблиць фактів у базі даних може виникати не тільки

із множинності рівнів різних вимірів, алі й з обставини, що в загальному

випадку факти мають різну кілікість вимірів. При абстрагуванні від

окремих вимірів користувач повинен одержувати проекцію максимально

повного гіперкуба, причому далеко не завжди значення показників у ній

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

при великій кількості незалежних вимірів необхідно підтримувати безліч

таблиць фактів, що відповідають кожному можливому сполученню

50

обраних у запиті вимірів, що також приводить до неощадливого

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

БД схеми зірки із зовнішніх джерел і складностям адміністрування.

Частково вирішують цю проблему розширення мови SQL (оператори

"GROUP BY CUBE", "GROUP BY ROLLUP" й "GROUP BY GROUPING

SETS"); крім того, автори статей [14, 16] пропонують механізм пошуку

компромісу між надмірністю й швидкодією, рекомендуючи створювати

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

значень осередків яких не можуть бути отримані за допомогою наступної

агрегації більше повних таблиць фактів (Рис.9).

Рис. 9. Таблиці фактів для різних сполучень вимірів у запиті

У кожному разі, якщо багатомірна модель реалізується у вигляді

реляційної бази даних, варто створювати "довгі" й "вузькі" таблиці фактів і

порівняно невеликі й "широкі" таблиці вимірів. Таблиці фактів містять

чисельні значення осередків гіперкуба, а інші таблиці визначають

утримуючі їхній багатомірний базис вимірів. Частину інформації можна

одержувати за допомогою динамічної агрегації даних, розподілених по

незіркоподібних нормалізованих структурах, хоча при цьому варто

пам'ятати, що запити, що включають агрегацію, при високонормалізованій

структурі БД можуть виконуватися досить повільно.

Орієнтація на подання багатомірної інформації за допомогою

зіркоподібних реляційних моделей дозволяє позбутися від проблеми

оптимізації зберігання розріджених матриць, що гостро стоїть перед

багатомірними СУБД (де проблема розрідженості вирішується

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

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

ключі - посилання на таблиці вимірів, неіснуючі значення просто не

включаються в таблицю фактів.

51

1.13.Інтелектуальний аналіз даних

ІАД (Data Mining) - це процес підтримки прийняття рішень, заснуваній

на пошуку в даних прихованих закономірностей (шаблонів інформації).

При цьому накопичені відомості автоматично узагальнюються до

інформації, що може бути охарактеризована як знання.

У загальному випадку процес іАД складається із трьох стадій [19] (Рис.

10):

1) виявлення закономірностей (вільний пошук);

2) використання виявлених закономірностей для прогнозування невідомих

значень (прогностичне моделювання);

3) аналіз виключень, призначений для виявлення й тлумачення аномалій у

знайдених закономірностях.

Іноді в явному виді виділяють проміжну стадію перевірки вірогідності

знайдених закономірностей між їхнім знаходженням і використанням

(стадія валидации).

Рис. 10. Стадії процесу інтелектуального аналізу даних

Всі методи ІАД розділяються на дві більші групи за принципом роботи

з вихідними навчальними даними [19].

1. У першому випадку вихідні дані можуть зберігатися в явному

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

моделювання й/або аналізу виключень; це так названі методи міркувань на

основі аналізу прецедентів. Головною проблемою цієї групи методів є

ускладненість їхнього використання на великих обсягах даних, хоча саме

при аналізі великих сховищ дані методи ІАД приносять найбільшу

користь.

2. В іншому випадку інформація спочатку витягається з первинних даних

і перетворюється в деякі формальні конструкції (їхній вид залежить від

конкретного методу). Відповідно до попередньої класифікації, цей етап

52

виконується на стадії вільного пошуку, що в методів першої групи в

принципі відсутній. Таким чином, для прогностичного моделювання й

аналізу виключень використовуються результати цієї стадії, які набагато

компактніші, чим самі масиви вихідних даних. При цьому отримані

конструкції можуть бути або "прозорими", або "чорними ящиками".

Дві ці групи й приклади вхідних у них методів представлені на Рис. 11.

Рис. 11. Класифікація технологічних методів ІАД

1.14.Інтеграція OLAP й ІАД

Оперативна аналітична обробка й інтелектуальний аналіз даних - дві

складові частини процесу підтримки прийняття рішень. Але сьогодні

більшість систем OLAP загострює увагу тільки на забезпеченні доступу до

багатомірним даних, а більшість засобів ІАД, що працюють у сфері

закономірностей, мають справу з одномірними перспективами даних. Ці

два види аналізу повинні бути тісно об'єднані, тобто системи OLAP

повинні фокусуватися не тільки на доступі, алі й на пошуку

закономірностей. Як помітив N. Raden, "багато компаній створили ...

прекрасні сховища даних, ідеально розклавши по поличках гори

невикористаної інформації, що сама по собі не забезпечує ні швидкої, ні

досить грамотної реакції на ринкові події".

K. Parsaye [20] ввів складений термін "OLAP Data Mining"

(багатомірний інтелектуальний аналіз) для позначення такого об'єднання

(Рис. 12). J. Han [65] пропонує ще більш просту назву - "OLAP Mining", і

пропонує кілька варіантів інтеграції двох технологій.

53

1. "Cubing then mining". Можливість виконання інтелектуального

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

багатомірного концептуального подання, тобто над будь-яким фрагментом

будь-якої проекції гіперкуба показників.

2. "Mining then cubing". Подібно даним, витягнутим зі сховища,

результати інтелектуального аналізу повинні представлятися в

гіперкубічній формі для наступного багатомірного аналізу.

3. "Cubing while mining". Цей гнучкий спосіб інтеграції дозволяє

автоматично активізувати однотипні механізми інтелектуальної обробки

над результатом кожного кроку багатомірного аналізу (переходу між

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

На жаль, далеко не всі виробники надають сьогодні досить продуктивні

засоби інтелектуального аналізу багатомірних даних у рамках систем

OLAP. Проблема також полягає в тому, що деякі методи ІАД (байесовскі

мірежі, метод k-найближчого сусіда) незастосовуючи для завдань

багатомірного інтелектуального аналізу, тому що засновані на визначенні

подібності деталізованих прикладів і не здатні працювати з агрегованими

даними [20].

Рис. 12. Архітектура системи багатомірного інтелектуального аналізу

даних

54

1.15.Критерії оцінки існуючих продуктів

Як й у будь-якій іншій області, у сфері OLAP не може існувати

однозначних рекомендацій з вибору інструментальних засобів. Можна

тільки загострити увагу на ряді ключових моментів і співставити

пропоновані можливості програмного забезпечення з потребами

організації.

1. Зручність і широкі можливості засобів адміністрування. Робота

адміністратора є найважливішою й самою складною частиною

експлуатації OLAP-системи. Тому варто звертати увагу на зручність

інтерфейсу адміністрування, а більше того - на спектр його

функціональних можливостей. Як формуються нові виміри? Як

модифікується існуюча модель? Потрібно створення бази даних жорстко

заданої структури, чи можна аналізувати дані, зібрані в раніше створених

базах (у випадку ROLAP)? На всі ці питання необхідно одержати

максиРисьно ясну й чітку відповідь.

2. Гнучкість настроювання й наочність форм демонстрації результатів.

Інтуитивность подання інформації - головна особливість OLAP. Наскільки

якісно й зручно формуються звіти? Чи наочні графічні можливості, чи

існує зв'язок з Гис-технологіями? Чи налагоджені механізми експорту

результатів у стандартні формати?

3. Спектр методів післяобробки даних, доступність засобів

інтелектуального аналізу. Чи багаті аналітичні можливості інструмента? Є

в ньому елементи Data Mining, і якщо є, які переваги вони можуть

забезпечити при використанні?

4. Можливість обробки більших сховищ даних із прийнятною

продуктивністю. Якщо необхідний планомірний безперервний аналіз

великого сховища дані організації, потрібно з'ясувати об'єктивні

обмеження продукту з погляду граничних розмірів вихідних баз даних.

5. Можливість пов'язання OLAP-інструментарію з усіма СУБД,

використовуваними в організації. Як показує практика, інтеграція

різнорідних продуктів у стабільно робочу систему - одне з найбільш

важливих питань, і його рішення в ряді випадків може бути пов'язане з

більшими проблемами. Необхідно розібратися, наскільки просто й надійно

можна інтегрувати засоби OLAP з існуючими в організації СУБД.

Крім того, зрозуміло, одним із ключових критеріїв вибору програмних

продуктів є ціна. А продукти OLAP істотно відрізняються друг від друга

по цьому показнику.

Враховуючи це, а найперше доступність та простота використання,

вибрані продукти: операційна система Windows, MS SQL Server 2000, MS

Analysis Server 2000, Microsoft Excel.