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

РефератДопомога в написанніДізнатися вартістьмоєї роботи

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

Кафедра «КСУ «.

Реферат.

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

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

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

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

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

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

. не формализуемые побажання, наприклад в.п. 10, 11;

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

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

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

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

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

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

І обратный:

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

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

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

Історичні дані. Найважливішим властивістю даних в аналітичних завданнях був частиною їхнього Історичний характер. Коли зафіксовано, що Петров у червні 1996 р. продав 2 автомобіля «Волга «та дванадцяти автомобілів «Жигулі «, дані про катастрофу стають історичним (доконаним) фактом. І по тому, як інформація про цей факт отримана, верифицирована і заведена в БД, може бути скільки завгодно разів зчитана звідти, але вже може і необхідно змінити. Історичність даних передбачає як високий рівень статичності (незмінності) як власне даних (наприклад: Петров продало 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. (Дані, необхідних відповіді питання аналітика комерційного отдела).

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

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

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

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

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

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

1. {Рік | Півріччя | Квартал | Місяць | Тиждень | День | Счет}.

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

3. {Фирма-Производитель | Завод-Производитель | Модель Автомобиля}.

4. {Тип скидки}.

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

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

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

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

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

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

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

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

Завантаження данных.

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

У OLAP системах завантаження даних може здійснюватися практично з різних зовнішніх джерел даних, включая:

різні РСУБД;

плоскі файли з фіксованою структурою записей;

електронних таблиць (Lotus 1−2-3, Ecxell і т.д.);

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

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

Заключение

На закінчення слід визнати, було не зовсім правильно протиставляти або говорити езопівською якесь серйозної взаємної конкуренції реляционного і багатовимірного підходів. Точніше сказати, що ці дві підходу взаємно доповнюють одне одного. Як сказав Еге. Кодд [1], реляционный підхід будь-коли призначався на вирішення його основі завдань, потребують синтезу, аналізу та консолідації даних. І спочатку передбачалося, що що така функції мають реалізовуватися з допомогою зовнішніх стосовно РСУБД, інструментальних средств.

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

Рівень агрегації даних в БД досить високий, і, обсяг БД невідь що великий (лише кілька гигабайт).

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

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

[pic].

Малюнок 1.(Многоуровневая архитектура).

Причому, таке рішення дозволяє найповніше реалізувати й використовувати гідності кожного з підходів: компактне зберігання деталізованих даних, і підтримка великих БД, забезпечувані РСУБД і простота настроювання й хороші часи відгуку, під час роботи з агрегированными даними, забезпечувані МСУБД.

1. Codd, S.B. Codd, C.T. Salley. Providing OLAP (On-Line Analytical.

Processing) to User-Analysts: An IT Mandate. — E.F.Codd & Associates,.

1993.

2. Guide to OLAP Terminology. — Kenan Systems Corporation, 1995.

Показати весь текст

Заповнити форму поточною роботою