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

Кафедра "КСУ"

Реферат

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

Введення

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

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

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

Набір цих вимог, що стали де-факто визначенням OLAP, достатньочасто викликає різні нарікання, тому що тут змішано:

. власне вимоги, наприклад п.п. 1, 2, 3, 6;

. НЕ формалiзуються, побажання, наприклад п.п. 10, 11;

. вимоги до комп'ютерної архітектурі, а не до програмних засобів, наприклад, незрозуміло, чому аналітична система відповідає вимогам 11 з 12, але реалізована на основі Unix-станції з терміналами, не є OLAP - п.п. 5. Тим більше, що вже є п. 2

(Прозорість) та п. 3 (Доступність).

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

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

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

Для чого власне потрібні МСУБД і чи потрібно витрачати час і кошти на їхосвоєння та придбання, якщо все ті ж завдання можна вирішити й засобамитрадиційних РСУБД?

І зворотний:

Чому МСУБД обмежують себе виключно додатками,орієнтованими на аналіз даних і чому б на їх основі не реалізовуватитрадиційні системи оперативної обробки даних?

І незважаючи на те, що ці питання висловлюють досить протилежніточки зору, відповідь на них звучить приблизно однаково: "Головнегідність МСУБД полягає саме в тому, що вони вузько спеціалізовані іобласть їх застосування - інтерактивна аналітична обробкаагрегованих історичних і прогнозованих даних ".

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

Історичні дані. Найважливішою властивістю даних в аналітичних задачахє їх Історичний характер. Після того, як зафіксовано, що Петровв червні 1996 р. продала 2 автомобіля "Волга" і 12 автомобілів "Жигулі",дані про цю подію стають історичним (доконаним) фактом. Іпісля того, як інформація про цей факт отримана, верифікована ізаведена в БД, вона може бути скільки завгодно разів зчитана звідти, але вже неможе і не повинна бути змінена. Історичність даних передбачає не тількивисокий рівень статичності (незмінності) як власне даних (наприклад:
Петров продав у 1995 р. 51 автомобіль "Жигулі ВАЗ2105"), так і їхвзаємозв'язків (наприклад: у 1995 р. Петров працював в Східному Регіоні; в
1995 продавалися автомобілі моделі ВАЗ2105). А це, у свою чергу, даєможливість використовувати спеціалізовані, засновані на припущенні простатичності даних та їх взаємозв'язків методи завантаження, зберігання, індексаціїі вибірки.

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

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

так і на мови опису та маніпулювання даними, наприклад:

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

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

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

Наприклад, якщо ми будуємо прогноз про обсяг продажів на червень 1997 р. дляменеджера Петрова, то, по мірі надходження фактичних (Історичних)даних за 1996 р., ця цифра може і буде багато разів змінюватися іуточнюватися. Більше того, досить часто прогнозування та моделюваннязачіпає не тільки майбутні, ще не відбулися, а й минулі, вжесталася подія. Наприклад, аналіз: "а, що буде (було б) ... якщо
(б )..?", будується на припущенні про те, що значення деяких даних, втому числі і з минулого, відмінні від реальних. І для відповіді на питання:

"Який був би Прогноз за обсягом продажів автомобілів" Волга "для менеджера
Петрова на червень 1997 р., якщо б обсяг продажів "Волг" в червні 1996 р. у ньогозріс на той же відсоток, що обсяг продажів "Жигулів "?"

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

На перший погляд, ми самі собі суперечить, говорячи про незмінністьданих, як основоположному властивості аналітичної системи. Але це не так.
Це удаване протиріччя навпаки підкреслює й підсилює значимістьвимог до незмінності Історичних даних. Скільки б ми не вправлялися
(наприклад, при аналізі: "а що ... якщо ..?") зі значенням обсягу продажів заЧервень 1996, значення Історичних (реальних) даних повинні залишатисянезмінними. Звісно, припущення про незмінність не означаєнеможливості виправлення помилок, якщо вони були виявлені в Історичнихданих.

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

менеджер Петров продав ще одні "Жигулі ВАЗ2106";

менеджера Петрова перевели зі Східного філії фірми в Західний.

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

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

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

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

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

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

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

Таблиця 2. (Порівняння характеристик статичної (регламентованого) тадинамічного аналізу).

Але, як правило, після перегляду такого звіту у користувача (аналітика)з'явиться не готова відповідь, а нова серія питань. Однак, якщо б йомузахотілося отримати відповідь на нове запитання, він може чекати його годинник, аіноді і дні. Зазвичай, кожен новий непередбачений заздалегідь запит повиненбути спочатку формально описаний, переданий програмісту, запрограмований і,нарешті, виконаний. Але після того, як аналітик отримає довгоочікувану відповідь,досить часто виявляється, що рішення не могло чекати і воно вже прийнято,або що трапляється ще частіше, відбулося взаємне нерозуміння і отримана відповідьна не зовсім те питання. Втім, не набагато менший час витрачається іна отримання відповіді і на заздалегідь описаний і запрограмований запит.

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

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

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

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

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

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

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

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

Реляційна модель

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

| | Червень | Липень | Серпень |
| "Жигулі" | 12 | 24 | 5 |
| "Москвич" | 2 | 18 | No |
| "Волга" | No | 19 | No |

Малюнок 1. (Реляційна і багатовимірна моделі представлення даних).

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

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

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

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

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

. вимір (Dimension);

. комірка (Cell).

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

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

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

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

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

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

