• Гідрологія і Гідрометрія
• Господарське право
• Економіка будівництва
• Економіка природокористування
• Економічна теорія
• Земельне право
• Історія України
• Кримінально виконавче право
• Медична радіологія
• Методи аналізу
• Міжнародне приватне право
• Міжнародний маркетинг
• Основи екології
• Предмет Політологія
• Соціальне страхування
• Технічні засоби організації дорожнього руху
• Товарознавство продовольчих товарів

Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция

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

Багатовимірна модель даних та багатовимірні СУБД

агатовимірна організація даних передбачає багатовимірне представлення структур даних і підтримку багатовимірності в мовах маніпулювання даними та не означає багатовимірність візуалізації даних. Дані представляються кінцевому користувачеві не у вигляді чотирьох- або п'ятимірних гіперкубів, а засобами звичної та комфортної двовимірної бізнес-графіки [23; 40].

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

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

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

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

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

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

• вимір (Dimension);

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

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

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

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

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

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

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

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

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

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

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

• менеджер;

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

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

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

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

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

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

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

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

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

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

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

Наприклад:

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

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

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

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

Операція агрегації (Drill Up)- це операція підйому за рівнями консолідації даних у процесі аналізу або переходу від деталізованих даних до агрегованих. З точки зору користувача, «Підрозділ», «Регі­он», «Фірма», «Країна» є точно такими ж: вимірюваннями, як і «Ме­неджер». Але кожний з них відповідає новому, більш високому рівню агрегації значень показника «Обсяг продажів».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.Для багатовимірних СУБД поки відсутні єдині стандарти на ­інтерфейс, мови опису та маніпулювання даними.

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

Використання БСУБД виправдане тільки при умовах, коли:

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

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

3.3. Реляційний ОLАР (RОLАР)

Забезпечення для реляційних системи продуктивності, набли­женої до продуктивності МОLАР-систем потребує ретель­ної розробки схеми БД. Використання схеми «зірка» («star schema») у реляційних системах забезпечує продуктивність, цілком порівнянну з продуктивністю систем на основі багатовимір­них х баз даних [23].

У цій схемі використовуються два види таблиць - таблиця фактів (фактологічна таблиця) та кілька довідкових таблиць (таблиць вимірювань). Як приклад, на рис. ЗА наведено спрощену схе­му структури сховища даних на основі «зірки». Лініями вказані зв'язки між таблицями, ключові атрибути таблиць виділені напівжирним шрифтом

Рис. 3.4. Приклад БД з радіально пов'язаними таблицями (схема «зірка»)

Кожний промінь схеми «зірка» задає (за термінологією Е. Кодда) напрямок консолідації даних за відповідним виміром.

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

Якщо БД включає велику кількість вимірювань, використовується схема «сніжинка» («snowflake» ). У цій схемі атрибути довідкових таблиць деталізують у додаткових довідкових таблицях {рис. 3.5).

Рис. 3.5. Приклад БД зі схемою «сніжинка»

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

Використання інструментів RОLАР у системах оперативної аналітичної обробки має певні переваги:

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

2.У разі змінної розмірності задачі, коли зміни в структуру вимірів ­доводиться вносити досить часто, RОLАР системи з динамічним представленням розмірності є оптимальним рішенням, оскільки в них такі ­модифікації не вимагають фізичної реорганізації БД.

3.Системи RОLАР можуть функціонувати на набагато менш могутніх клієнтських станціях, ніж системи MOLAP, оскільки головне обчислювальне навантаження в них лягає на сервер, де виконуються складні аналітичні SQL-запити, які формуються системою.

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

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

НедолікамиRОLАР-систем є, по-перше, обмежені можливості з точки зору розрахунку значень функціонального типу; по-друге, менша продуктивність порівняно зМОLАР- системами.

Це пов'язано з тім, що побудова схеми «зірка» вимагає створен­ня проміжної таблиці, яка є декартовим добутком довідкових таб­лиць, які використовуються в запиті. Потім виконується послідов­ний перегляд двох таблиць (фактологічної та проміжної), у процесі якого відсіваються усі рядки, які не відповідають умовам вибору. Такий спосіб оптимізації дає ефект тільки тоді, коли проміжна таб­лиця вміщується в ОЗП. Алі це не завжди так. Наприклад, якщо запит посилається на 10 довідкових таблиць, у кожній з яких лише 10 рядків довжиною в 40 символів, унаслідок виконання операції декартового добутку вийде проміжна таблиця в 10 млрд. рядків. А обсяг ОЗП для її розміщення становитиме 400 гігабайт.

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

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

Взагалі ІС з аналітичними можливостями включає три рівні використання даних:

· перший рівень - це загальнокорпоративна БД на основі реляційної СУБД із нормалізованою чи слабо нормалізованою схе­мою (деталізована БД);

· другий рівень ~ це БД агрегованих даних рівня підрозділу, реалізована на основі БСУБД;

· третій рівень - персональна БД агрегованих даних на робо­чому місці кінцевого користувача, де безпосередньо встановлений аналітичний інструментарій

Рис. 3.6. Використання БСУБД у багаторівневій архітектурі

інформаційної системи

Читайте також:

1. I. Особливості аферентних і еферентних шляхів вегетативного і соматичного відділів нервової системи
2. VI.3.3. Особливості концепції Йоганна Гайнріха Песталоцці
3. VI.3.4. Особливості концепції Йоганна Фрідриха Гербарта
4. А. Особливості диференціації навчального процесу в школах США
5. Агітація за і проти та деякі особливості її техніки.
6. Аграрне виробництво і його особливості
7. Аграрне право як галузь права, його історичні витоки та особливості.
8. Аналіз паралельного інтерейсу з DSP-процесорами: запис даних в ЦАП, що під’єднаний до адресного простору пам’яті
9. Аналіз паралельного інтерфейсу з DSP-процесорами: читання даних з АЦП, що під’єднаний до адресного простору пам’яті
10. Аналіз статистичних даних про склад та плинність кадрів, які обіймали керівні
11. Аналіз та інтерпретація одержаних даних
12. АНАТОМІЯ І ФІЗІОЛОГІЯ ЦЕНТРАЛЬНОЇ ТА ПЕРИФЕРИЧНОЇ НЕРВОВОЇ СИСТЕМИ, ЇЇ ВІКОВІ ОСОБЛИВОСТІ

Переглядів: 3070