Корпоративні інформаційні системи КІС (стр. 9 из 21)

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

3.1).

РЕЛЯЦІЙНА МОДЕЛЬ

Модель	Місяць	Обсяг
BMV	Червень	12
BMV	Липень	24
BMV	Серпень	5
Mercedes	Червень	2
Mercedes	Липень	18
Opel	Липень	19

БАГАТОВИМІРНА МОДЕЛЬ

Місяць/ Модель	Червень	Липень	Серпень
BMV	12	24	5
Mercedes	2	18	Null
Opel	Null	19	Null

Рис. 3.1. Реляційна та багатовимірна моделі представлення даних

Якщо кількість моделей автомобілів дорівнює 30, кількість місяців - 12, при реляційному уявленні вийде звіт у 360 (30 × 12) рядків, який займає не менше 5-6 сторінок. У разі ж багатовимірного (у цьому випадку двовимірного) уявлення вийде досить компактна таблиця розміром 30 × 12, яка цілком вміститься на одній сторінці і яку навіть при такому обсязі даних можна реально оцінювати й аналізувати.

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

• вимір (Dimension);

• чарунка (Cell), або показник (Measure).

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

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

(показників), що знаходяться в чарунках гіперкуба.

Виміри: Модель — Opel, BMW, Mercedes

Менеджер — Сидоров, Петров, Іванов Час (рік) — 2001, 2002, 2003

Показник: Обсяг продаж

Рис. 3.2. Виміри та показники (чарунки)

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

У багатовимірній СУБД Oracle Express Server показник може бути визначений, як:

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

• формула (Formula) — значення таких показників обчислюються за деякою заздалегідь специфікованою формулою. Тобто для показника, який має тип «формула», у БД зберігається не його значення, а формула, за якою це значення може бути обчислене.

У прикладі на рис. 3.1 кожне значення поля «Обсяг продажів» однозначно визначається комбінацією стовпців: «модель автомобіля» та «місяць продаж».

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

• модель автомобіля;

• менеджер;

• час (скажімо, рік).

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

• перший вимір - модель автомобіля;

• другий вимір - менеджер, який продав автомобіль;

• третій вимір - час (рік).

На перетині граней гіперкуба, в чарунках, знаходяться значення показника «Обсяг продажів».

Але не всі показники (рис. 3.3) можуть мати реальні значення. Наприклад, менеджер Сидоров у 2001 р. міг ще не працювати на фірмі, і в цьому випадку всі значення показника «Обсяг продажів» у Сидорова за цей рік будуть мати невизначені значення.

Рис. 3.3. Невизначені значення показників

Операції маніпулювання вимірами

Формування «зрізу» (Slice) - це підмножина гіперкуба, яка була здобута внаслідок фіксації значення одного або більшої кількості вимірів. Наприклад, обмеживши значення виміру «Модель автомобіля» - BMW, отримаємо підмножину гіперкуба (у цьому випадку - двомірну таблицю), яка містить інформацію про історію продажів цієї моделі різними менеджерами в різні роки.

Операція «обертання» (Rotate) - це зміна порядку представлення (візуалізаціі) вимірів. Звичайно застосовується при двовимірному представленні даних. Ця операція забезпечує можливість візуалізаціі даних у формі, найбільш комфортній для їх сприйняття. Наприклад, аналітик має можливість вивести звіт, в якому моделі автомобілів перераховані по осі X, а менеджери по осі Y, і поміняти місцями координати (виконавши обертання на 90 градусів).

Використання ієрархічних відносин (Hierarchical Relationships).

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

Наприклад:

• День —> Місяць —> Квартал —> Рік;

• Менеджер -» Підрозділ —> Регіон —> Фірма —> Країна;

• Модель автомобіля -» Завод-виробник -> Країна.

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

Операція агрегації (Drill Up) - це операція підйому за рівнями

консолідації даних у процесі аналізу або переходу від деталізованих даних до агрегованих. З точки зору користувача, «Підрозділ», «Регіон», «Фірма», «Країна» є точно такими ж вимірюваннями, як і «Менеджер». Але кожний з них відповідає новому, більш високому рівню агрегації значень показника «Обсяг продажів». Наприклад, подивившись, наскільки успішно в 2002 р. Сидоров продавав моделі BMW та Opel, керуючий може захотіти дізнатися, як виглядає співвідношення продажу цих моделей на рівні підрозділу, де Сидоров працює. А потім отримати аналогічну довідку по регіону або фірмі.

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

До основних етапів проектування багатовимірної БД відносяться:

• визначення запитів потенційних користувачів аналітичної системи;

• вибір вимірювань, показників, відносин;

• вибір рівня агрегації вимірів;

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

Гіперкубічні та полікубічні моделі даних

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

Відмінність між ними полягає в тому, що системи, які підтримують полікубічну модель (прикладом є Oracle Express Server), припускають наявність у багатовимірній БД декількох гіперкубів з різною розмірністю та різними вимірами.

Наприклад, значення показника «Робочий час менеджера» не залежить від виміру «Модель автомобіля» та однозначно визначається двома вимірами: «Час» та «Менеджер».

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

• двомірний - для показника «Робочий час менеджера» з вимірами «Час», «Менеджер»;

• тримірний - для показника «Обсяг продажів» з вимірами «Час», «Менеджер», «Модель автомобіля».

У разі гіперкубічної моделі передбачається, що всі показники повинні визначатися одним і тим же набором вимірів. Тобто тільки через те, що «Обсяг продажів» визначається трьома вимірами, при описі показника «Робочий час менеджера» доведеться перебудувати модель і використати ще один вимір - «Модель автомобіля».

Сфера застосування багатовимірних СУБД

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

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

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

З іншого боку, є істотні обмеження на використання БСУБД:

1. БСУБД не дозволяють працювати з великими базами даних. На сьогоднішній день їх реальна межа - 10-20 гігабайт.

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