Зауважимо, що ця відмінність існує тільки на етапі проектування таповністю приховано від кінцевих користувачів.

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

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

Місяць продажів.

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

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

Менеджер;

Час (наприклад Рік).

Вимірювання :

Час (Рік) - 1994, 1995, 1995

Менеджер - Петров, Смирнов, Яковлев

Показник:

Обсяг Продаж

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

перший Вимірювання - Модель автомобіля;

другу Вимірювання - Менеджер, що продав автомобіль;

третій Вимірювання - Час (Рік);

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

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

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

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

. Гіперкубіческая модель;

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

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

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

Тривимірний - для показників обсягу продажів.

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

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

Формування "зріз". Користувача рідко цікавлять всі потенційноможливі комбінації значень вимірів. Більше того, він практично ніколине працює одночасно відразу з усім Гіперкуб даних. Підмножинагіперкуба, що вийшло в результаті фіксації значення одного або більше
Вимірювання, яка називається зрізом (Slice). Наприклад, якщо ми обмежимо значення
Вимірювання Модель Автомобіля = "ВАЗ2108", то отримаємо підмножина гіперкуба
(у нашому випадку - двовимірну таблицю), що містить інформацію про історіюпродажів цієї моделі різними менеджерами в різні роки.

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

Відносини і Ієрархічні Відносини. У нашому прикладі значення Показниківвизначаються тільки трьома вимірами. Насправді їх може бути набагатобільше і між їхніми значеннями звичайно існують безліч різних
Відносин (Relation) типу "один до багатьох".

Наприклад, кожен Менеджер може працювати тільки в одному підрозділі, акожної моделі автомобіля однозначно відповідає фірма, яка їївипускає:

Менеджер -> Підрозділ;

Модель Автомобіля -> Фірма-виробник.

Зауважимо, що для вимірювання, що мають тип Час (таких як День, Місяць,
Квартал, Рік), все Відносини встановлюються автоматично, і їх непотрібно описувати.

У свою чергу, безліч Відносин може мати ієрархічну структуру -
Ієрархічні Відносини (Hierarchical Relationships). Ось тільки кількаприкладів таких ієрархічних відносин:

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

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

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

І часто зручніше не оголошувати нові Вимірювання і потім встановлюватиміж ними безліч Відносин, а використовувати механізм ієрархічних
Відносин. У цьому випадку всі потенційно можливі значення з різних
Вимірювань об'єднуються в одне безліч. Наприклад, ми можемо додати добезлічі значень Вимірювання Менеджер ( "Петров", "Сидоров", "Іванов",
"Смірнов"), значення Вимірювання Підрозділ ( "Філія 1", "Філія 2",
"Філія 3") і Виміри Регіон ( "Схід", "Захід") і потім визначити міжцими значеннями Відношення Ієрархії.

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

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

Проектування багатовимірної БД

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

Визначення питань

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

Проектування МБД зазвичай починається з визначення питань (табл. 4), зякими кінцеві користувачі хотіли б звернутися до системи. Причому нацьому етапі інтерес становлять навіть не самі тексти питань, а розуміннятого, про які особистостях, місця, події та об'єктах в них питається.

Таблиця 4. (Список потенційних питань менеджерів фірми).

Розглянемо як приклад питання співробітника комерційного відділу
( "Які два варіанти знижок найбільш ефективні в Західному регіоні в літнійперіод при продажу автомобілів "Жигулі", на основі даних за останні 10років? "). Як було сказано вище, на цьому етапі ми не збираємосяпрограмувати це питання, тим більше, що інструментальні засобикінцевого користувача дозволять легко сформулювати його в інтерактивномурежимі, без написання рядків коду. Зараз нам важливіше зрозуміти, які даніповинні бути в МБД, оцінити тимчасові інтервали, які повинні відображатися,зрозуміти трудомісткість і реальність підготовки і завантаження цих даних.

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

Таблиця 5. (Дані, необхідні для відповіді на питання аналітикакомерційного відділу).

Критерії вибору рівня агрегації

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

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

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

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

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

2. (Країна | Регіон | Філія | Менеджер)

3. (Фірма-виробник | Завод-виробник | Модель Автомобіля)

4. (Тип знижки)

Вибравши рівень деталізації:

1. День (365 * 10 = 3650 різних значень),

2. Менеджер (300 різних значень),

3. Модель Автомобіля (100 різних значень),

4. Тип Знижки (4 різних значення),

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

Таким чином, у нашій БД буде відразу ж зарезервовано місце для всіх
438 млн. значень показників обсягу продажів. Причому цифри "300 менеджерів" і
"100 моделей автомобілів" зовсім не означають того, що сьогоднішняноменклатура фірми - 100 різних моделей, які продають 300 чоловік.
Цифра 300 говорить про те, що у фірмі за 10 років її існування працювало
300 різних менеджерів. Сьогодні ж їх може бути, наприклад, лише 30.

Спробуємо оцінити, який відсоток осередків у нашому випадку буде міститиреальні значення. Припустимо, що в середньому в фірмі постійно працюєблизько 30 менеджерів, менеджер продав в день 10 різних моделей і запродажу кожного автомобіля може бути використаний тільки один варіантзнижки. Тоді 3650 * 30 * 10 * 1 = 1095000. Тобто тільки 0,25% осередків кубабуде містити реальні значення даних. І хоча в МСУБД зазвичайпередбачається, що блоки, повністю заповнені невизначенимизнач