Тема: Співіснування багатовимірних систем

Лекція №19

Тема: Співіснування багатовимірних систем

План

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

2.  Агреговані дані..

3.  Історичні дані.

4.  Прогнозовані дані.

5.  Багатовимірна модель даних.

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

Таблицяправил оцінки засобів для OLAP).

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

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

Агреговані дані. Користувача, що займається аналізом, рідко цікавлять деталізовані дані. Більш того, чим вище рівень користувача (керівника, що управляє, аналітика), тим вище рівень агрегації даних, використовуваних їм для ухвалення рішення. Розглянемо як приклад фірму з продажу автомобілів. Комерційного директора такої фірми мало цікавить питання: "Якого кольору "Жигулі" найуспішніше продає один з її менеджерів - Петров: білого або червоного?" Для нього важливо, яким моделям і яким кольорам віддають перевагу в даному регіоні. Його також мало цікавить деталізація на рівні контракту, години або навіть дня. Наприклад, якщо з'ясується, що "ВАЗ2108 Червоного кольору" частіше купують в уранішній годинник, цей факт швидше зацікавить психіатра, а не комерційного аналітика. Для правильного формування складу йому важлива і необхідна інформація на рівні декади, місяця або навіть кварталу.

Історичні дані. Найважливішою властивістю даних в аналітичних задачах є їх Історичний характер.

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

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

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

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

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

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

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

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

·  системи, орієнтовані на аналіз даних - системи підтримки ухвалення рішень (DSS).

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

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

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

Таблиця 2. (Характеристики даних в системах, орієнтованих на оперативну і аналітичну обробку даних).

Характеристика	Оперативні	Аналітичні
Частота оновлення	Висока частота, маленькими порціями	Мала частота, великими порціями
Джерела даних	В основному внутрішні	В основному зовнішні (по відношенню до аналітичної системи)
Вік даних	Поточні (за період від декількох місяців до одного року)	В основному історичні (за період в декілька років, десятки років) і прогнозовані
Рівень агрегації даних	Деталізовані дані	В основному агреговані дані
Призначення	Фіксація, оперативний пошук і обробка даних	Робота з історичними даними, аналітична обробка, прогнозування і моделювання

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

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

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

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

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

·  вимірювання (Dimension);

·  осередок (Cell).

Іноді замість терміну "Осередок" використовується термін "Показник" (Measure).

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

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

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

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

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

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

У різних МСУБД використовуються два основні варіанти організації даних:

·  Гіперкубічна модель;

·  Полікубічеськая модель.

Системи, що підтримують Полікубічеськую модель (прикладом є Oracle Express Server), припускають, що в МБД може бути визначено декілька гіперкубів з різною розмірністю і з різними Вимірюваннями як їх грані. У Полікубічеськой моделі в цьому випадку може бути оголошено два різні гіперкуби: Двомірний;Тривимірний. У разі ж гіперкубічної моделі передбачається, що всі Показники повинні визначатися одним і тим же набором Вимірювань.

Література:

Томас Конноли, Каролин Бегг, Анна Страчан. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд. – М.: Издательский дом «Вильямс», 2000. [1], 835-840

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

1.  Сформуйте 12 правил оцінки засобів для OLAP.

2.  Що собою уявляють Історичні дані?

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

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

5.  Яким чином може бути визначений Показник?