Міністерство освіти і науки України

ОДЕСЬКИЙ НАЦІОНАЛЬНИЙ ПОЛІТЕХНІЧНИЙ

УНІВЕРСИТЕТ

Зіноватна С.Л.

Конспект лекцій
з дисципліни
СХОВИЩА ДАНИХ ТА OLAP-СИСТЕМИ
для студентів напряму
6.050103 - «Програмна інженерія»

Одеса ОНПУ 2017

 Міністерство освіти і науки України
ОДЕСЬКИЙ НАЦІОНАЛЬНИЙ ПОЛІТЕХНІЧНИЙ
УНІВЕРСИТЕТ

Зіноватна С.Л.

Конспект лекцій
з дисципліни
СХОВИЩА ДАНИХ ТА OLAP-СИСТЕМИ
для студентів напряму
6.050103 - «Програмна інженерія»

Затверджено
на засіданні
кафедри системного
програмного забезпечення
Протокол № 8 від 16.01.2017

Одеса ОНПУ 2017

Конспект лекцій з дисципліни «Сховища даних та OLAP-системи» для студентів напряму
6.050103 – «Програмна інженерія» / Авт. С. Л. Зіноватна – Одеса: ОНПУ, 2017. – 95 с.

Автор С.Л. Зіноватна, доцент.

Рецензенти: В.А. Крісілов, д.т.н., проф.

О.Б. Кунгурцев, к.т.н. проф.

Конспект містить докладний опис усіх питань, розглянутих під час вивчення
дисципліни. Обсяг лекційного курсу складає 30 год.
Вивчаються такі основні розділи: поняття про системи підтримки рішень, OLAP-
системи; структура сховища даних, вітрини даних, види архітектури та фактори. що
впливають на вибір архітектури; багатомірні куби, види ієрархій, операції над кубами,
агрегація даних; мова багатомірних виразів MDX, синтаксис оператору запиту, функції,
кортежі та множини; підготовка даних для сховища; проблеми побудови сховища даних;
структура робіт по створенню сховища даних.
Призначено для студентів денної та заочної форми навчання.

3
 СПИСОКСКОРОЧЕНЬ

BI – business intelligence
DSS – decision support systems
EIS – executive information systems
FASMI – Fast Analysis of Shared Multidimensional Information
КМ – knowledge management
SQL – structured query language
ODBC – Open Data Base Connectivity
OLAP – OnLine Analytical Processing
OLTP – OnLine Transaction Processing
TDWI – The Data Warehousing Institute

БД – база даних
ИАД – інтелектуальний аналіз даних
ИС – інформаційна система
ИТ – інформаційна технологія
ПО – програмне забезпечення
СППР – система підтримки прийняття рішень
СУБД – система керування базами даних
ТЗ – технічне завдання
ХД – сховище даних
 ВСТУП

Метою викладання дисципліни «Сховища даних та OLAP-Системи» є формування

комплексу знань, вмінь та розумінь, а також здобуття навичок з використання принципів
організації й оперування великими обсягами даних із застосуванням сучасних
інформаційних засобів і технологій.
Для досягнення мети вивчення дисципліни студенти повинні навчитися проектувати
багатомірну модель даних та структуру сховища даних; формулювати запитий до
багатомірної бази даних; розуміти процеси виконання запитів в OLAP-Системах.
У результаті вивчення дисципліни студент повинен знаті:
- основні визначення, що відносяться до концепції керування сховищами даних;
- основні вимоги й засоби їхнього забезпечення для сховищ даних:
- способи підтримки високої швидкості одержання даних зі сховища та
внутрішньої несуперечності даних;
- можливості одержання й порівняння зрізів даних;
- засоби підтримки якісного процесу поповнення даних;
- технології, що забезпечують маніпулювання сховищами даних;
- методологію створення корпоративних інформаційних систем.
 Семестровий модуль 1
Змістовний модуль 1
Системи підтримки ухвалення рішення
ЛЕКЦІЯ №1
Введення в бізнес-інтелект

Розглядаються такі питання:

· причини розвитку аналітичних засобів;
· поняття бізнес-інтелекту (BI);
· основні види аналітичної діяльності;
· інструменти сучасних BI-Засобів.

Одержання аналітичної звітності в інформаційних системах, заснованих на

традиційних базах даних (БД), пов’язано з рядом обмежень:
· розробка кожного звіту вимагає роботи програміста;
· звіти формуються дуже повільно (найчастіше кілька годин), сповільнюючи при
цьому роботу всієї інформаційної системи;
· дані, одержувані від різних структурних елементів компанії, не уніфіковані й
часто суперечливі.
У багатьох компаніях у процесі складання звіту беруть участь два фахівці -
програміст, що забезпечує запити до баз даних, і економіст, що намагається за допомогою
електронних таблиць звести ці дані у звіт, необхідний керівництву. Як показує практика,
подібна модель взаємодії користувача звіту (керівника) і самих даних часто приводить до
ефекту «зіпсованого телефону», не говорячи вже про істотні витрати часу.
Економіст найчастіше виявляється просто не в змозі без допомоги програміста
оперативно підготувати необхідну вибірку й відповісти на питання про те, яким способом
були отримані ті або інші цифри. Звичайно, не йде й мови про те, щоб моделювати
можливі ситуації, відслідковувати вплив одних показників на інші, прогнозувати
тенденції розвитку, проводити порівняльний аналіз і відображати різні зрізи даних.
Швидка й адекватна реакція на зміну зовнішніх умов в остаточному підсумку
визначає позицію, займану компанією на ринку. Якість інформації, уміння її обробляти й
аналізувати, швидкість прийняття рішень за результатами цього аналізу – фактори, від
яких залежить успіх або неуспіх компанії в конкурентній боротьбі.
Однак скористатися потенційною перевагою, що дає володіння інформацією,
вдається не всім. По-перше, тому, що інформація, яку керівництво компанії одержує з
різних джерел, розрізнена. По-друге, неповнота даних різко знижує продуктивність і
якість аналізу. А найчастіше менеджерам, навпаки, доводиться мати справа із занадто
великим потоком даних, що також утрудняє прийняття зваженого й обміркованого
рішення. В обох випадках основна проблема в тім, що інформація, яку має менеджер
компанії, не орієнтована на задачі керування бізнесом, і представлена вона в такій формі,
що нею незручно користуватися в процесі прийняття управлінських рішень. Такі,
наприклад, пропоновані багатьма системами керування стандартні набори звітів:
менеджер одержує набір даних, але не засоби для їхнього аналізу.
Для адекватної оцінки ситуації й вироблення оптимального рішення необхідно
певним чином класифікувати й систематизувати дані, відсіяти несуттєві факти й
спроектувати наявні дані на конкретне бізнес-завдання.
Отже, перед компанією виникає задача перетворення «даних» в «інформацію», що
відповідає потребам процесу аналізу й прийняття рішень. Для менеджера інформація – це
сировина для прийняття рішень. До інформації, як до будь-якої сировини, пред'являються
вимоги якості. Вона повинна бути бізнес-орієнтованою (оперативні дані перетворені в
бізнес-зміст), актуальна (відповідати поточному стану бізнесу), доступна (кожному
менеджерові в зручній формі й в обсязі, що відповідає посадовим обов'язкам), достовірна
(коректна й перевірена), повна (що необхідно для ухвалення вірного рішення) і
хронологічна.
Зараз у багатьох організаціях накопичені значні обсяги даних, на основі яких можна
вирішувати різноманітні аналітичні й управлінські задачі. Проблеми зберігання й обробки
аналітичної інформації стають усе більше актуальними, що привело до формування
повноцінного ринку технологій бізнесу-аналізу.
В ідеалі робота аналітиків і керівників різних рівнів повинна бути організована так,
щоб вони могли мати доступ до всієї їхньої інформації, яка потрібна, і користуватися
зручними й простими засобами представлення й роботи із цією інформацією.

Агентство Gartner Group, що займається аналізом ринків інформаційних технологій,

в 1980-х роках увело термін «Business Intelligence», діловий інтелект або бізнес-інтелект.
Business Intelligence (BI) – це користувачевоцентріський процес, що включає доступ і
дослідження інформації, її аналіз, виробіток інтуїції й розуміння, які ведуть до
поліпшеного й неформального прийняття рішень. Цей термін запропонований для опису
різних концепцій і методів, які поліпшують бізнес рішення шляхом використання систем
підтримки прийняття рішень (СППР, DSS – Decision Support Sysytem).
В 1996 році агентство уточнило визначення даного терміна. BI – програмні засоби,
які функціонують у рамках підприємства і які забезпечують функції доступу й аналізу
інформації, що перебуває в сховищі даних, а також забезпечують прийняття правильних і
обґрунтованих управлінських рішень.
TDWI (The Data Warehousing Institute) (www.dmreview.com): запропонувало
наступне визначення «Business intelligence належить до процесу перетворення даних у
знання, а знань у дії бізнесу для одержання вигоди. Є діяльністю кінцевого користувача,
яку полегшують різні аналітичні й групові інструменти й застосування, а також
інфраструктура сховища даних».
Іноді в це поняття BI включають і технологію керування знаннями Knowledge
Management (КМ), яка, однак більше пов'язана з аналізом неструктурованої або
слабоструктурованої інформації (наприклад, HTML), що не є предметом аналізу BI-
інструментів. KM забезпечує категоризацію, розвідку й семантичну обробку текстів,
розширений пошук інформації й ін. Технологія BI має відношення до аналізу
фактографічної структурованої (бази даних, плоскі файли й інші ODBC або OLE DB-
джерела даних) і квазіструктурованої інформації (наприклад, XML).
Історично назви й зміст інформаційно-аналітичних систем змінювалися від
інформаційних систем керівника (executive information systems, EIS) до систем підтримки
прийняття рішень (decision support systems, DSS) і зараз до систем бізнесу-інтелекту.
Застосування EIS були налаштовані на потреби керівників і менеджерів і давали
можливість одержувати основну агреговану інформацію про стан їхнього бізнесу у
вигляді таблиць або діаграм. Звичайно вони включали регламентні запити з набором
параметрів. Такі пакети звичайно розроблялися силами своїх підрозділів інформаційних
технологій (ІТ). Для одержання додаткової інформації й проведення подальшого аналізу
застосовувалися інші застосування або створювалися за замовленням запити або звіти на
SQL.
Застосування DSS першого покоління були пакетами прикладних програм з
динамічною генерацією SQL-скриптів по типу запитуваної користувачем інформації.
Вони дозволяли аналітикам одержувати інформацію з реляційних БД, не вимагаючи
знання SQL. На відміну від EIS застосування DSS можуть відповідати на широкий спектр
питань бізнесу, мають кілька варіантів представлення звітів і певні можливості
форматування. Однак гнучкість таких пакетів все-таки була обмежена через орієнтацію на
конкретний набір задач.
Із приходом персональних комп'ютерів і локальних мереж наступне покоління
застосувань DSS будується вже на основі BI і дозволяє користувачеві-непрограмістові
легко й оперативно витягати інформацію з різних джерел, формувати власні
налаштовуванізвіти, або графічні представлення, проводити багатомірний аналіз даних.
Розвиток систем бізнес-інтелекту пройшов шлях від «товстих» клієнтів до Web-
застосувань, у яких користувач веде дослідження за допомогою браузера й може
працювати віддалено. Можна також створювати сценарії «що якщо» і колективно
переглядати й обновляти інформацію.

У цей час прийнято розрізняти наступні основні види аналітичної діяльності:

1) стандартна звітність;
2) нерегламентовані запити;
3) багатомірний аналіз (OLAP – online analytical processing);
4) інтелектуальний аналіз даних (розвідка даних – data mining).

Інтелектуальний аналіз даних (ІАД) розглядається як процес підтримки прийняття

рішень, заснований на пошуку в даних схованих закономірностей.
Розвідка даних являє собою процес виявлення кореляції, тенденцій, шаблонів,
зв'язків і категорій. Вона виконується шляхом ретельного дослідження даних з
використанням технологій розпізнавання шаблонів, а також статистичних і математичних
методів. При розвідці даних багаторазово виконуються різні операції й перетворення над
сирими даними (відбір ознак, стратифікація, кластерізація, візуалізація й регресія), які
призначені:
1) для знаходження представлень, які є інтуїтивно зрозумілими для людей, які, у
свою чергу, краще розуміють бізнес-процеси, що лежать в основі їхньої діяльності;
2) для знаходження моделей, які можуть пророчити результат або значення певних
ситуацій, використовуючи історичні або суб'єктивні дані.
Розвідка даних у значно меншому ступені направляється користувачем, замість
цього покладається на спеціалізовані алгоритми, які встановлюють співвідношення
інформації й допомагають розпізнати важливі (і раніше невідомі) тенденції, вільні від
упередженості й припущень користувача.
Більшість методів ІАД розроблено в рамках теорії штучного інтелекту й прийнято
розглядати його як процес підтримки прийняття рішень із використанням пошуку в даних
схованих закономірностей (інформаційних шаблонів). У процесі ІАД витягають шаблони
й тренди, що існують у даних. Такі шаблони й тренди можуть бути зібрані воєдино й
визначені як модель інтелектуального аналізу даних.
Основними задачамиІАД є:
Класифікація (Classification). НайпоширенішазадачаІАД. У результаті рішення
задачі класифікації виявляються ознаки, які характеризують групи об'єктів (класи). По цих
ознаках новий об'єкт можна віднести до того або іншого класу.
Кластерізація (Clustering). Кластерізація є логічним продовженням ідеї
класифікації. Цязадачабільш складна, особливість кластерізації полягає в тім, що класи
об'єктів спочатку не визначені. Результатом кластерізації є розбивка об'єктів на групи.
Асоціація (Associations). У ході рішення задачі пошуку асоціативних правил
відшукуються закономірності між зв'язаними подіями в наборі даних. Відмінність
асоціації від двох попередніх задач Data Mining: пошук закономірностей здійснюється не
на основі властивостей аналізованого об'єкта, а між декількома подіями, які відбуваються
одночасно.
Послідовність (Sequence). Послідовність дозволяє знайти часові закономірності між
транзакціями. Задача послідовності подібна асоціації, але її метою є встановлення
закономірностей не між одночасно наступаючими подіями, а між подіями, зв'язаними в
часі. Інакше кажучи, послідовність визначається високою ймовірністю ланцюжка
зв'язаних у часі подій. Фактично, асоціація є окремимвипадком послідовності з часовим
лагом, рівним нулю.
 Прогнозування (Forecasting). У результаті рішення задачі прогнозування на основі
особливостей історичних даних оцінюються пропущені або ж майбутні значення цільових
чисельних показників. Для рішення таких задач широко застосовуються методи
математичної статистики..
Аналіз відхилень (Deviation Detection). Даназадача вирішується з метою виявлення
й аналіз даних, які найбільш відрізняються від загальної множини даних, тобто виявлення
нехарактерних шаблонів.

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

Більшість інструментів працюють спільно, хоча в процесі прийняття рішень вони грають
різні ролі. Нижче перераховані інструменти BI:
- сервери реляційних баз даних;
- OLAP-сервери;
- сховища даних;
- вітрини даних;
- інструменти перетворення й очищення даних;
- інструменти звітності;
- інструменти аналізу й дослідження;
- засоби візуалізації;
- засоби розвідки даних (data mining);
- карти показників, портали й інструментальні панелі;
- електронні таблиці;
- засоби моделювання й прогнозування;
- аналітичні застосування.

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

1. Опишіть причини розвитку аналітичних систем.
2. Поясніть, що розуміють під бізнес-інтелектом.
3. Які види аналітичної діяльності Ви знаєте?
4. Що розуміють під терміном «розвідка даних»?
5. Назвіть етапи розвитку інформаційно-аналітичних систем.

Методичні вказівки до лекції: [2, с. 58—89]; [4, с. 905–908]; [5, с. 981–998]; [6, с.
36-43]; [8, с. 524-529].

Вправи
1. Приведіть приклади аналітичних звітів для предметної області «Торгівля».
2. Проведіть порівняння між звітами для оперативної системи й аналітичної
системи на основі прикладів.
 ЛЕКЦІЯ №2
Поняття сховища даних

Розглядаються такі питання:

· основна ідея концепції сховища даних (СД);
· визначення СД;
· проблеми розробки й супроводу СД;
· переваги технології сховищ даних;
· основні компоненти СД.

В основі концепції СД лежить ідея розділення даних, використовуваних для

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

Сховище даних(Data Warehouse) –предметно-орієнтований, інтегрований,

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

СД функціонує по наступному сценарії: по заданому регламенті в нього збираються

дані з різних джерел - БД систем оперативної обробки. У СД підтримується хронологія:
нарівні з поточними зберігаються історичні дані із вказівкою часу, до якого вони
відносятся. У результаті необхідні доступні дані про об'єкт керування збираються в
одному місці, приводяться до єдиного формату, погоджуються й, у ряді випадків,
агрегуються до мінімально необхідного рівня узагальнення.
Незважаючи на те, що СД містять свідомо надлишкову інформацію, що і так є в
базах або файлах оперативних систем, поява концепції СД викликана тим, що аналізувати
дані оперативних систем прямо неможливо або дуже важко. Це пояснюється:
· розрізненістю даних (системи обробки оперативних даних, текстові звіти, xls-
файли);
· зберіганням їх у форматах різних СКБД і в різних вузлах корпоративної мережі.
Але навіть якщо на підприємстві всі дані зберігаються на центральному сервері БД (що
буває вкрай рідко), аналітик важкорозібратися в їх складних, часом заплутаних
структурах;
· складні аналітичні запити до оперативної інформації гальмують поточну роботу
компанії, оскільки надовго блокують таблиці й захоплюють ресурси сервера.

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

Проблеми розробки й супроводу сховищ даних

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

Переваги технології сховищ даних

1) Потенційно висока віддача від інвестицій
У випадку застосування даної технології організації буде потрібно інвестувати
значні засоби для того, щоб гарантувати успішну реалізацію проекту. Залежно від
використовуваних технічних рішень необхідна сума інвестицій може змінюватися від
50000 до 10000000 фунтів стерлінгів. Однак за даними фірми International Data Corporation
(IDC) в 1996 році усереднений зa 3 роки коефіцієнт окупності інвестицій у сфері сховищ
даних склав 401%, причому більш ніж для 90% компаній, охоплених даним дослідженням,
цей показник склав понад 40%, для половини компаній – понад 160%, а для чверті
компаній – понад 600%.
2) Підвищення конкурентоспроможності за рахунок того, що особи, відповідальні
за прийняття рішень у даній організації, одержують можливість звернутися до раніше
недоступної, невідомої й такої, що ніколи використовувалася, інформації.
3) Підвищення ефективності праці осіб, відповідальних за прийняття рішень
завдяки створенню інтегрованої бази даних, що складається з несуперечливої й такої, що
охоплює великий часовий інтервал, інформації.
4) Керівництво одержує повне ясне бачення ситуації і єдиний механізм обліку,
контролю й аналізу.
5) Зменшується потреба в людських ресурсах за рахунок автоматизації внутрішніх
бізнес-процесів і підвищення продуктивності співробітників.

Основні компоненти СД
ПЗ (програмне забезпечення) проміжного шару
Забезпечує мережний доступ і доступ до баз даних. Сюди належать мережні й
комунікаційні протоколи, драйвери, системи обміну повідомленнями та ін.
Транзакційні БД і зовнішні джерела інформації
БД систем оперативної обробки даних історично призначалися для ефективної
обробки структур даних у відносно невеликому числі чітко певних транзакцій. Через
обмежену цільову спрямованість «облікових» систем застосовувані в них структури даних
погано підходять для систем підтримки прийняття рішень. Крім того, вік багатьох
установлених OLTP-Систем досягає 10 - 15 років.
Рівень доступу до даних
Таке ПЗ забезпечує спілкування кінцевих користувачів з інформаційним СД і
завантаження необхідних даних із транзакціних систем. У цей час універсальною мовою
спілкування служить мова структурованих запитів (SQL).
Завантаження й попередня обробка
Цей рівень містить у собі набір засобів для завантаження даних з OLTP-систем і
зовнішніх джерел. Виконується, як правило, у сполученні з додатковою обробкою:
перевіркою даних на чистоту, консолідацією, форматуванням, фільтрацією та ін.
Інформаційне СД
Являє собою ядро всієї системи - один або кілька серверів БД.
Метадані
Метадані (репозіторій, «дані про дані») відіграють роль довідника, що містить
відомості про джерела первинних даних, алгоритми обробки, яким вихідні дані були
піддані, і т.д.
Рівень інформаційного доступу
Забезпечує безпосереднє спілкування користувача із СД за допомогою стандартних
систем маніпулювання, аналізу й надання даних типу MS Excel, MS Access, Lotus і ін.
 Рівень керування (адміністрування)
Відслідковує виконання процедур, необхідних для відновлення інформаційного
сховища або підтримки його стану. Тут програмуються процедури підкачування даних,
перебудови індексів, виконання підсумкових (підсумовуючих) розрахунків, реплікації
даних, побудови звітів, формування повідомлень користувачам, контролю цілісності й ін.

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

1. Дайте визначення сховища даних.
2. Поясніть, що розуміють під предметною орієнтацією й інтеграцією для СД.
3. Поясніть, що розуміють під підтримкою хронології й незмінністю для СД.
4. Опишіть регламент функціонування СД.
5. Назвіть етапи створення СД.
6. Перелічіть переваги використання СД.
7. У чому складаються проблеми створення й супроводу СД?
8. Які основні компоненти СД?

Методичні вказівки до лекції: [1, с. 23–30]; [2, с. 19–26]; [5, с. 944–951]; [6, с. 59–
64].

Вправи
1. Знайдіть за допомогою різних джерел інформації приклад невдалого проекту СД.
2. Приведіть приклад аналітичного запиту для обраної Вами предметної області,
результати якого дозволять підвищити прибутковість організації.
 Змістовний модуль 2
OLAP-системи
ЛЕКЦІЯ №3
Аналітичні (OLAP) системи

Розглядаються наступні питання

· порівняння характеристик систем оперативної обробки даних і аналітичних
систем;
· поняття оперативного аналізу даних;
· функції аналітичних систем;
· користувачі OLAP-систем;
· типи використовуваних в аналітичних системах даних;
· тест FASMI.
· правила Кодда для опису характеристик аналітичних систем;
· приклади використання OLAP-систем;
· багатомірність в OLAP-застосуваннях;
· способи реалізації багатомірної моделі.

Порівняння основних характеристик типових систем OLTP і сховищ даних

Практично в будь-якій організації склалася парадоксальна ситуація: інформація
начебто б десь і є, її навіть занадто багато, але вона неструктурована, неузгоджена,
розрізнена, не завжди достовірна, її практично неможливо знайти й отримати. У
результаті можна говорити об відсутність інформації при її наявності й навіть
надмірності.
Для того щоб витягати корисну інформацію з даних, вони повинні бути організовані
способом, відмінним від прийнятого в OLTP-системах, тому що:
· в OLTP-системах використовуються нормалізовані таблиці БД. Нормалізація
ефективна, якщо відношення часто оновлюються, але дає негативний ефект у випадку
операції вибірки (особливо у випадку складних запитів). А в DSS-системах
використовуються тільки операції вибірки, і дані рідко змінюються, тому дані доцільно
зберігати у вигляді слабко нормалізованих відношень, що містять заздалегідь обчислені
основні підсумкові дані. Більша надмірність і пов'язані з нею проблеми отут не страшні,
тому що відновлення відбувається тільки в момент завантаження нової порції даних. При
цьому відбувається як додавання нових даних, так і перерахування підсумків;
· виконання деяких аналітичних запитів вимагає хронологічної впорядкованості
даних. Реляційна модель не припускає існування порядку записів у таблицях;
· у випадку аналітичних запитів частіше використовуються не детальні, а
узагальнені (агреговані дані).
Організація звичайно має кілька різних систем OLTP, призначених для підтримки
таких ділових процесів, як керування запасами, виставляння рахунків клієнтам і продаж
товарів. Системи OLTP оптимально підходять для інтенсивної обробки транзакцій, які
проектують заздалегідь, багаторазово повторюються й зв'язані переважно з відновленням
даних.
Однак в організації звичайно є тільки одне СД. СД призначені для обробки щодо
невеликої кількості транзакцій, які мають непередбачений характер і вимагають відповіді
на довільні, неструктуровані й евристичні запити. Інформація в СД призначена для
підтримки прийняття довгострокових стратегічних рішень відносно невеликою кількістю
керівників.
Хоча системи OLTP і СД мають різні характеристики й створюються для різних
цілей, вони зв'язані в тому розумінні, що системи OLTP є джерелом інформації для
сховища даних.
 За допомогою СД можна одержати відповіді на запити, більш складні, ніж запити з
найпростішими узагальненнями типу наступного: «Яка середня ціна об'єктів нерухомості
в найбільших містах країни?».
Приклади запитів для сховища даних:
- Які три райони в городах, що обслуговуються, були найбільш популярні з
погляду оренди об'єктів нерухомості в певному році і як ці дані змінилися в порівнянні з
даними за попередні два роки?
- Який місячний дохід від продажу об'єктів нерухомості в кожному відділенні
компанії в порівнянні з аналогічними показниками річної давнини?
- Які типи об'єктів нерухомості продаються за цінами вище середньої ціни об'єктів
нерухомості в найбільших містах країни і як ці дані пов'язані з демографічними даними?
- Який зв'язок спостерігається між сумарним щорічним доходом у кожному
відділенні компанії й загальною кількістю торгових агентів у кожному із цих відділень?

Порівняння основних характеристик типових систем OLTP і сховищ даних

Система OLTP
Містить поточні дані
Зберігає докладні відомості
Дані є динамічними
Повторюваний спосіб обробки даних
Тип екранних форм в основному
визначений заздалегідь
Висока інтенсивність обробки транзакцій Середня й низька інтенсивність обробки
Передбачуваний спосіб використання
даних
Призначена для обробки транзакцій
Орієнтована на прикладні області
Підтримка прийняття повсякденних
рішень
Обслуговує велику кількість працівників
виконавчої ланки
Відповідає на питання Скільки? Як?
Коли?
Сховище даних
Містить історичні дані
Зберігає докладні відомості, а також частково
й повністю узагальнені дані
Дані в основному є статичними
Нерегламентований, неструктурований і
евристичний спосіб обробки даних
Форми визначаються користувачем
транзакцій
Непередбачений спосіб використання даних
Призначено для проведення аналізу
Орієнтовано на предметні області
Підтримка прийняття стратегічних рішень
Обслуговує відносно малу кількість
працівників керівної ланки
Відповідає на питання Чому? Що буде, якщо?

Через ці розходження можуть виникнути труднощі при організації спільного

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

Оперативний аналіз даних

Ідея обробки багатомірних даних виникла в 1962 році, коли К.Айверсон опублікував
свою роботу «Мова програмування» (A Programming Language, APL). APL – це
математично визначена мова з багатомірними змінними й досить абстрактними
операторами. В 70-і й 80-і роки вона активно використовувалася в багатьох ділових
застосуваннях, функціонально схожих із сучасними OLAP-системами.
В 1970 з’явився перший програмний продукт для багатомірного аналізу даних –
Express. В 1992 році був випущений Essbase – перший OLAP продукт, що одержав
масштабний ринок.
 В 1993 році вийшла стаття Е.Ф.Кодда (E.F.Codd), у якій уперше було дано
формальне визначення OLAP-технології.
OLAP – технологія оперативної аналітичної обробки даних, що використовує
методи й засоби для збору, зберігання й аналізу багатомірних даних з метою підтримки
процесів прийняття рішень.

Рис.1. Основні функції аналітичних систем

Користувачі OLAP-систем
- керівники й менеджмент;
- бізнес-аналітики, маркетологи й аналітикипо плануванню розвитку;
- керівники середньої й молодшої ланки;
- рядові співробітники;
- співробітники ІТ-служб;
- інші застосування.

Типи використовуваних даних

У системах аналізу багатомірних даних можна виділити три основних типи даних,
аналіз яких дозволяє робити прогнозування бізнес процесів.
Агреговані дані
Користувача, що займається аналізом, рідко цікавлять деталізовані дані. Більш того,
чим вище рівень користувача (керівника, керуючого, аналітика), тим вище рівень агрегації
даних, використовуваних їм для ухвалення рішення.
Приклад. Є фірма із продажу комп'ютерів. Комерційного директора такої фірми
мало цікавить питання: «Якого кольору комп'ютери краще всього продає менеджер
Петров: чорного або сріблистого?» Для нього важливо, які моделі, і які кольори воліють у
даному регіоні. Його також мало цікавить деталізація на рівні контракту, часу або навіть
дня. Для правильного формування складу йому важлива й необхідна інформація на рівні
декади, місяця або навіть кварталу.
Історичні дані
Після того як зафіксовано, що Петров у червні поточного року продав 2 комп'ютери
Celeron і 12 комп'ютерів Pentium, дані про цю подію стають історичним (таким, що
здійснився) фактом. І після того, як інформація про цей факт отримана, верифікована й
заведена в БД, вона може бути багаторазово зчитана звідти, але вже не може й не повинна
бути змінена.
Історичність даних припускає не тільки високий рівень статичності (незмінності) як
властиво даних (наприклад: Петров продав цього року 51 комп'ютер Pentium), так і їхніх
взаємозв'язків (наприклад: цього року Петров працював у м.Суми; цього року продавалися
комп'ютери моделі Pentium). Це дає можливість використовувати спеціалізовані, засновані
на припущенні про статичність даних і їхніх взаємозв'язків методи завантаження,
зберігання, індексації й вибірки.
Прогнозовані дані
Коли говориться про незмінність і статичність даних в аналітичних системах,
мається на увазі незмінність винятково історичних даних (даних, що описує події вже, які
відбулися). Таке припущення не поширюється на прогнозовані дані (дані про подію, що
ще не відбувалася).
Наприклад, якщо будується прогноз про обсяг продажів на наступні роки для
менеджера Петрова, то в міру надходження фактичних (історичних) даних за поточний рік
ця цифра буде багаторазово змінюватися й уточнюватися. Більш того, досить часте
прогнозування й моделювання зачіпає не тільки майбутні, що ще не відбулися, але й
минулі, що вже здійснилися події. Наприклад, аналіз: «а, що буде (було б)... якщо (би)..?»,
будується на припущенні про те, що значення деяких даних, у тому числі й з минулого,
відмінні від реальних. І для відповіді на питання: «Який був би прогноз по обсягу
продажів комп'ютерів Athlonдля менеджера Петрова на наступний рік, якби обсяг
продажів комп'ютерів Celeron цього року в нього зріс на той же відсоток, що обсяг
продажів Pentium»,буде потрібно не тільки обчислити нове, ще не існуюче значення
обсягу продажів для року, що ще не наступив, але й попередньо обчислити гіпотетичне
значення обсягу продажів за вже минулий період.

В 1995 році на основі вимог, викладених Коддом, сформульований тест FASMI (Fast
Analysis of Shared Multidimensional Information), що переводиться як «швидкий аналіз
поділюваної багатомірної інформації». Тест FASMI включає наступні вимоги до
застосувань для багатомірного аналізу:
• надання користувачеві результатів аналізу за прийнятний час (приблизно 5 с) при
припустимому рівні деталізації аналізу (прості за 2 с, невелика кількість дуже складних не
більш ніж за 20 с);
• можливість здійснення будь-якого логічного й статистичного аналізу,
підтримуваного використовуваним додатком, зі збереженням результатів у доступному
для користувача виді;
• багатокористувальницький доступ до даних з підтримкою відповідних механізмів
блокування й засобів автоматизованого доступу;
• багатомірне концептуальне представлення даних, включаючи повну підтримку для
ієрархій і множинних ієрархій вимірів (ключова вимога OLAP);
• можливість звертатися до будь-якої потрібної інформації незалежно від її обсягу й
місця зберігання.
У статті Е.Ф.Кодда, у якій уперше було дано формальне визначення OLAP-
технології, також були описані дванадцять правил, які описуютьголовні особливості
OLAP, до цих правил в 1995 році були додані ще кілька.
Характеристики OLAP розбиті на кілька груп.
Основні характеристики:
1. Багатомірність моделі даних. OLAP-система на концептуальному рівні повинна
представляти дані у вигляді багатомірної моделі, що спрощує процеси аналізу й
сприйняття інформації.
2. Інтуїтивні механізми маніпулювання даними. OLAP-система повинна надавати
спосіб виконання операцій зрізу, обертання, консолідації й деталізації над OLAP-кубом
без необхідності користувачеві робити множину дій з інтерфейсом. Маніпулювання
даними повинне виконуватися за допомогою дій безпосередньо в комірках таблиць, без
застосування меню або складних операцій.
3. Доступність. OLAP-система повинна надавати користувачеві єдину, погоджену й
цілісну модель даних, забезпечуючи доступ до даних незалежно від того, як і де вони
зберігаються.
4. Пакетне добування даних. Це правило вимагає, щоб продукти пропонували як
власні бази для зберігання аналізованих даних, так і динамічний доступ до зовнішніх
даних.
5. Архітектура «клієнт-сервер». OLAP-сервер забезпечує зберігання даних,
виконання над ними необхідних операцій і формування багатомірної моделі на
концептуальному рівні. OLAP-клієнт представляє користувачеві інтерфейс до
багатомірної моделі даних, забезпечуючи його можливістю зручно маніпулювати даними
для виконання завдань аналізу.
6. Прозорість – означає, що користувач, наприклад, електронної таблиці може
одержати повний доступ до засобів, надаваним ядром OLAP, і може при цьому навіть не
знати про те, звідки отримані ці дані. OLAP-система повинна приховувати від користувача
реальну реалізацію багатомірної моделі, спосіб організації, джерела, засоби обробки й
зберігання.
7. Багатокористувальницька робота. OLAP-система повинна надавати можливість
працювати декільком користувачам разом з однією аналітичною моделлю або створювати
для них різні моделі з єдиних даних.
8. Підтримка всіх моделей OLAP-аналізу.OLAP-система повинна підтримувати всі
чотири моделі аналізу даних, визначені Коддом: категоріальну, тлумачевальну, умоглядну
й стереотипну (формування звітів, що параметрично настроюються, формування розрізів і
угруповань зі зверненням, аналізом у стилі «що, якщо» і моделями пошуку цілей,
відповідно).
Спеціальні характеристики
9. Обробка ненормалізованих даних. Це означає можливість інтеграції між ядром
OLAP і ненормалізованим джерелом даних. Кодд виділяє те, що при відновленні даних,
виконаному в середовищі OLAP, повинна бути можливість змінювати ненормалізовані
дані в зовнішніх системах.
10. Зберігання OLAP результатів окремо від вихідних даних.
11. Виділення відсутніх даних. Це означає, що відсутні дані повинні відрізнятися від
нульового значення. Як правило, всі сучасні OLAP системи підтримують цю
характеристику.
12. Обробка відсутніх значень. Всі відсутні значення повинні бути зігноровані при
аналізі, поза залежністю від їхнього джерела.
Характеристики побудови звітів
13. Гнучка побудова звітів. OLAP-система повинна підтримувати різні способи
візуалізації даних, тобто звіти повинні представлятися в будь-якій можливій орієнтації.
Засоби формування звітів повинні представляти синтезовані дані або інформацію, що
випливає з моделі даних у її будь-якій можливій орієнтації. Різні виміри повинні
вибудовуватися будь-яким способом відповідно до потреб користувача.
14. Стабільна продуктивність при побудові звітів. Продуктивність OLAP-систем не
повинна значно зменшуватися при збільшенні кількості вимірів, по яких виконується
аналіз, або збільшенні обсягу бази даних.
15. Автоматичне регулювання фізичного рівня. OLAP-система повинна автоматично
регулювати фізичну структуру для адаптації її до типу й структури моделі.
Керування розмірністю
16. Рівноправність вимірів. Всі виміри повинні мати однакові можливості в
структурі й функціональності. Швидкість доступу повинна зберігатися поза залежністю
від розташування комірок даних і бути постійною величиною для моделей, що мають
різне число вимірів і різний ступінь розрідженості даних.
17. Необмежене число вимірів і рівнів агрегування. Фактично, під необмеженим
числом Кодд має на увазі 15-20, тобто число, що свідомо перевищує максимальні потреби
аналітика.
18. Необмежені операції між даними різних вимірів. Кодд вважає, що для того, щоб
застосування називалося багатомірним, воно повинне підтримувати будь-які обчислення з
використанням даних всіх вимірів.

Приклади використання OLAP-систем

Торгівля характеризується великим обсягом операцій (при незначному розмірі
одиничної транзакції), великою кількістю клієнтів, широкою продуктовою лінійкою й
часто розподіленим зберіганням даних.
· Консолідація даних. За допомогою СД можна зібрати інформацію з територіально
розподілених підрозділів і множини джерел даних, як внутрішніх, так і зовнішніх.
· Прогнозування й оптимізація запасів. OLAP-системи дозволяють знаходити
сезонність і тренди, ураховувати складний вплив множини зовнішніх факторів. Маючи
якісний прогноз, можна вирішувати задачу оптимізації запасів і збільшення оборотності.
· Програми лояльності. За допомогою методів глибокого аналізу даних можна
зрозуміти особливості споживання клієнтів і відношення покупців до маркетингових
програм, виявити цільові групи. Це дасть можливість будувати ефективні програми
лояльності, що не зводяться просто до надання знижок, а враховують особливості кожної
групи покупців і пропонують їм саме те, що їх зацікавить.
· Стимулювання попиту. Аналіз споживчого кошика дозволяє знаходити самі ходові
сполучення товарів і пропонувати саме ті продукти, які викличуть найбільший інтерес,
правильно розмістити товари на полках, організувати системи знижок.
· Аналіз залежностей. Порівняння обсягів продажів різних товарів у часі для
виявлення необхідних асортиментів – «кошика».
· Зіставлення (порівняльний аналіз). Порівняння результатів продажів у часі, або за
заданий період, або для заданої групи товарів.
· Закупівлі. Можливих завдань при аналізі закупівель множина, від планування
коштів на основі минулого досвіду, до контролю за менеджерами, що вибирають
постачальників.
· Склад. Аналіз структури залишків на складі в розрізі видів товарів, складів, аналіз
строків зберігання товарів, аналіз відвантаження по одержувачах і багато інші важливі для
підприємства види аналізів можливі при наявності в організації складського обліку.
За допомогою OLAP-систем можна вирішити й інші завдання, актуальні для
компаній роздрібної торгівлі: розрахунок показників ефективності, бюджетування, оцінка
ефективності маркетингових дій і т.д.
Телекомунікації – розв'язувані завдання, насамперед, пов'язані із програмами
лояльності й утриманням існуючої клієнтської бази, а також із залученням нових
споживачів.
· Побудова профілів клієнтів. Технології OLAP-систем дозволяють розділити
абонентів на групи, виявляючи їхнє схоже поводження в частоті, тривалості й часі
дзвінків, а також щомісячних витрат. Це дозволить вирішити задачу розробки
маркетингових акцій, спрямованих на певні групи клієнтів, оцінки найбільше й найменш
дохідних сегментів.
· Адресне розсилання абонентам. У компаній регулярно з'являються додаткові
послуги, змінюються тарифи, проводяться сезонні акції. Методи OLAP-систем
допомагають вирішувати задачу виділення тих існуючих клієнтських сегментів, кому в
першу чергу можуть бути цікаві нові пропозиції.
 · Запобігання відходу клієнтів. Актуальні завдання, метою яких є виявити причини
відходу й оцінити ймовірність відходу клієнта із заданими показниками. На основі
результатів таких досліджень можна розробити методи роботи із клієнтами, щоб
підвищити їхня лояльність до компанії.
Медицина
· Консолідація даних. За допомогою СД можна консолідувати всю інформацію, що
має відношення до розв'язуваних задач: дані з медичних карт, результати аналізів і проб,
вихідні показники діагностуючих тест-систем. Механізми інтеграції дають можливість
одержати дані практично з будь-якого джерела: від офісних застосувнь до спеціалізованих
медичних систем.
· Діагностика захворювань. На базі OLAP-технологій легко створювати системи для
діагностики захворювань, що радять, які використовують накопичені дані клінічних
досліджень, автоматично виявляють значимі ознаки й моделюють складні залежності між
симптомами й захворюваннями.
· Виявлення побічних ефектів. Виявлення зв'язків між прийомом препаратів і
побічних ефектів.
· Дослідження ефективності нових методівлікування.

Багатомірність в OLAP-застосуваннях може бути розділена на три рівні.

· Багатомірне представлення даних
Засоби кінцевого користувача, що забезпечують багатомірну візуалізацію й
маніпулювання даними; шар багатомірного представлення абстрагований від фізичної
структури даних і сприймає дані як багатомірні.
· Багатомірна обробка
Засіб (мова) формулювання багатомірних запитів (традиційна реляційна мова SQL
тут виявляється непридатною) і процесор, що вміє обробити й виконати такий запит.
· Багатомірне зберігання
Засоби фізичної організації даних, що забезпечують ефективне виконання
багатомірних запитів.
Перші два рівні в обов'язковому порядку присутні у всіх OLAP-засобах. Третій
рівень, хоча і є широко розповсюдженим, не обов'язковий, тому що дані для
багатомірного представлення можуть витягати й зі звичайних реляційних структур;
процесор багатомірних запитів у цьому випадку транслює багатомірні запити в SQL-
запити, які виконуються реляційною СКБД.
Теоретично засоби OLAP можна застосовувати й безпосередньо до оперативних
даних або їхніх точних копій (щоб не заважати оперативним користувачам). Але в цьому
випадку існує певний ризик, оскільки будуть аналізуватися оперативні дані, які прямо для
аналізу непридатні.
Основні способи реалізації багатомірної моделі
В основі OLAP лежить ідеябагатомірної моделі даних, у якій на зміну таким
поняттям як відношення й сутності приходять поняття вимірів і кубів даних.
З погляду аналізу кожний аналізований факт зручно розглядати як функцію від його
характеристик. Наприклад, виробництво виробу є функція від матеріалів, верстатів,
робітників, інженерів, технологів, керівників, можливо, ще якихось істотних параметрів.
Параметри такого типу називаються вимірами.
По типі вхідної БД продукти OLAP діляться на наступні класи.
MOLAP (Multidimensional OLAP) – для реалізації багатомірної моделі
використовуються багатомірні БД. При цьому дані зберігаються у вигляді впорядкованих
багатомірних масивів. Такі масиви підрозділяються на гіперкуби, у яких всі збережені в
БД комірки мають однакову мірність, і полікуби, у яких кожна комірка зберігається із
власним набором вимірів. Фізично дані зберігаються в «плоских» файлах, при цьому куб
представляється у вигляді однієї плоскої таблиці, у яку рядками вписуються всі комбінації
елементів всіх вимірів з відповідними їм значеннями мер.
Виміри Міри
Магазин Час Постачальник Товар Одиниці товару Вартість товару
№1 01.01.09 Іванов Картопля 100 20
№1 01.01.09 Іванов Морква 50 25
№1 01.02.09 Іванов Картопля 150 20
№2 01.02.09 Петров Морква 200 25

Дані передаються від джерела даних у багатомірну базу даних, а потім база даних
піддається агрегації. Попередній розрахунок прискорює OLAP-запити, оскільки
розрахунок зведених даних уже зроблений. Час запиту стає функцією винятково часу,
необхідного для доступу до окремого фрагмента даних і виконання розрахунку. Цей
метод підтримує концепцію, відповідно до якої робота виконується один раз, а результати
потім використовуються знову й знову. Багатомірна база найчастіше буде надлишковою.
Куб, побудований на її основі, буде сильно залежати від числа вимірів. При збільшенні
кількості вимірів об'єм куба буде експоненційно рости. Іноді це може привести до
«підривного росту» обсягу даних, що паралізує в результаті запити користувачів.
«Вибух» бази даних являє собою феномен багатомірних баз. Це пов'язане з
розрідженістю бази даних і попередньою агрегацією даних. Якщо багатомірна база даних
містить невелике число елементів даних, порівнянне з кількістю забезпечуваних нею
рівнів агрегації, кожний фрагмент даних буде вносити більший вклад в усі одержувані з
нього дані. Коли база даних «вибухає», розмір її стає істотно більше, ніж він повинен
бути.

Переваги використання MOLAP:

· пошук і вибірка даних здійснюється значно швидше, ніж при багатомірному
концептуальному погляді на реляційну БД, тому що багатомірна БД денормалізована й
містить заздалегідь агреговані показники, забезпечуючи оптимізований доступ до
запитуваних комірок і не вимагаючи додаткових перетворень при переході від множини
зв'язаних таблиць до багатомірної моделі; середній час відповіді на нерегламентований
запит при використанні багатомірної СКБД звичайно на один-два порядки менше, ніж у
випадку реляційної СКБД із нормалізованою схемою даних;
· у випадку багатомірних БД легко включити в інформаційну модель різноманітні
убудовані функції, тоді як обмеження мови SQL роблять виконання цих задач на основі
реляційних БД досить складним, а іноді й неможливим;
· структура й інтерфейси щонайкраще відповідають структурі аналітичних запитів.
Цей спосіб більше схожий з ментальною моделлю людини, тому що аналітик звик
оперувати плоскими таблицями. Провадячи перетин куба двовимірною площиною в тім
або іншому напрямку, легко одержати взаємозалежність будь-якої пари величин щодо
обраної міри. Наприклад, як змінювалася вартість виготовлення виробу (міра) у часі
(вимір) у розрізі по ділянках, цехам і виробництвах (інший вимір).
Недоліки MOLAP:
· за рахунок денормалізації й попередньо виконаної агрегації обсяг даних у
багатомірній БД, як правило, відповідає (по оцінці Кодда) в 2,5... 100 разів меншому
обсягу вхідних деталізованих даних;
· у переважній більшості випадків інформаційний гіперкуб є сильно розрідженим, а
оскільки дані зберігаються в упорядкованому виді, невизначені значення вдається
видалити тільки за рахунок вибору оптимального порядку сортування, що дозволяє
організувати дані в максимально великі безперервні групи. Крім того, оптимальний з
погляду зберігання розріджених даних порядок сортування, швидше за все, не буде
збігатися з порядком, що найчастіше використовується в запитах. Тому в реальних
системах доводиться шукати компроміс між швидкодією й надмірністю дискового
простору, зайнятого базою даних;
· багатомірні БД чутливі до змін у багатомірній моделі. Наприклад, при додаванні
нового виміру доводиться змінювати структуру всієї БД, що спричиняє великі витрати
часу.

На підставі аналізу достоїнств і недоліків багатомірних БД можна виділити наступні

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

ROLAP (Relational OLAP) – для реалізації багатомірної моделі використовуються

реляційні БД.
Достоїнства:
· у більшості випадків корпоративні СД реалізуються засобами реляційних СКБД, і
інструменти ROLAP дозволяють виконувати аналіз безпосередньо над ними. При цьому
розмір сховища не є таким критичним параметром, як у випадку MOLAP;
· у випадку змінної розмірності задачі, коли зміни в структуру вимірів доводиться
вносити досить часто, ROLAP-системи з динамічним представленням розмірності є
оптимальним рішенням, тому що в них такі модифікації не вимагають фізичної
реорганізації БД;
· реляційні СКБД забезпечують значно більш високий рівень захисту даних і гарні
можливості розмежування прав доступу.
Головний недолік ROLAP у порівнянні з багатомірними СКБД – менша
продуктивність. Для забезпечення продуктивності, порівнянної з MOLAP, реляційні
системи вимагають ретельного пророблення схеми бази даних і настроювання індексів.

HOLAP (Hybrid OLAP) – для реалізації багатомірної моделі використовуються й

багатомірні, і реляційні БД. HOLAP-сервери використовують гібридну архітектуру, що
поєднує технології ROLAP і MOLAP. На відміну від MOLAP, що працює краще, коли
дані більш-менш щільні, сервери ROLAP показують кращі параметри в тих випадках,
коли дані досить розріджені. Сервери HOLAP застосовують підхід ROLAP для
розріджених областей багатомірного простору й підхід MOLAP – для щільних областей.
Сервери HOLAP розділяють запит на кфлька підзапитів, направляють їх до відповідних
фрагментів даних, комбінують результати, а потім надають результат користувачеві.

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

1. У чому складаються основні розходження між системами оперативної обробки
даних і системами оперативного аналізу даних?
2. Перелічите користувачів аналітичних систем.
3. Які типи даних використовуються в аналітичних системах?
4. Опишіть функції аналітичних систем.
5. Який тест описує вимоги до застосувань для багатомірного аналізу?
6. Що описують правила Кодда?
7. Перелічите основні характеристики OLAP-Систем.
8. Які рівні багатомірності даних Ви знаєте?
 9. Назвіть достоїнства й недоліки МOLAP реалізації багатомірної моделі.
10. У чому складаються основні достоїнства ROLAP?

Методичні вказівки до лекції: [1, с. 2-–23]; [2, с. 44–45, 48–57]; [4, с. 873–875]; [5,
с. 848–949, 985–986]; [6, с. 64–79]..

Вправи
1. Приведіть приклади історичних, агрегованих і прогнозованих даних для
предметної області «Оператор кабельного телебачення».
2. Приведіть приклад запитів із системи оперативної обробки даних і аналітичної
системи для обраної Вами предметної області.
3. Приведіть приклад предметної області, для якої корисно створити аналітичну
систему.
4. Приведіть приклади аналітичних запитів для предметної області «Оператор
кабельного телебачення».
5. Додайте приклади аналітичних запитів для предметної області «Медицина».
 ЛЕКЦІЯ №4
Архітектура сховища даних

Розглядаються наступні питання:

· архітектури СД, розповсюджені в цей час;
· фактори, що впливають на вибір архітектури;
· практичні ради на вибір архітектури СД;
· успіх архітектур;
· віртуальні сховища даних.

На сьогоднішній день запропонована множинаархітектур, серед них

найпоширеніші:
1) незалежні вітрини даних (independent data marts);
2) шина взаємозалежних вітрин даних (data-mart bus architecture with linked
dimensional data marts);
3) архітектура «зірка» (hub-and-spoke);
4) централізоване сховище даних (centralized data warehouse);
5) федеративна архітектура (federated architecture).

Незалежні вітрини даних

Нерідка ситуація, коли кожний підрозділ компанії розробляє свою власну вітрину
даних.
Вітрина даних(кіоск, секція, крамниця, ринок, вітрина) містить інформацію, що
відноситься до окремого аспекту діяльності корпорації. По суті справи, вітрина даних
(ВД) – це полегшений варіант СД, що містить тільки тематично об'єднані дані. Цільова
база даних максимально наближена до кінцевого користувача й може містити
тематично орієнтовані агрегатні дані. Вітрина даних, природно, істотно менше по
об'єму, чим корпоративне СД, і для її реалізації не потрібно особливо потужна
обчислювальна техніка. ВД впроваджуються набагато швидше й швидше видний ефект
від їхнього використання.
Всі вітрини задовольняють потреби, для яких створювалися, але при цьому не
залежать друг від друга й не забезпечують єдиного представлення про ситуацію в
компанії. У них неузгоджено задані дані, використовуються різні виміри й показники, а,
отже, аналіз даних між вітринами утруднений.
Шина взаємозалежних вітрин даних
Запропонована Ральфом Кимбеллом (Ralph Kimball).
Створення такої архітектури починається з аналізу вимог для конкретних бізнес-
процесів, таких як замовлення, клієнти, рахунки й ін. Перша вітрина даних будується для
одного бізнес-процесу з використанням вимірів і показників, які надалі будуть
застосовуватися в інших компонентах.
Наступні вітрини даних розробляються з використанням цих вимірів, що в
результаті приводить до створення логічно інтегрованих вітрин.
Архітектура «Зірка»
Просувається відомим експертом в області сховищ даних Білом Інмоном (Bill
Inmon). Являє собою централізоване сховище даних із залежними вітринами даних.
На основі використання корпоративного представлення даних виконується
ітеративна розробка архітектури, при цьому залучається одна предметна область за
іншою. Детальні дані зберігаються в нормалізованій формі в сховищі даних. Залежні ВД
одержують дані зі сховища даних.
Залежні ВД розробляються для підрозділів або конкретних функціональних
областей, цілей (наприклад, для data mining) і можуть бути як нормалізованими, так і
денормалізованими, або у вигляді будь-якої агрегованої структури даних. Більшість
користувачів виконує запити на залежних вітринах даних.
Така архітектура має три рівні:
1) корпоративне СД на основі однієї із сучасних реляційних СКБД. Це СД
інтегрованих в основному деталізованих даних. Реляційні СКБД забезпечують ефективне
зберігання й керування даними дуже великого обсягу, але не занадто добре відповідають
потребам OLAP-систем, зокрема, у зв'язку з вимогою багатомірного представлення даних;
2) вітрини даних на основі багатомірної СКБД (приклад - Oracle Express Server).
Такі СКБД майже ідеально підходять для цілей розробки OLAP-систем, але не
дозволяють зберігати надвеликі обсяги даних. У цьому випадку це й не потрібно, оскільки
мова йде про вітрини даних. Вітрина даних не обов'язково повинна бути повністю
сформована. Вона може містити посилання на СД і добирати звідти інформацію по мірі
надходження запитів. Це збільшує час відгуку, але знімає проблему обмеженого обсягу
багатомірної БД;
3) клієнтські робочі місця кінцевих користувачів, на яких установлюються засоби
оперативного аналізу даних.
Достоїнства архітектури корпоративного сховища даних
· несуперечність інформації;
· один набір процесів витягу й бізнес-правил;
· загальна семантика;
· централізоване, кероване середовище;
· легко створювані й наповнювані вітрини даних;
· єдиний репозіторій метаданих;
Недоліки такого архітектурного рішення СД
· реалізація вимагає великих витрат;
· висока ресурсоємність;
· потреба в системах і ресурсах у масштабі всього підприємства;
· ризикований сценарій («усе поставлено на карту»).
Іноді архітектуру «зірка» називають підходом «зверху донизу», а шину вітрин даних
- підходом «знизу нагору», тому що перша орієнтована на спочатку задану
інфраструктуру й процеси, а шина вітрин даних – на розробку проекту, у якому
вирішуються критичні бізнеси-завдання.
Централізоване сховище даних (без залежних вітрин)
Ця архітектура схожа на архітектуру «зірка» за винятком відсутності залежних
вітрин даних. Сховище даних містить детальні дані, деяку кількість агрегованих даних і
логічні представлення. Запити й застосування виконуються як на реляційних даних, так і
на багатомірних представленнях.
Федеративна архітектура
У цій архітектурі використовуються вже існуючі структури підтримки прийняття
рішень (операційні системи, вітрини й сховища даних). Дані витягають із перерахованих
систем на основі бізнесів-вимог. Дані логічно або фізично інтегруються за допомогою
метаданих, розподілених запитів і інших методів. Ця архітектура є практичним рішенням
для компаній, які вже користуються аналітичними засобами й не хочуть від них
відмовлятися.
Достоїнства системи об'єднаних СД
· загальна семантика й бізнес-правила;
· один набір процесів витягу й бізнес-правил;
· децентралізовані ресурси й керування;
· паралельна розробка.
Недоліки такого архітектурного рішення
· необхідність у координуванні робіт;
· складності в подоланні «політичних» моментів і рішенні питань авторських прав;
 · потрібна погодженість серед різних відділів з питань архітектури, бізнес правил і
семантики;
· найскладніше технічне середовище;
· дуже часта наявність численних репозіторіїв метаданих.

Фактори, що впливають на вибір архітектури

Відповідно до досліджень компанії TDWI, існує 10 основних факторів, що
впливають на вибір архітектури.
Раціональні фактори
1) Інформаційна залежність між організаційними підрозділами
Високий рівень інформаційної залежності виникає в тих організаціях, де один
підрозділ залежить від відомостей, що надходять із іншого. У цій ситуації можливість
спільного використання й інтеграції інформації дуже важлива.
2) Інформаційні потреби керівництва
Вищому керівництву часто потрібна інформація про більш низькі організаційні
рівні. Іноді виникає потреба поглибитися в детальні дані й розібратися в діяльності
конкретного підрозділу або переконатися, що компанія виконує необхідні нормативні
вимоги.
3) Терміновість впровадження сховища даних
4) Характер користувальницьких задач
Ряд користувачів виконує складні й нестандартні задачі. Для реалізації їхніх потреб
недостатньо структурованих запитів і звітів. Їм необхідно аналізувати дані новими
способами, а отже, мати в розпорядженні таку архітектуру, що дозволить аналізувати дані
«на лету», нетривіальними методами.
5) Обмежені ресурси
Деякі види сховищ даних вимагають більше ресурсів, ніж інші. У результаті на
виборі архітектури може відбитися доступність IT-персоналу, бізнесів-співробітників і
матеріальних засобів.
6) Стратегічне представлення сховища даних до впровадження
Різні компанії мають різні плани застосування сховища даних. Іноді необхідно
«точкове рішення» для конкретного підрозділу, а іноді – інфраструктура підтримки
прийняття рішень, що містить множину застосувань.
7) Сумісність із існуючими системами
8) Можливості персоналу
Впровадження деяких архітектур уважається більш складним залежно від навичок і
досвіду технічного персоналу, наявності позитивного досвіду в аналогічних проектах і від
рівня конфіденційності.
Технічні фактори
Вибір на користь тієї або іншої архітектури робиться залежно від важливості
наступних технічних питань.
1) можливість інтеграції метаданих;
2) масштабованість користувачів;
3) обсяги даних;
4) ефективність запитів;
5) можливість підтримки історичних даних;
6) адаптація до змін (наприклад, у вихідних системах).
Соціальні фактори
Один із соціальних факторів – вплив експертів. Ухвалення рішення – це процес
переговорів, створення коаліцій, де відіграє роль множина амбіційних цілей. Не можна
сказати, що в кожної компанії є одне єдине завдання, що впливає на вибір архітектури.
Для оптимізації й балансу цілей, а отже, і для вибору архітектури необхідно вдаватися до
допомоги експертів.
 Іноді в ролі експертів виступають консультанти, іноді власні користувачі. У деяких
випадках інформація черпається на семінарах, конференціях і інших заходах. Кожний із
цих факторів до деякої міри впливає на вибір архітектури. Дуже часто цей суб'єктивний
вплив, пов'язане з особистим успішним досвідом фахівця.
У результаті досліджень і опитувань, проведених TDWI, було з'ясовано, що всі
перераховані вище фактори (що ставляться до кожної із трьох груп) мають своє значення.
Найважливіші фактори – взаємозалежність між організаційними підрозділами, стратегічне
представлення про сховище даних до його впровадження й інформаційні потреби вищого
керівництва. Можливості технічного персоналу – на останнім місці, однак вони мають
певну вагу й грають далеко не найменшу роль.

Один із практичних фахівців в області впровадження BI Брайан Шварбрик (Brian

Swarbrick) назвав питання, які необхідно розглянути при виборі кращої архітектури BI-
рішення.
1. Чи продуманий і чи заданий масштаб проекту? Чи будується рішення для
підтримки вимог відділу або як фундамент корпоративного проекту, якому необхідно
поступово розширювати для підтримки майбутніх вимог і інших підрозділів? Якщо
завдання обмежується одним відділом, то архітектура може бути простіше. Однак якщо
передбачається довгострокове рішення, то підхід необхідно ретельно продумати. При
виборі повинні враховуватися як архітектурні аспекти, так і погодженість із
організаційними й IT-стратегіями й майбутніми планами.
2. Чи важливо відокремити компоненти інтеграції даних від аналітичних
компонентів і чому? (Мова йде про корпоративні рішення як для короткострокових, так і
для довгострокових завдань). Вхідні дані можуть надходити як зсередини організації, так і
ззовні. Дані можуть уже існувати або з'явитися завтра, або надійти у віддаленому
майбутньому. Правила інтеграції даних можуть бути складними. Крім того, необхідно
враховувати вимоги до звітності. Зокрема, одним зі шляхів є поділ і моделювання шарів
даних і шарів звітності. У результаті забезпечується гнучкість і облік постійно додаваних
й змінюваних бізнесів-вимог.
3. Організаційний інтерес до якості даних. Якщо якість даних не грає принципової
ролі, а звітні вимоги виходять від підрозділів (а не від компанії в цілому), то найкраще
вибрати найпростіше звітне програмне забезпечення. Якщо ж завдання підвищення якості
даних стоїть гостро, то краще вибрати рішення, описане в пункті 2. Розробка
архітектурного шару, орієнтованого на збір і інтеграцію даних, має на увазі подальше
розширення й впровадження підтримки якості. Така архітектура дозволяє підвищувати
якість даних, а також звітності й аналітичних операцій.
4. Гнучкість для майбутнього росту. Часто збір і інтеграція даних, а також вітрини
даних будуються на одній базі. Підготовчі шари звичайно тимчасові й використовуються
для підтримки поточних вимог до звітності (заданих ще до початку проекту). У міру зміни
вимог і надходження нових, вітрини даних розширюються. Але часто такі проекти не
вдається розширити до корпоративних масштабів без істотної переробки. Якщо
відповідно до нових вимог необхідні дані, недоступні у вітрині даних або доступні в
іншому форматі, то вітрина даних втрачає зміст. Вітрини даних гарні для підтримки
відомих бізнес-вимог, але при цьому недостатньо гнучкі при їхній зміні.
5. Бюджет. Корпоративні проекти бувають дорогими. Звичайно вони містять
множину компонентів, і не завжди є час на розробку «одноразових» вітрин даних для
підрозділів. Час на підтримку й розробку збільшується. Однак якщо грамотно продумати
архітектуру, то проект можна виконати досить швидко. Кращим є ітеративний підхід,
заснований на структурованій архітектурі й методології, що дозволяє швидко створювати
корпоративну інфраструктуру й забезпечувати користь для бізнесу на кожному з етапів
процесу.
 6. Проект буває успішним лише тоді, коли в ньому використовуються необхідні
ресурси й навички. Організація повинна забезпечити матеріальні можливості й кадри. Для
локальних (усередині відділу) проектів зусиль буде потрібно менше.

Успіх архітектур
На думку TDWI, архітектурою, що домінує, є зірка, за нею йде шина вітрин даних і
централізована архітектура, і лише невеликий відсоток проектів заснований на
незалежних вітринах даних і федеративній архітектурі.
Централізоване сховище даних частіше вибирають, коли впровадження потрібно
провести терміново, обмеженість ресурсів вище й більше розрахунку на власний
персонал.
Архітектура «зірка» найчастіше використовується в корпоративних проектах для
створення великих сховищ даних. Це самі довгострокові й дорогі проекти, однак і самі
результативні. Функціональне охоплення таких проектів ширше, і розмір сховища даних
більше. Ця архітектура вимагає більшого утягування керівництва й планування, а отже,
матеріальних і часових ресурсів.
Шина вітрин часто вибирається в тій ситуації, коли ресурсів цілком достатньо,
представлення про сховище даних не носить чіткої стратегічної орієнтації, і сумісність із
уже впровадженими засобами не грає принципової ролі.
Лише деякі компанії вибирають федеративну архітектуру, зокрема, ті, хто
обмежений по строках. У деяких організацій уже використовуються розрізнені платформи
прийняття рішень у результаті злиттів і поглинань. Тому вони й застосовують
федеративний підхід, найбільше швидко реалізований. Тут більшу роль грає фактор
інформаційної залежності між підрозділами компанії й інформаційних потреб керівництва
Незалежні вітрини даних мають найнижчі оцінки серед користувачів. Це зайвий раз
підтверджує загальновідомий факт: ця архітектура далеко не найкраща.
Якщо говорити про інформаційну й системну якість, а також про організаційний
вплив, то про домінування однієї конкретної архітектури мова не йде. Вони розвиваються
й згодом здобувають близькі риси. Наприклад, архітектура «зірка» часто включає вітрини
даних, що лежать в основі архітектури «шина».

Крім фізичних СД, використовуються й віртуальні сховища даних. У такій системі

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

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

1. Опишіть особливості архітектури «зірка».
2. У чому відмінність між архітектурами з незалежними вітринами даних і шиною
вітрин даних?
3. Перелічіть раціональні фактори, що впливають на вибір архітектури СД.
4. Що важливо врахувати при виборі архітектури СД?
5. Чому архітектура «зірка» є домінуючою при розробці СД?
6. Чим віртуальне СД відрізняється від фізичного?
 Методичні вказівки до лекції: [2, с. 26–31]; [4, с. 889–896]; [5, с. 951]; [8, с. 33–34].

Вправи
1. Проаналізуйте, яку архітектуру краще вибрати для реалізації аналітичної системи
діяльності ВЗН.
2. Дайте опис варіантів різних архітектур для предметної області «Медицина» (що
могло б знаходиться в СД і у вітринах даних для кожної архітектури).
 Змістовний модуль 3
Багатомірні куби
Лекція №5
Багатомірний куб. Основні поняття

Розглядаються наступні питання:

· поняття багатомірного простору;
· гіперкубічна й полікубічна моделі;
· типи фактів.

Багатомірне моделювання є методом моделювання й візуалізації даних як множини

числових показників або параметрів (measures), які описують загальні аспекти діяльності
організації. Як правило, при багатомірному моделюванні основна увага фокусується на
числових даних, таких як число продажів, баланс, прибуток, вага, або на об'єктах, які
можна перерахувати, таких як статті, патенти, книги.
Метод багатомірного моделювання базується на наступних основних поняттях:
факти, атрибути, виміри, міри, ієрархія.
Факт (fact) – це набір зв'язаних елементів даних, що містять міри й описові дані.
Кожен факт звичайно представляє елемент даних, що чисельно описує діяльність
організації, бізнес-операцію або подію, що може бути використане для аналізу діяльності
організації або бізнес-процесів.
Атрибут (Аttrіbute) - це опис характеристики реального об'єкта предметної області.
Як правило, атрибут містить заздалегідь відоме значення, що характеризує факт. Звичайно
атрибути представляються текстовими полями з дискретними значеннями. Наприклад,
габарити впакування товару, запах товару.
Вимір (dіmensіon) - це інтерпретація факту з деякого погляду в реальному світі.
Виміри, подібно атрибутам, містять текстові значення, які сильно зв'язані за змістом між
собою. Звичайно виміри представляються як осі багатомірного простору, крапками якого
є пов'язані з ними факти. У багатомірній моделі кожен факт пов'язаний з однієї або
декількома осями. Виміри звичайно представляють нечислові, лінгвістичні змінні, такі як
філії організації, співробітники організації, покупці й т.д.
Наприклад, при аналізі продажів продукції, виробленою або продаваною
організацією, такими вимірами звичайно вступають час, покупці, продавці, місце продажу
або складування товару.
Виміри задаються перерахуванням своїх елементів (members). Елемент виміру
(dіmensіonal member) - унікальне ім'я, використовуване для визначення позиції елемента.
Наприклад, вимір «Час» може містити наступні елементи: «всі місяці», «квартали»,
«роки».
Часто елементи виміру перебувають у відношенні «частина-ціле» або «батько-
нащадок», що дозволяє ввести на вимірі одну або кілька ієрархій. Кожна ієрархія може
мати кілька рівнів ієрархії (hіerarchy levels). Кожен елемент виміру повинен належати
тільки одному рівню ієрархії, породжуючи в такий спосіб розбивка на непересічні
підмножини. Прикладом може служити ієрархія на вимірі «Час»: рік, півріччя, квартал,
місяць й день.
Міра (параметр, метрика або показник) (measure) – це числова характеристика
факту, що визначає ефективність діяльності або бізнес-дії організації з погляду виміру.
Конкретні значення міри описуються за допомогою змінних. Наприклад, нехай мірою є
чисельне вираження продажів товару в грошах, кількість проданих одиниць товару й т.д.
Міра визначається за допомогою комбінації елементів вимірів й, таким чином,
представляє факт.
Багатомірна модель візуально представляється за допомогою куба (або у випадку
більше трьох вимірів – гіперкуба).
 Куб OLAP – це структура, у якій зберігаються сукупності даних, отримані з бази
даних OLAP шляхом всіх можливих сполучень вимірів з фактами.
Багатомірний простір даних може мати будь-яку кількість вимірів. Такий простір
дискретний й містить дискретну кількість значень на кожному вимірі. Розмірність
простору математично визначається перемножуванням розмірів всіх вимірів. Оскільки
кожний вимір дискретний, той простір є обмеженим (кінцевим).
Виміри представлені осями куба, по яких відкладають значення, що відносяться до
аналізованої предметної області, наприклад, назви товарів і назви місяців року. Такі
значення, що «відкладаються» уздовж вимірів, називаються Членами або Мітками
(members).
Мітки (Members) y1 y2 y3

x1
x2
x3

Комірка (Cell)
z3 U313 U323 U333

z2 U312 U322 U332

z
z1 U311 U321 U331

Пуста комірка (Empty Cell)

y
Виміри (Dimensions) Міра (Measure)
x

Рис.2. Елементи багатомірного куба

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

функцій упорядкування або відстані для значень виміру. Єдине «упорядкування» полягає
в тому, що значення більш високого рівня містять значення більш низьких рівнів. Однак
для деяких вимірів, таких як час, упорядкованість значень розмірності може
використовуватися для обчислення сукупної інформації, такої як загальний обсяг
продажів за певний період.
У різних БСКБД використовуються два основних варіанти організації даних:
гіперкубічна модель і полікубічна модель. У другому випадку припускають, що в ББД
може бути визначено кілька гіперкубів з різною розмірністю й з різними вимірами в якості
їхніх граней. У полікубічній моделі в цьому випадку може бути оголошено два різних
гіперкуби:
· двомірний – для показника Робочий Час Менеджера, визначається Днем і
Менеджером;
· тривимірний – для показника Обсяг Продажів визначається Моделлю комп'ютера,
Днем і Менеджером.
У випадку ж гіперкубічної моделі передбачається, що всі показники повинні
визначатися тим самим набором вимірів. Тобто тільки через те, що Обсяг Продажів
визначається трьома вимірами, при описі Показника Робочий Час Менеджера доведеться
також використовувати три виміри й уводити надлишкове для цього показника вимір
Модель Комп'ютера.
На перетинанні осей вимірів в комірках розташовуються дані, що кількісно
характеризують аналізовані факти.
Комірки куба можуть бути порожні або повні. Коли значне число комірок куба не
містить даних, говорять, що він «розріджений».
 Цілком звичайні такі набори даних, які містять 1%, 0.01% і навіть меншу частку
можливих даних.
Кожний факт є сукупність однієї або декількох мер. Наприклад, окремий факт
виготовлення містить у собі сукупність як мінімум трьох величин – вартість заготівки,
вартість виготовлення й різні нарахування.
Найбільше часто зустрічаються наступні 4 типи фактів:
1) факти, пов'язані із транзакціями (Transaction facts). Вони засновані на окремих
подіях (типовими прикладами яких є телефонний дзвінок або зняття грошей з рахунку за
допомогою банкомату);
2) факти, пов'язані з «моментальними знімками» (Snapshot facts). Засновані на
стані об'єкта (наприклад, банківського рахунку) у певні моменти часу, наприклад на
кінець дня або місяця. Типовими прикладами таких фактів є обсяг продажів за день або
денний виторг;
3) факти, пов'язані з елементами документа (Line-item facts). Засновані на тім або
іншому документі (наприклад, рахунку за товар або послуги) і містять докладну
інформацію про елементи цього документа (наприклад, кількість, ціну, відсоток знижки);
4) факти, пов'язані з подіями або станом об'єкта (Event or state facts).
Представляють виникнення події без подробиць про нього (наприклад, просто факт
продажу або факт відсутності такого без інших подробиць).
Таблиця фактів є основною таблицею сховища даних. Вона, як правило, містить
унікальний складений ключ, що поєднує первинні ключі таблиць вимірів. Найчастіше це
цілочислені значення або значення типу «дата/час» – адже таблиця фактів може містити
сотні тисяч або навіть мільйони записів, і зберігати в ній повторювані текстові описи, як
правило, невигідно – краще помістити їх у менші по обсягу таблиці вимірів. При цьому як
ключові, так і деякі неключові поля повинні відповідати майбутнім вимірам OLAP-Куба.
Крім цього таблиця фактів містить одне або кілька числових полів, на підставі яких надалі
будуть отримані агрегатні дані.
Як правило, у фактах немає надмірності, вона є тільки у вимірах.
Куб OLAP також може розглядатися як багатомірний масив даних, як правило,
розріджений і довгочасно збережений. Може бути реалізований на основі універсальних
реляційних СУБД або спеціалізованим програмним забезпеченням.
Індексам масиву відповідають виміри (dіmensіons) або осі куба, а значенням
елементів масиву – міри (measures) куба.
На відміну від звичайного масиву в мові програмування, доступ до елементів OLAP-
куба може здійснюватися як по повному наборі індексів-вимірів, так і по їхній
підмножині. Тоді результатом буде не один елемент, а їхня безліч, що є аргументом для
агрегуючої функції.

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

1. Назвіть основні компоненту кубу.
2. Як визначається розмірність кубу?
3. Як звичайно виглядає структура таблиці фактів?
4. Які типи фактів Ви знаєте?

Методичні вказівки до лекції: [2, с. 40–44] ; [3, с. 80-86]; [5, с. 971–976, 984]; [8,с.
30–32].

Вправи
1. Наведіть приклади вимірів для предметної області «Деканат».
2. Наведіть приклади мір для предметної області «Телефонна компанія».
3. Надайте структуру таблиці фактів для предметної області «Поліклініка».
 ЛЕКЦІЯ №6
Ієрархії вимірів. Схеми кубу «зірка» та «сніжинка»

Розглядаються наступні питання:

· класи параметрів;
· ієрархії вимірів;
· схеми «зірка» і «сніжинка»;
· операції, виконувані над гіперкубом.

Параметри складаються із двох компонентів:

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

Виміри організуються в ієрархію, що складається з декількох рівнів, кожний з яких

представляє рівень деталізації, необхідний для відповідного аналізу.
Об'єкти у вимірах можуть бути різного типу, наприклад «виробники» - «марки
автомобіля» або «роки» - «квартали».
Існують наступні типи ієрархій:
- збалансовані (balanced);
- незбалансовані (unbalanced);
- нерівні (ragged).

Збалансована ієрархія – ієрархія, у якій число рівнів визначене її структурою й

незмінно, і кожна галузь ієрархічного дерева містить об'єкти кожного з рівнів.
Кожному виробникові
автомобілів може відповідати
кілька марок автомобілів, а
кожній марці – кілька моделей
автомобілів, тому можна
говорити про трьохрівневу
ієрархію цих об'єктів. У цьому Рис.3. Приклад збалансованої ієрархії
випадку на першому рівні
ієрархії розташовуються виробники, на другому – марки, а на третьому – моделі.
Для формування збалансованої ієрархії необхідна наявність зв'язку «один-до-
багатьох» між об'єктами менш детального рівня стосовно об'єктів більш детального рівня.
У принципі кожний рівень збалансованої ієрархії можна представити як окремий
простий вимір, але тоді ці виміри виявляться залежними, а виходить, неминуче
підвищення розрідженості куба.
Незбалансована ієрархія – ієрархія, у якій число рівнів може бути змінено, і кожна
галузь ієрархічного дерева може містити об'єкти, що належать не всім рівням, тільки
декільком першим.
Всі об'єкти
незбалансованої ієрархії
належать одному типу.
Типовий приклад
незбалансованої ієрархії –
ієрархія типу «начальник-
підлеглий», де всі об'єкти
мають той самий тип –
Рис.4. Приклад незбалансованої ієрархії
«Співробітник».

Нерівна ієрархія - ієрархія, у якій число рівнів визначене її структурою й постійно,

однак на відміну від збалансованої ієрархії деякі гілки ієрархічного дерева можуть не
містити об'єкти якого-небудь рівня.
Ієрархії такого виду містять такі члени,
логічні «батьки» яких не перебувають на
безпосередньо вищестоящому рівні.
Типовим прикладом є географічна
ієрархія, у якій є рівні «Країни», «Штати» і
«Міста», але при цьому в наборі даних є
країни, що не мають штатів або регіонів між
рівнями «Країни» і «Міста».
Рис.5. Приклад нерівної ієрархії
Може бути визначено кілька ієрархій
для виміру.
Вимір Філіал
Регіон філіалу
Регіон1
Філіал A
Філіал B
Регіон2 Двіієрархії
Філіал C
Філіал D
Керівник відділення
Керівник 1
Філіал A
Філіал C
Філіал D
Керівник 2
Філіал B
Рис.6. Приклад множини ієрархій для одного виміру

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

Рис.7. Приклад схеми «зірка»

Особливості схеми «зірка»:

1) Одна таблиця фактів, що сильно денормалізована. Є центральною в схемі,
може складатися з мільйонів рядків і містить агреговані або фактичні дані, за допомогою
яких можна відповісти на різні питання. Кілька денормалізованих таблиць вимірів. Мають
меншу кількість рядків, ніж таблиці фактів, і містять описову інформацію. Ці таблиці
дозволяють користувачеві швидко переходити від таблиці фактів до додаткової
інформації. Кількість рівнів в ієрархії дорівнює кількості стовпців таблиці виміру.
2) Таблиця фактів і таблиці вимірів пов'язані з допомогою зовнішніх ключів.
Первинний ключ таблиці факту цілком складається з первинних ключів всіх таблиць
розмірності.
3) Агреговані дані зберігаються разом з вхідними.
Переваги схеми «зірка»:
Завдяки денормалізації таблиць вимірів спрощується сприйняття структури даних
користувачем і формулювання запитів, зменшується кількість операцій з'єднання таблиць
при обробці запитів.
Недоліки схеми «зірка»:
Денормалізація таблиць вимірів вносить надмірність даних, зростає необхідний для
їхнього зберігання обсяг пам'яті. Якщо агрегати зберігаються разом з вхідними даними, то
у вимірах необхідно використовувати додатковий параметр – рівень ієрархії.

Особливості схеми «сніжинка»

1) Одна таблиця фактів, що сильно денормалізована. Є центральною в схемі,
може складатися з мільйонів рядків і містити агреговані або фактичні дані, за допомогою
яких можна відповісти на різні питання.
2) Кілька таблиць вимірів, які нормалізовані на відміну від схеми «зірка». Ці
таблиці дозволяють користувачеві швидко переходити від таблиці фактів до додаткової
інформації. Первинні ключі в них складаються з єдиного атрибута (відповідають єдиному
елементу виміру). Елементи різних рівнів ієрархії витягають із декількох таблиць,
зв'язаних зовнішніми ключами.
3) Таблиця фактів і таблиці розмірності пов'язані з допомогою зовнішніх ключів.
Первинний ключ таблиці факту цілком складається з первинних ключів всіх таблиць
розмірності.
4) У схемі «сніжинка» агреговані дані можуть зберігатися окремо від вихідних
даних./
Faculty Degree_Dim
Degree_Id: int
Faculty_Id: int
Name: char(250)
Dekan: nvarchar(100)
Balls_degree_A: float
Telefon_faculty: nvarchar(20)
Faculty_name: nvarchar(50)Sub_fakulty Teacher_Dim Balls_degree_K: float
Faculty_short_name: nvarchar(50) Teacher_Id: int
Sub_fakulty_Id: int
Sub_fakulty_id: int
Faculty_id: int
Faculty_id: int
Name: char(250)
First_name: nvarchar(50)
ZavKafedra: nvarchar(50)
imya: nvarchar(50)
Work_Fact
Short_name: nvarchar(15)
otchestvo: nvarchar(50) Teacher_id: int
pol: nvarchar(8) Sub_fakulty_ID: int Status_Dim
passport_seria: nvarchar(20) Faculty_id: int
Status_Id: int
passport_number: nvarchar(20) Degree_id: int
Post_id: int Name: char(250)
Post_Dim Status_id: int Balls_status_A: float
Post_Id: int Balls_status_K: float
Year: int
Name: char(250) Value: int
Balls_post_A: float Comments: char(200)
Balls_post_K: float

Рис.8. Приклад схеми «сніжинка»

Переваги схеми «сніжинка»

Нормалізація таблиць вимірів на відміну від схеми «зірка» дозволяє мінімізувати
надмірність даних і більш ефективно виконувати запити, зв'язані зі структурою значень
вимірів.
Недоліки схеми «сніжинка»
За нормалізацію таблиць вимірів іноді доводиться платити часом виконання запитів.
Для представлення даних, що зберігаються в кубі, застосовуються, як правило,
звичні двовимірні, тобто табличні, представлення, що мають складні ієрархічні заголовки
рядків і стовпців. Двовимірне представлення куба можна одержати, "розрізавши" його
поперек однієї або декількох осей (вимірів), у цьому випадку фіксуються значення всіх
вимірів, крім двох, тобто виходить звичайна двовимірна таблиця. У горизонтальній осі
таблиці (заголовки стовпців) представлено один вимір, у вертикальній (заголовки рядків)
– інше, а в комірках таблиці – значення мер. При цьому набір мер фактично розглядається
як один з вимірів – вибирається для показу або одна міра (і тоді можна розмістити в
заголовках рядків і стовпців два виміри), або показується кілька мір (і тоді одну з осей
таблиці займуть назви мір, а іншу - значення єдиного «нерозрізаного» виміру).
На рис. 9 зображені різні варіанти двовимірного представлення куба:
a) двовимірний зріз куба для однієї міри Продано штук і двох «нерозрізаних»
вимірів – Місце продажу й Час;
b) один «нерозрізане» вимір – Місце продажу, але відображаються значення
декількох мер – Продано штук, Сума продажу й Накладні витрати;
c) двовимірне представлення куба, коли «нерозрізаними» залишається більше двох
вимірів. При цьому на осях зрізу (рядках і стовпцях) будуть розміщені два або більше
виміри куба, що «розріжеться».

а) Двовимірний зріз куба для однієї міри

Україна Росія Польща
Січень 20000 4000 3000
Лютий 30000 6000 3000
Березень 50000 10000 5000
 b)Двовимірний зріз куба для декількох мір
Україна Росія Польща
Продано штук 20000 4000 3000
Сума продажу 30000 6000 3000
Накладні витрати 50000 10000 5000

с) Двовимірний зріз куба з декількома вимірами на одній осі

Січень Лютий
Україна Росія Польща Україна Росія Польща
Продано штук 500 100 50 5000 300 200
Сума продажу 7500 …
Накладні витрати

Рис.9 Різні варіанти двовимірного представлення куба

Операції, виконувані над гіперкубом

1. Зріз (slice-and-dice) – формується підмножина багатомірного масиву даних, що
відповідає єдиному значенню одного або декількох елементів вимірів, що не входять у цю
підмножину.
Приклад. Якщо обмежиться значенням виміру Модель Комп'ютера - Celeron, то
вийде підмножина гіперкуба (у цьому випадку – двомірна таблиця), що містить
інформацію про історію продажів цієї моделі різними менеджерами в різні роки.
2. Обертання (rotating) – зміна розташування вимірів, представлених у звіті або на
відображуваній сторінці. Наприклад, операція обертання може полягати в перестановці
місцями рядків і стовпців таблиці. Крім того, обертанням куба даних є переміщення
позатабличних вимірів на місце вимірів, представлених на відображуваній сторінці, і
навпаки.
Приклад для першого випадку.Є звіт, для якого елементи виміру "Час"
розташовуються поперек екрана (заголовки стовпців таблиці), а елементи виміру
«Комп'ютери» – уздовж екрана (заголовки рядків таблиці). Після застосування операції
обертання звіт буде мати такий вигляд: елементи виміру «Комп'ютери» будуть
розташовані по горизонталі, а елементи виміру «Час» – по вертикалі.
3. Консолідація (roll-up) і деталізація (drill-down) – операції, які визначають
перехід нагору по напрямку від детального представлення даних до агрегованого й
навпаки, відповідно. Напрямок деталізації (узагальнення) може бути заданий як по ієрархії
окремих вимірів, так і згідно іншим відношенням, установленим у рамках вимірів або між
вимірами.
Приклад.Проаналізувавши, наскільки успішно в 2010 р. Петров продавав моделі
Pentium і Athlon, директор може захотіти довідатися, як виглядає співвідношення
продажів цих моделей на рівні Підрозділу, де Петров працює. А потім одержати
аналогічну довідку по Регіоні або Фірмі.
4. Злиття (drill-across) комбінує куби, які мають одне або кілька загальних вимірів.
З погляду реляційної алгебри така операція виконує з'єднання (join).
5. Ранжирування (ranking) повертає тільки ті комірки, які з'являються у верхній
або нижній частині впорядкованого певним чином списку, наприклад, 10 самих
продаваних продуктів у конкретному місті в 2009 році.

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

5. У чому відмінність між збалансованою й незбалансованою ієрархіями?
6. У чому відмінність між збалансованою й нерівною ієрархіями?
 7. Що загального між збалансованою й нерівною ієрархіями?
8. Які типи фактів Ви знаєте?
9. Опишіть особливості схеми «зірка».
10. Опишіть особливості схеми «сніжинка».
11. Дайте порівняльний аналіз схем «зірка» і «сніжинка».
12. Які операції над кубами Ви знаєте?

Методичні вказівки до лекції: [2, с. 40–44] ; [3, с. 80-86]; [5, с. 971–976, 984]; [8,с.
30–32].

Вправи
4. Приведіть приклад збалансованої, незбалансованої й нерівної ієрархії.
5. Приведіть приклади декількох ієрархій для виміру Час.
6. Приведіть приклади декількох ієрархій для виміру Товар.
7. Приведіть приклад адитивного, неадитивного й полуадитивного параметра для
предметної області «Аптека».
8. Дайте приклад схеми «зірка» і «сніжинка» для предметної області «Агентство
нерухомості».
9. Приведіть приклад двовимірного представлення різних типів для куба із
предметної області вправи 5.
 ЛЕКЦІЯ №7
Агрегація даних у багатомірному кубі

Розглядаються наступні питання:

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

Розглянемо приклад
Таблиця фактичних даних
Регіон Продукт Час Продаж
Р1 Книги Весна 9
Р1 Їжа Осінь 3
Р2 Книги Осінь 6

Куб з агрегованими значеннями

Агрегуюча функція - AVG
AVG
Регіон Продукт Час
(Продаж)
Р1 Книги Весна 9
Р1 Їжа Осінь 3
Р2 Книги Осінь 6
Р1 Книги All 9
All Книги Весна 9
…
Р2 All All 6
All Їжа All 3
All All Весна 9
All All All 6

Схема агрегування даних для формування куба показана на рис.9.

d
Розмір куба даних визначається по формулі Õ ( ni + 1) , де d – кількість вимірів, ni –
i =1
кількість різних значень у вимірі, «+1» відповідає значенню All, агрегуючему всі
можливі значення виміру.
Таким чином, при базовій таблиці в 3 рядки результуючий куб у вигляді простої
реляційної таблиці, у якій прямо зберігаються всі агрегати, має 27 рядків.
По кожному вимірі можна задавати власну (і не одну) функцію агрегації.
З погляду складності розпаралелювання агрегуючі функції можна поділити на
наступні класи:
Дистрибутивні функції – дозволяють розбивати вхідні дані й обчислювати окремі
підсумки, які потім можна поєднувати, наприклад, sum, count, min, max.
Алгебраїчні функції – можна представити комбінацією з дистрибутивних функцій
sum ()
(наприклад, Average() можна представити як .
count ()
 Холістичні функції – неможливо обчислювати на часткових даних або представляти
яким-небудь образом, наприклад, rank().

avg

За регіонами
Р1 А
рег грегу
Р2 іон ван
ам
и ня
ро , ча за
avg ку сом
За часом року
Весна Літо
За регіонами
Р1 avg
Р2 avg
avg avg avg

За продуктами За часом року

Весна Літо
Їжа
Книги
За регіонами
Р1
Р2

Рис. 9. Агрегування даних

Види запитів до кубів

Крапкові запити (Point queries) – вертається агрегуюче значення міри в якійсь комірці
куба, координати якої задаються в запиті. Всі інші запити можна переписати,
використовуючи серії крапкових запитів. Тому час виконання крапкових запитів є однієї з
найважливіших характеристик алгоритму зберігання OLAP даних.
SELECT SUM(продажі) FROM Продажі
WHERE (регіон = Р1) AND (продукт = книги) AND (сезон = весна)
Результат: комірка (Р1, книги, весна)
Інтервальні запити (Range queries) – вертається деякий набір крапок куба, що задовольняє
заданим умовам.
SELECT регіон, продукт, SUM(продажі) FROM Продажі
WHERE ((регіон = Р1) OR ((регіон = Р2)) AND ((продукт = книги) OR (продукт = їжа))
GROUP BY регіон, продукт
Результат: продажі книг і їжі в Р1 і Р2
Зворотні запити (Iceberg queries) – на відміну від крапкових й інтервальних запитів, для
відповіді на запит даного типу використовуються значення міри (агрегуючі значення).
Зворотний запит повертає всі комірки куба, що задовольняють обмеженням, накладеним
на значення міри користувачем.
SELECT регіон, продукт, час, AVG(продажі)
FROM Продажі
GROUP BY регіон, продутий, час
HAVING AVG(продажі) >= 6
(в умові HAVING полягає обмеження на значення міри)

«Вибух» даних
При додаванні вихідних даних у куб обсяг даних і час обчислення куба ростуть
експоненційльно, тому що необхідно розраховувати агрегати по кожному з вимірів.
Наприклад, десятивимірний куб без ієрархії усередині вимірів з кількістю значень 100 для
кожного виміру приводить до структури з 10110=1,120 комірками. Навіть якщо припустити
розрідженість 1 до 106 (тобто тільки один з мільйона комірок містить дані), куб однаково
буде мати 1,114 непустих комірок. Якщо порожні значення досить легко стискуються, то
«вибухом даних» називають ріст кількості агрегатів по всіх вимірах, які необхідно
обчислити. Тобто додавання однієї комірки в куб з 10 вимірами, що містять підсумки,
приводить до необхідності порахувати порядку 210 підсумкових агрегатів.

Уважається стандартним представлення куба у вигляді графа, у якому вузли

визначають представлення (view) для відповіді на запит (рис. 10). Для кожного вузла мітка
позначає виміри, по яких у представленні є фактичні дані, за значеннями ALL виконується
агрегація.

All, All,All

Регіон, All,All All, Продукти, All All,All, Час

Регіон, Продукти,All Регіон, All,Час All, Продукти, All

Регіон,
Продукти,Час

Рис.10. Представлення куба у вигляді графа

У даній структурі куба матеріалізується набір представлень, що містить агреговані дані.

Подібні представлення також називаються підкубами (cuboids).
Вибір підкубов для матеріалізації визначає майбутню продуктивність системи. Можна
одержати набір уявлень, при використанні якого для виконання запитів буде вироблятися
не більше 1-2 агрегацій (по одному вимірі), що означає дуже швидку відповідь на запит. І
навпаки, можлива ситуація, у якій для відповіді на запит необхідно буде створювати всі
агрегації від фактичних даних (базового куба). Однак кількість підкубів експоненціально
залежить від кількості вимірів (як 2d, де d – кількість вимірів), тому для повної
матеріалізації може вимагатися величезний об'єм пам'яті й місця на жорсткому диску.
Часткова матеріалізація пропонує вибір між часом створення кубів і розміром збережених
даних, з одного боку, і часом відгуку, з іншої. Замість обчислення повного куба можна
обчислити лише деякі з його підкубів або навіть частин підкубів.

Загальні стратегії обчислення кубів

Поза залежністю від методу зберігання (ROLAP, MOLAP), існує набір прийомів, що
дозволяють зменшити час створення й обробки запитів до OLAP-Кубів.
Сортування, хешування, угруповання
Під час обчислення куба агрегуються рядки (або комірки), що мають однакові значення по
всіх вимірах (так звані дублікати), тому важливо використовувати сортування й групувати
дані, щоб спростити обчислення подібних агрегатів. Приміром, якщо необхідно
порахувати загальні продажі по регіонах, продуктам, порі року, то більш ефективно
сортувати кортежі по регіонах, потім по сезонах і групувати по продуктах.
Одночасне агрегування й хешування проміжних результатів
Ефективніше створювати підкуби високих рівнів з підкубів низьких рівнів, ніж з базової
таблиці. Більш того, одночасне обчислення агрегатів може дозволити скоротити дорогі
операції звертання до жорстких дисків.
Приміром, для розрахунку продажів по регіонах можна використовувати проміжні
результати, отримані при розрахунку підкуба більш низького рівня продажів по регіонах,
по днях.
Агрегування від найменшого підкуба-нащадка при наявність багатьох підкубів-нащадків
При обчисленні підкуба високого порядку часто більш ефективно використовувати
найменший із уже розрахованих підкубів-нащадків. Приміром, для розрахунку куба
продажів по регіонах за умови наявності 2-х розрахованих підкубів (по регіонах і рокам, і
по регіонах і продуктам), мабуть, ефективніше використовувати куб по регіонах і рокам,
тому що він містить менше комірок.
При створенні кубів типу айсберг можна використовувати наступне правило: «Якщо
вказана комірка не задовольняє умові, що накладається на мінімальне значення міри, то
жоден з її нащадків не задовольняє умові». Така умова може бути використана для
скорочення об'єму оброблюваних даних. Однак дана умова вірна тільки для
дистрибутивних агрегуючих функцій.

Параметри складаються із двох компонентів:

чисельна характеристика факту, наприклад, ціна або дохід від продажів;
формула, звичайно проста агрегативна функція, наприклад, сума MIN, MAX, AVG,
COUNT, що може поєднувати кілька значень параметрів в одне. Але в деяких випадках
можуть використовуватися й більш складні функції – дисперсії, середньоквадратичне
відхилення й т.д.).
З погляду обчислень можна виділити три різних класи параметрів.
Адитивні параметри можуть змістовним образом комбінуватися в будь-якому вимірі.
Наприклад, має сенс підсумувати загальний обсяг продажів для продукту, місця
розташування й часу, оскільки це не викликає накладення серед явищ реального світу, які
генерують кожне із цих значень.
Напівадитивні параметри, які не можуть комбінуватися в одному або декількох вимірах.
Наприклад, підсумовування запасів по різних товарах і складам має сенс, але
підсумовування запасів товарів у різний час безглуздо, оскільки той самий фізичний
предмет може враховуватися кілька разів.
Неадитивні параметри не комбінуються в будь-якому вимірі, звичайно тому, що обрана
формула не дозволяє об'єднати середні значення низького рівня в середнім значенні більш
високого рівня.
Адитивні й неадитивні параметри можуть описувати факти будь-якого роду, у той час як
напівадитивні параметри, як правило, використовуються з миттєвими знімками.
Питання для самоперевірки
Як розраховується розмірність куба з агрегованими значеннями?
Які види агрегуючих функцій ви знаєте?
Перелічите види запитів до багатомірних кубів. Поясніть розходження між ними.
Що розуміється під «вибухом» даних?
Що втримується у вузлах графа, який представляє куб?
Поясніть зміст різних способів прискорення обробки даних багатомірного куба.
Які параметри називаються неадитивними?
У чому відмінність між неадитивними й напівадитивними параметрами?

Методичні вказівки до лекції: [3, с. 458–461].

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

ЛЕКЦІЯ №8
Агреговані значення для різних видів вимірів

Розглядаються наступні питання:

· поняття ступеня агрегації;
 · розрахунок кількості агрегованих значень для простих вимірів;
· розрахунок кількості агрегованих значень для ієрархічних вимірів;
· обчислювальні витрати на агрегування;
· процедура попереднього формування агрегатів;
· процедура оперативного формування агрегатів.

Звичайно під агрегацією розуміється будь-яка процедура формування меншої

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

Ступінь агрегації куба обчислюється як:

a
a= * , (1)
a
де a – реальна кількість агрегованих значень показників, a* – максимально можлива
кількість агрегатних значень вихідних даних куба.
При виводі формул для a і a* спочатку розберемо прості випадки із двома-трьома
вимірами, а потім перейдемо до узагальненого варіанта. Те ж саме стосується й рівнів
ієрархії у вимірах: спочатку розглянемо випадки простих вимірів (з одним рівнем), а потім
на прикладі вимірів з декількома рівнями виведемо узагальнену формулу.

Прості виміри
Нехай є 3 прості виміри для обліку обсягу продажів деяких товарів. Структура
багатомірного куба буде містити в собі наступні об'єкти (рис.11):
· Один показник: число проданих одиниць товару,
· Три виміри:
- менеджери по продажах (вісь oM),
- види товарів (вісь oC),
- часовий вимір з одиницею «місяць» (вісь oT).

Рис. 11. Тривимірний OALP-Куб із простими вимірами; стрілки показують напрямок

агрегації.

Нехай Р, М, T – множини членів відповідних вимірів «види товарів», «менеджери»,

«місяці». Нехай кількість членів у кожному з вимірів nР = |Р|, nm = |М|, nt = |T|. Члени цих
вимірів позначаються відповідно mр, mm, mt.
 Для одержання агрегованих значень у розрізі менеджерів і місяців необхідно
підсумувати первісні значення показників по всіх видах товару для кожної комбінації (mt,
mm) менеджерів і місяців. На рис.11 напрямок агрегування позначений стрілкою 1.
Кількість агрегованих у такий спосіб значень дорівнює nmnt. Можна представити, що
агреговані в такий спосіб значення показників розташовуються на площині (oM, oT).
Аналогічно міркуючи, одержимо число агрегатів для всіх комбінацій (mр, mt) при
підсумовуванні показників по всіх членах виміру “менеджери”. Воно дорівнює nрnt.
Кількість агрегатів для всіх комбінацій (mр, mm) при агрегації по часовому вимірі
дорівнює nm nр.
Тепер необхідно одержати число агрегатів у розрізі членів одного з вимірів.
Очевидно, що кількість таких агрегатів дорівнює числу членів відповідного виміру nm, nр і
nt (стрілки 4, 5 і 6 відповідно).
З огляду на значення повного агрегату, що визначає в нашім випадку сумарний обсяг
продажів по всіх видах товарів, менеджерам і всьому часовому періоду, сумарна кількість
всіх агрегатів дорівнює:
a* = nmnр + nрnt + nmnt + nр + nm + nt + 1
Нехай є m вимірів. Кожному виміру відповідає порядковий номер i,i = 1..m. Кожний
вимір містить ni членів.
Нехай Al1 ...li ...l m – деяка множина агрегатів, де li=0, якщо по i-му вимірі виконується
агрегування, інакше li=1.
Тоді A1...1…1,де індекси у всіх позиціях рівні 1, є множиною вхідних даних; A0...0…0,де
індекси у всіх позиціях рівні 0, містить єдине значення повного агрегату.
Упорядкована послідовність l1,…,li,…,lm,відповіднамножині агрегатів
Al1…li…lm,називається станом агрегації.
Рівнем деталізації називається число l = l1+…+li+…+lm... Очевидно, різні стани
агрегації, а, отже, і множини агрегатів можуть відповідати тому самому рівню деталізації.
Нехай al ...l ...l – це кількість агрегатів множини Al ...l ...l .
1 i m 1 i m

Для тривимірного випадку з урахуванням того, що i(Р)=1, i(M)=2, i(T)=3 – порядкові

номери вимірів, одержимо
a011= nmnt ; a101= nрnt; a110= nрnm; a001= nt; a010= nm; a100= nc
Тоді
a* = a011+ a101+ a110 + a001+ a010 + a100 + a000.
Кількість агрегатів, отриманих агрегуванням по деяких вимірах, дорівнює добутку
числа членів всіх інших вимірів, тобто

m
al1...li ...lm = Õ ni (2)
i =1,li ¹ 0
Кількість усіляких агрегатів дорівнює сумі al1 ...li ...lm при всіляких варіантах
m
послідовності l1,…,li,…,lm,крім множини вхідних даних. Таких варіантів усього 2 -1.
Формула розрахунку повного числа агрегатів з урахуванням (2) виглядає в такий
спосіб

m m- k
a* = å å Õ ni (3)
k =1 C mk i =1,li ¹ 0
де Cm – кількість варіантів розміщення k нулів по m позиціях, тобто сполучення k
k

m -k
елементів по m, å Õ ni – сума всіляких неповторюваних добутків кількості членів
Cmk i =1,li ¹ 0
вимірів.
Більш просту формулу можна одержати, використовуючи властивість, що випливає з
(2):

Al1...li ...lm = ni Al1...0...lm

Тоді

å al ...l ...l
1 i m
= (n1 + 1) å a0...li ...lm = ( n1 + 1)...(ni + 1) å a 0...0li +1...lm = (n1 + 1)...(nm + 1)
2 m
2 m -1 2 m -i
Крім числа вхідних даних, одержимо

m m
a* = Õ (ni + 1) - Õ ni (4)
i =1 i =1

Ієрархічні виміри
Нехай для i-го виміру існує li* рівнів ієрархії.
ni,j – кількість членів в j-ом рівні i-го виміру, так що ni , j1 < ni , j2 при j1<j2 ; ni –
загальна кількість членів i-го виміру:

li *
n i = å ni , j .
j =1
Зіставимо кожному виміру порядковий номер i.
Al1...li ...lm – множина агрегатів, отриманих агрегуванням вхідних даних до li-го рівня
кожного з m вимірів, li = 0...li*.
Послідовність чисел l1,…,li,…,lmназивається станом агрегації.
Рівень ієрархії з нульовим номером li = 0 можна асоціювати з абстрактним
кореневим рівнем, що містить завжди єдиний член (ni0 =1), який, як правило, не має
відповідності реальному об'єкту предметної області. У такому випадку агрегацію по всіх
членах i-го виміру можна інтерпретувати, як агрегацію до кореневого рівня i-го виміру.
Як і у випадку із простими вимірами, рівнем деталізації називається число l =
l1+…+li+…+lm,відповіднемножині агрегатів Al1...li ...lm .
Розглянемо двомірний випадок з наступною структурою (рис.12):
· Показники: число проданих одиниць товару,
· Виміри:
- вимір, що відповідає часу продажу (вісь oT): квартал - місяць - день,
- вимір, що відповідає місцю й продавцеві (вісь oU): салони продажів -
менеджери.
 Рис. 12. Двомірний випадок з ієрархічними вимірами

Нехай кількість членів часового виміру (T) перевищує кількість членів виміру місця
(U). Тоді
- l1* = 3, l2* = 2;
- загальне число членів виміру T і U дорівнює відповідно n1 і n2;
- кількість кварталів, місяців і днів у часовому вимірі дорівнює відповідно n1,1, n1,2
і n1,3 ;
- кількість салонів і менеджерів дорівнює відповідно n1,1 і n2,2;
- кількість вхідних даних дорівнює n1,3 і n2,2.
Відповідна кількість агрегатів дорівнює:
- у розрізі місяців і менеджерів a22= n1,2n2,2,
- у розрізі днів і салонів продажів a31= n1,3n2,1,
- у розрізі тільки днів a30= n1,3,
- у розрізі місяців і салонів продажів a21=n1,2n2,1,
- у розрізі кварталів і менеджерів a12= n1,1n2,2,
- у розрізі тільки місяців a20= n1,2,
- у розрізі кварталів і салонів продажів a11= n1,1n2,1,
- у розрізі тільки менеджерів a02= n2,2,
- у розрізі тільки салонів продажів a01= n2,1.
- у розрізі тільки кварталів a10= n1,1,
- повний агрегат a00= 1.
У такий спосіб
a* =a31+a30+a22+a21+a20+a12+a12+a10+a02+a01+a00=
=n1,2n2,2 + n1,3n2,1+ n1,3+ n1,2n2,1+ n1,1n2,2+ n1,2+ n1,1n2,1+ n2,2, + n2,1 + n1,1 + 1.
(перший індекс - вимір, другий індекс - рівень)
З визначення Al1...li ...lm слідує, що

al1...li ...lm = Õ ni ,li (5а),

li ¹ 0
що є загальним випадком щодо формули (2). З огляду на те, що ni,0 = 1, одержимо більш
просту формулу
m
al1...li ...lm = Õ ni ,li (5б)
i =1
 З (5б) виходить співвідношення між потужностями з різними рівнями деталізації
ni ,li a l1...li ...lm = ni ,li a l1...li - k ...lm , (6)
-k
де li = k…li*...
Загальна кількість всіх агрегатів виходить підсумовуванням числа агрегатів
множин Al1...li ...lm , обумовлених усілякими станами агрегації. Число комбінацій
l1,…,li,…,lmбез урахування комбінації, що відповідає вхідним даним, дорівнює добутку
(l1*+1)…(li*+1)…(lm*+1)–1... Тоді з урахуванням (5б) кількість усіляких агрегатів
дорівнює:
m
a* = å Õ ni,l i
m i =1
Õ (l j *+1)-1
j =1
де кожний доданок представляє унікальний добуток числа членів вимірів.
Більш зручна з погляду обчислення формула кількості всіляких агрегатів може бути
отримана із властивості
a l1...li -1lili -1...lm = ni ,li al1...li -1 0li + 1...lm
,
яка слідує з (6).
Сума всіляких al1...li ...lm дорівнює:

m
å al ...l ...l
1 i m
= (n1,l1* + ... + n1,1 + 1)
m
å a 0,l ...l ...l
2 i m
=
Õ (l j *+1)-1 Õ (l j *+1)-1
j =1 j=2

= (n1,l1* + ... + n1,1 + 1)...( n1,li * + ... + ni ,1 + 1)

m
å a 0,0...0,l i +1 ...lm
=
Õ (l j *+1) -1
j = l +1

= (n1,l1* + ... + n1,1 + 1)...( n m,lm * + ... + n m,1 + 1)

li *
Крім множини вхідних даних, і з огляду на те, що ni = å ni ,li , одержимо
li =1
m m
a* = Õ (ni + 1) - Õ n i,li * (7)
i =1 i =1
Формула (7) представляє узагальнений вид формули (4).
Обчислювальні витрати на ад'єктивування
Під обчислювальними витратами на виконання агрегації деякої множини значень
показників (агрегованих або вхідних) до певного результуючої множини агрегатів
розуміється кількість елементарних операцій підсумовування, які необхідно здійснити для
одержання результуючої множини.
Позначимо витрати на виконання агрегування множини Al1 ...li ...l m по i-му вимірі, як
C (i, Al1 ...li ...lm ) .
Очевидно, що C (i, Al1 ...l i -1 0l i +1 ...l m ) = 0
Для формування множини агрегатів A011 у випадку із трьома простими вимірами для
кожної комбінації менеджерів і місяців необхідно підсумувати вхідні значення показників
по напрямку стрілки 1 (рис. 11) nр-1 раз. Таким чином, з урахуванням того, що i(Р) =1,
i(M)=2, i(T) =3 – порядкові номери вимірів, витрати на виконання агрегування від A011до
A011 визначаються як
C(1, A111) = (nр - 1)nmnt.
Аналогічно при формуванні множин агрегатів A101 і A110 на підставі вихідних
значень показників одержимо відповідно витрати
C(2, A111) = nc nt (nm - 1),
C(2, A111) = nc nm (nt –1).
Одержання множини A001 можливо двома способами:
· агрегування множини A101 по вимірі видів товару (по стрілці 4);
· агрегування множини A011 по вимірі менеджерів (по стрілці 5);
Очевидно, що витрати на ці операції різні й рівні відповідно
C(1, A101) = (nр-1)nt,
C(2, A011) = (nm-1)nt.
Розглянемо розрахунок витрати на агрегування в загальному випадку з ієрархічними
вимірами. Для цього використовуємо наступне твердження.
Твердження 1. Нехай існує ієрархія з l* рівнями, де nl – кількість членів на l-ом рівні
й nl<=nl+1, l=1…l*-1...Тоді кількість елементарних операцій підсумовування значень
показника, що відповідають l+ 1-му рівню, з метою одержання агрегованх значень
показника l-го рівня дорівнює
nl+1-nl.
У прикладі із двома ієрархічними (рис. 12) вимірами для одержання агрегованих
значень показника по кожній комбінації менеджерів і місяців (А22) необхідно провести
агрегацію множини вхідних A32 даних по часовому вимірі: від A32 доА22 по 1-му вимірі.
Для цієї операції необхідно для кожного менеджера підсумувати значення показника по
днях з метою одержання показника по місяцях (відповідно до твердження) n1,3 - n1,2 разів.
Таким чином,
C(1, A32) = (n1,3 – n1,2)n2,2 = n1,3n2,2 - n1,2n2,2 = a32 - a22.
Аналогічно витрати на агрегацію значень показника в розрізі менеджерів і кварталів
по часовому вимірі з метою одержання агрегатів тільки по менеджерах рівні
C(1, A12) = (n1,1 – n1,0)n2,2 = (n1,1 – 1) n2,2 = n1,1n2,2 - n2,2 = a12 - a02,
Узагальнюючи вище описані приклади, можна сформулювати висновок, що при
підсумовуванні множин агрегатів по i-му вимірі з li-го на li-1 рівень необхідно для кожної
комбінації зі членів поточних рівнів всіх інших m-1 вимірів провести ni,li – ni,li-1
елементарних операцій підсумовування. Таким чином, одержуємо

m
C (i , Al1 ...li -1 0li +1 ...l m ) = (ni ,li - ni,li -1 ) Õ n j ,l j , де li = 1…li*...
j =1, j ¹ i

Використовуючи (5а) і (6), перетворимо цю формулу в наступний вид:

m m
C (i, Al1...li -1 0li +1...lm ) = Õ n i ,li - n i,li -1 Õ n j ,l = al1...li ...lm - a l1...li =
j -1 ...l m
i =1 j =1, j ¹ i
ni ,li (8)
ni ,li -1
= a l1...li - a l1...li = a l1...li ...lm - a l1...li
ni ,li -1 ...l m -1 ...lm n i , li -1 ...l m
-1

Процедури формування агрегатів

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

У будь-яку множину агрегатів Al ...l ...l можна безпосередньо перейти з іншої

1 i m

множини Al ...l ...lm , зробивши ад'єктивування по i-му вимірі. При цьому необхідно
1 i +1

зробити відповідні обчислювальні витрати, що відкладаються на ребрах графа.

Вірно наступне твердження.
Твердження 2. У будь-яку вершину графа Al1 ...l i ...l m можна потрапити з іншої
вершини Al1 '...li '...l m ' , якщо хоча б одна з нерівностей li’=>li , i = 1…m виконується
строго.

Процедура попереднього формування агрегатів

Нехай необхідно виконати попереднє формування агрегатних значень вхідних даних
куба відомої структури так, щоб ступінь агрегації розглянутого куба досягла значення α.
Для цього згідно (1) необхідно сформувати a= α a* агрегатів. Нижче описані основні
моменти, що характеризують процедуру попереднього формування агрегатів.
Принцип “від детального до загального”. Очевидно, що процедуру формування
агрегованих значень показників необхідно починати з формування агрегатів, що
відповідають більшому ступеня деталізації. Будемо вважати, що формування агрегатів l-го
рівня деталізації неможливо без одержання всіляких агрегатів l+ 1-го рівня деталізації.
Принцип мінімальних витрат. Як було сказано раніше, розрахунок множини
агрегатів Al ...l ...l може бути виконаний декількома способами, причому витрати на кожну
1 i m

із цих операцій агрегації різні. Логічно із всіх можливих альтернатив агрегації вибирати
ту, котра вимагає найменших обчислювальних витрат.
Розподіл агрегатів між множинами одного рівня деталізації. Розглянемо сукупність
множин агрегації Al, що відповідають рівню деталізації l ( l=1...1…1*). Допустимо, що на
цей момент всі множини більшого ступеня деталізації, чим l, сформовані й загальна їхня
кількість дорівнює a’. Позначимо множину всіх агрегатів рівня l як al. Залежно від заданої
для поточного куба ступеня агрегації можливі наступні варіанти подальшого поводження.
· Оцінювана сумарна кількість агрегатів, що відповідають рівню деталізації більш
або рівного l, не перевищує дозволеної кількості агрегатів а, обумовленого заданим
ступенем деталізації, тобто a’+ al<= a. У цьому випадку повністю формуються всі
множини агрегатів Al ...l ...l , що відповідають рівню деталізації l.
1 i m

· Оцінювана сумарна кількість агрегатів, що відповідають рівню деталізації більш

або рівному l, перевищує дозволену кількість агрегатів а, обумовлене заданим ступенем
деталізації, тобто a’+ al>a. Оскільки немає підстав для визначення пріоритетів і переваг
серед множин агрегатів l-го рівня, логічно рівноцінно розподілити залишкову кількість
агрегатів по цих множинах. Рівноцінність припускає розподіл залишкової кількості
агрегатів серед множин l-го рівня деталізації в прямої пропорції максимально можливій
кількості їхніх елементів al1 ...li ...lm , так що реальна кількість агрегатів множини
Al1 ...li ...l m обчислюється як
é a - a' ù
a ' l1...li ...lm = ê l a l1...li ...lm ú
ë a û
Правило, по якому визначається, які з агрегатів у кожній множині
Al1 ...li ...l m формуються, а які ні, не регламентується, так що формовані агрегати
вибираються випадковим образом.
Описана процедура, можливо, і забезпечує мінімальні обчислювальні витрати на її
виконання, але вона не є оптимальною стосовно множин формованих агрегатів. Для
пояснення цього факту розглянемо процедуру оперативного формування агрегатів.

Процедура оперативного формування агрегатів

Будемо розуміти під процедурою оперативного формування агрегатів процедуру
одержання результуючого набору агрегатів при виконанні користувальницького запиту.
При розрахунку результуючого набору агрегатів будуть використовуватися підходящі
попередньо сформовані агреговані значення показників. Якщо результуючий набір
агрегатів попередньо сформований, то витрати на оперативне формування агрегатів рівні
0.
Ясно, що для одержання множини агрегатів певного рівня, необхідно спочатку
одержати множини агрегатів більшого рівня деталізації. Однак на відміну від процедури
попереднього формування агрегатів при одержанні результуючого набору немає
необхідності формувати всілякі агрегати певного рівня деталізації. Досить формувати по
одній множини певного рівня на основі множини більш детального рівня.
Нехай у результаті процедури попередньо формування агрегатів одержали всілякі
множини мінімального рівня деталізації l. Нехай у результаті необхідно сформувати
множину агрегатів Al ' ...l ' рівня деталізації l’, l’< l. Необхідно на підставі однієї з множин
1 m

Al1...li ...lm l-го рівня одержати результуючу множину. При цьому:

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

Рис.14. Попереднє й оперативне формування агрегатів у мережній моделі

Така процедура оперативного формування забезпечить мінімальний час виконання

користувальницьких запитів. Однак багато чого залежить від множини попередньо
сформованих агрегатів. Вони повинні бути сформовані так, щоб обчислювальні витрати
на оперативне формування всіляких множин були мінімальні.
 Питання для самоперевірки
1. Поясніть, як розраховується кількість усіляких агрегатів для куба із простими
вимірами.
2. Поясніть, як розраховується кількість усіляких агрегатів для куба з
ієрархічними вимірами.
3. Як визначаються обчислювальні витрати на агрегування?
4. Які принципи використовуються під час виконання процедури попереднього
формування агрегатів?
5. Назвіть особливості процедури оперативного формування агрегатів.

Методичні вказівки до лекції: [9].

Вправи
1. Визначите міру й три виміри для куба із предметної області «Лікарня».
Розрахуйте кількість усіляких агрегатів для випадку із простими вимірами.
2. Додайте ієрархію у виміри із вправи 1. Розрахуйте кількість усіляких агрегатів.
3. Розрахуйте обчислювальні витрати для агрегації по одному з вимірів для куба із
вправи 2.
4. Намалюйте граф, що визначає шляхи формування агрегатів для куба із вправи 3.
 Семестровий модуль 2
Змістовний модуль 4
Підготовка даних для СД
ЛЕКЦІЯ №9
Витяг, перетворення й завантаження даних

Розглядаються наступні питання:

· стадії процесу завантаження;
· процес витягу даних і його підпроцеси;
· методи прискорення процесу перевантаження даних.

Витяг, перетворення й завантаження, відомі під абревіатурою ETL (extraction,

transformation, loading), – це основні етапи переносу інформації з одного застосування в
інше.
У загальному випадку ETL витягають інформацію з вхідної бази даних, перетворять
її у формат, підтримуваний базою даних призначення, а потім завантажують у неї
перетворену інформацію. Щоб витягти дані з вхідної бази даних, можна вибрати один із
трьох варіантів – створити власні програми, звернутися до готового спеціалізованого
інструментарію ETL або використовувати сполучення й того й іншого.
Програміст ETL може уявляти собі архітектуру СД у вигляді сукупності трьох
областей: джерело даних (сукупність таблиць оперативної системи й додаткових
довідників (класифікаторів, таблиць узгодження), що дозволяє створити багатомірну
модель даних з необхідними вимірами), проміжна область (сукупність таблиць, що
використовуються винятково як проміжні при завантаженні СД) і приймач даних.
Якщо зустрічаються джерела інформації, що надходить у різний час або з різних
оперативних систем, але ідентичної за структурою, наприклад, однотипні відомості з
різних філій, то такі джерела варто вважати не різними, а одним розподіленим. Витяг
даних із всіх частин розподіленого джерела виконується в одну таблицю проміжної
області. Для збереження інформації, звідки надійшли дані, у структуру цієї таблиці
додається поле з позначенням вхідної оперативної системи або філії.

У свою чергу, процес витягу включає наступні підпроцеси:

- вивантаження;
- структурування;
- обробка;
- пересилання;
- імпорт.
Залежно від характеру джерела даних можуть використовуватися такі методи
організації вивантаження даних:
- із СКБД – звичайно не викликає утруднень, можна використовувати власні
утиліти СКБД;
- зі структурованого джерела – для вивантаження використовуються відповідні
драйвера, наприклад, ODBC; може знадобитися попередня підготовка структурованого
файлу людиною або сторонньою програмою;
- з неструктурованого джерела - потрібні додаткові утиліти для експорту даних, у
ході якого дані організуються у тверду структуру.
Повинна бути також врахована глибина вибірки даних за часом. Як правило, це 2
режими роботи процедури вивантаження: вивантаження всієї інформації, без урахування
часу її надходження, і вивантаження за деякий останній період (наприклад, за останній
закритий день). Універсальним засобом рішення є можливість завдання, як параметр
процедури, дати, починаючи з якої будуть вибиратися дані.
 Структуровані дані можуть зажадати додаткової обробки (очищення, фільтрації,
узгодження, і т.д.) для підвищення якості інформації.
В обробці даних можуть бути задіяні різні інструменти: від ручного виправлення
текстового файлу аналітиком до утиліт, що застосовують просунуті методи аналізу даних
(нейронні мережі, тезаурус, кластерізація й ін.).
У ході проектування процедур витягу даних необхідно врахувати умови
забезпечення безпеки при пересиланні й обробці даних. Дані джерела не завжди можуть
бути оброблені на сервері постачальника даних. Тоді їх необхідно переслати для обробки
на сервер консолідації даних, що також вимагає наявності захищених каналів зв'язку й
адміністративних ресурсів. У цьому випадку, етап пересилання виконується раніше
структурування даних.
Для подальшої обробки, структуровані дані необхідно імпортувати у відповідну
таблицю СКБД (яку потрібно попередньо очистити). При цьому існує ймовірність, що
окремі записи не зможуть, у силу фізичних обмежень або несумісності типів даних, бути
вставлені. По можливості, такі «невідповідні» записи потрібно зберігати в окремий файл
тієї ж структури, що й імпортований, з метою подальшого аналізу й підвищення якості
даних.
Помилки можуть з'являтися в кожному з підпроцесів стадії витягу даних.
Відстежити їхнє виникнення – завдання, що слабко формалізується. Крім того, найчастіше
вся відповідальність за забезпечення коректної роботи процедур витягу даних
покладається на програмістів, що може бути виправдано тільки для жорстко
структурованих джерел даних (наприклад, коли завантаження виконується прямо із
СКБД).
У кожному разі, обов'язковою є обробка фатальних для подальших стадій помилок.
Приклади фатальних помилок:
- відсутність файлів джерела даних;
- помилка доступу до даних;
- виникнення системної помилки операційної системи.

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

задовольняють існуючим фізичним обмеженням або бізнес-правилам.
Категорії критеріїв оцінки якості даних можна звести до наступних класів:
1) по критичності:
- критичні помилки в даних (дані, які не відповідають цьому критерію, не можуть
бути завантажені в CД), наприклад, числове вираження, що містить букву;
- некритичні помилки в даних (дані, які можуть бути завантажені в CД, але не є
якісними), наприклад, порожнє (NULL) значення в полі ім'я;
- якісні дані.
2) по об’єктам, що перевіряються:
- коректність форматів і представлень даних;
- унікальність первинних і альтернативних ключів;
- повнота даних;
- повнота зв'язків;
- відповідність даних аналітичним обмеженням.
Фізична модель СД часто не збігається зі структурою оперативних джерел даних.
Тому виникає потреба в перетворенні даних, які надходять із оперативних джерел у
структури, що відповідають таблицям СД.
Перетворення даних зводиться до декількох елементарних операцій:
- обчислення;
- агрегація;
- узгодження ключів;
 - генерація сурогатних ключів.
Обчислення – це операція, що може бути реалізована на рівні скалярних функцій.
Узгодження ключів – операція приведення ідентифікаторів набору даних джерела до
виду, що відповідає ідентифікаторам СД.
Генерація сурогатних ключів – операція зіставлення природному ключу (найчастіше
- складеному) унікального сурогатного ключа – ідентифікатора набору даних СД.
Найчастіше застосовуються наступні способи: послідовна нумерація або кодування
природного ключа (сурогатний ключ обчислюється із природного за допомогою деякої
функції).

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

Процес перевантаження даних джерел у сховище даних, з технічної точки зору, є

послідовністю SQL-запитів до СКБД над досить великими об’ємами даних (від 1 до 100
мегабайт за один сеанс). Тому, виконання неоптимізованих процесів перевантаження
може на порядки збільшити час виконання за рахунок зайвих або повторних обробок або
пересилань даних.
Зокрема, можна врахувати наступні методи прискорення процесу:
- наявність у таблиці індексів або представлень може сильно збільшити час
вставки даних у цю таблицю – перед заповненням необхідно, по можливості, видалити всі
індекси й представлення й створити їх заново після заповнення;
- швидкість передачі даних по мережі набагато менше швидкості передачі даних
усередині одного сервера СКБД – на етапі вивантаження даних із джерела варто
застосувати всі можливі фільтри й процедури агрегації, щоб прискорити проходження
даних по мережі;
- застосування оператора DISTINCT сильно сповільнює виконання запиту в деяких
СКБД – замість оператора DISTINCT використовувати GROUP BY, наприклад, замість
оператора SELECT DISTINCT Ід_Товару FROM Продаж використовувати оператор
SELECT Ід_Товару FROM Продаж GROUP BY Ід_Товару;
- у деяких СКБД відсутній окрема операція очищення таблиці, яка не
журналізується, а застосування оператора DELETE FROM може виконуватися повільно –
можна застосувати парні операції видалення й наступного створення таблиці, при цьому
прийдеться заново створити залежні об'єкти, наприклад, індекси.
У процесах перевантаження даних є й інші вузькі місця, які можна оптимізувати. Це
фаза очищення даних, етап генерації сурогатних ключів і фаза вставки даних у СД.
Наприклад, один зі способів оптимізації очищення даних полягає в наступному. При
очищенні даних виконується перевірка кожного запису на відповідність ряду заздалегідь
обраних критеріїв і правил. Оскільки перевірка одних критеріїв може залежати від
результатів перевірки інших (наприклад, перевірка обмеження на значення числа, що
втримується в поле з типом даних char(10), залежить від перевірки, чи є вміст цього
текстового поля числом), те рекомендується за результатами перевірки критеріїв з більш
високим пріоритетом (у наведеному прикладі перевірка, чи є значення поля числом, має
більш високий пріоритет) формувати проміжні (тимчасові) таблиці, які будуть потім
перевірятися на відповідність іншим критеріям. У результаті запит на перевірку кожного
наступного критерію буде обробляти все менший об’єм даних. Цей спосіб має й недоліки:
відсутність виграшу при надходженні якісних даних, і навіть програш по швидкості за
рахунок потреби в очищенні проміжних таблиць; збільшення числа об'єктів проміжної
області; збільшення числа кроків.
 Для часткового усунення цього недоліку формування додаткових проміжних
таблиць варто вводити тільки для перевірки критеріїв, що забирає значний час.

Одна із самих повільних операцій у СКБД - це операція відновлення UPDATE. Один

з методів обійти використання UPDATE – заміна її на операції видалення й вставки.
Можливі два варіанти заміни:
1) стандартний
a) видалення із СД рядків, які підлягають відновленню;
b) вставка всіх рядків з новими значеннями в СД;
2) оптимізований
a) перенос рядків, які не підлягають відновленню, із СД у тимчасову таблицю з
рядками, які підлягають відновленню;
b) очищення всієї таблиці СД;
c) вставка в СД всієї тимчасової таблиці.
Подібна заміна буде ефективна при великій кількості обновлюваних полів таблиці
СД (більше 10). Однак, ця заміна неможлива для випадків, коли обмеження посилальної
цілісності створені фізично в базі даних. Для таких випадків UPDATE – єдиний спосіб
відновлення даних.
ETL-процес є вузьким місцем концепції сховищ даних для рішення багатьох задач.
При побудові СД найбільші витрати, як правило, доводяться саме на етап ETL.
Правильний підхід у реалізації процесів ETL дозволять істотно оптимізувати витрати при
побудові сучасного аналітичного інформаційного комплексу й підвищити його
ефективність.

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

1. Що таке ETL?
2. Назвіть основні етапи витягу даних.
3. Які фатальні помилки можуть виникати на стадії витягу даних?
4. Назвіть критерії оцінки якості даних.
5. Які способи прискорення перевантаження даних у СД Ви знаєте?

Методичні вказівки до лекції: [3, с. 345–348];[4, с. 886–888]; [5,с. 960–962]; [6, с.

83–91].

Вправи
1. Розробіть реляційну БД для обліку оперативної інформації в предметній області
«Поліклініка». Розробіть для даної предметної області структуру реляційних таблиць для
СД типу «зірка» із трьома вимірами. Напишіть оператори SQL для перенесення даних з
оперативної БД у СД.
2. Виконайте вправу 1 для предметної області «Телефонна компанія».
 ЛЕКЦІЯ №10
Очищення даних

Розглядаються наступні питання:

· проблеми окремого джерела даних на рівні схеми;
· проблеми окремого джерела даних на рівні елемента даних;
· проблеми очищення даних з множини джерел.

Оскільки сховища даних завантажують і постійно обновляють величезні об’єми

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

Проблеми окремих джерел даних

Проблеми окремого джерела даних на рівні схеми

Область/ Проблема Забруднені дані Причини/ Примітки
Неприпустимі Значення поза
Атрибут ДатаНародження=30.13.70
значення припустимою областю
Порушені логічних Вік=22, ДатаНародження Вік не відповідає року
Запис
зв'язків =12.02.70 народження
Співробітник1=(Прізвище=
Порушено унікальність
Тип Порушення 'Петренко', ІдНомер=123456)
ідентифікаційного
запису унікальності Співробітник2=(Прізвище=
номера
'Іванов', ІдНомер=123456)
Порушення
Співробітник=(Прізвище= Не визначений відділ
Джерело цілісності
’Петренко’, КодВідділу=127) 127
посилань

Проблеми окремих джерел даних на рівні елемента

Область/ Проблема Забруднені дані Причини/ Примітки
Втрачені значення Неуведені значення
ІдКод= 9999999999 (безглузді або
невизначені)
Орфографічні Звичайно помилки,
Місто=’Хмельницьк’
помилки фонетичні помилки
Зашифровані
значення й
Атрибут
абревіатури
Категорія='B'
Посада= 'Сісадмин'
 Область/ Проблема Забруднені дані
Вкладені значення
Ім'я=’Петренко І. 12.02.80
Одеса’
Значення, що не
відповідають Місто=’Україна'
своїм полям
Запис Порушені логічні
Місто=’Одеса’, Індекс=44065
зв'язки
Тип Перестановка слів ПІБ1='І.Петренко',
запису ПІБ2='Іванов П.'
Записи, що Співробітник1=( ПІБ
дублюються ='Петренко Іван')
Співробітник2=( ПІБ
='Петренко І.')
Суперечливі Співробітник1=( ПІБ
записи ='Петренко Іван',
ДатаНародження =12.12.1980)
Співробітник2=( ПІБ
='Петренко І.', ДатаНародження
=12.02.1980)
Джерело Невірні посилання Співробітник1=(
ДатаНародження =’Петренко
Іван’, КодВідділу =17)
Причини/ Примітки
Множина значень в
одному атрибуті
(наприклад, у полі
вільного формату)
Індекс повинен
відповідати місту
Звичайно зустрічається
в полях вільного
формату
У результаті помилок
при уведенні даних
якась особа присутня
двічі
Той самий об'єкт
реального оточення
описується різними
значеннями
Відділ 17 визначений,
але не відповідає
об'єкту

Проблеми множини джерел даних

Проблеми, представлені в окремих джерелах, збільшуються у випадку інтеграції
множини джерел даних. Кожне джерело може містити забруднені, а також дані,
представлені різним образом, що перекривають і суперечать один одному. Причиною
цьому служить звичайно незалежна розробка, впровадження й підтримка джерел,
орієнтована на специфічні потреби підприємств. У результаті проявляється значна
неоднорідність у системах керування даними, моделях даних, схемах і поточних даних.
Основні проблеми при проектуванні схеми – це конфлікти найменувань і структурні
конфлікти. Конфлікти найменування виникають, коли те саме ім'я використовується для
різних об'єктів (омоніми) або різні імена використовуються для того самого об'єкта
(синоніми). Структурні конфлікти пов'язані з різними представленнями того самого
об'єкта в різних джерелах, наприклад, атрибутивне представлення проти табличного, різна
структура компонентів, різні типи даних, різні обмеження цілісності й т.д.
Навіть коли зустрічаються ті самі імена атрибутів і типи даних, представлення
(наприклад, для сімейного статусу) або інтерпретації значень (наприклад, одиниці виміру
грошової суми) від джерела до джерела можуть різнитися. Крім того, інформація в
джерелах може бути представлена в різних рівнях агрегації (наприклад, продажі по
продуктах проти продажів по групах продуктів) або відноситися до різних періодів
(наприклад, поточні продажі на вчорашній день для джерела 1 проти поточних продажів
на минулий тиждень для джерела 2).
Основною проблемою очищення даних з множини джерел є виявлення даних, що
перекриваються, особливо – відповідні один одному дані, що відносяться до того самого
об'єкта реального оточення (наприклад, споживач). Цю проблему називають також
проблемою ідентичності об'єкта, проблемою виключення дублювання або проблемою
злиття/видалення. Часто інформація тільки місцями надлишкова, і джерела можуть
доповнювати один одного, забезпечуючи більш повну інформацію про об'єкт. інформація,
що дублюється, повинна видалятися, а інформація, що доповнює, повинна
консолідуватися й з'єднуватися, щоб об'єкти реального оточення одержали погоджене
представлення.

Приклади проблем множини джерел на рівні схеми й елемента даних

Замовник (джерело 1)
Id замовника Ім'я Вулиця Місто Стать
Вул. Шевченко Білгород-Дністровський,
11 Євгенія Петренко 0
2 Одеська обл.
Пр. Шевченко
24 Євгеній Петренко Б.-Дністровський, Од. обл. 1
2

Клієнт (джерело 2)
N Прізвище Ім'я Рід Адреса Телефон/Факс
клієнта
Миколаївська обл., Первомайськ, 333-222-6542/
24 Петренко Євгеній Ж
вул. Шевченко 2 333-222-6599
Од. обл., Білгород-Дністровський,
493 Петренко Евг. М. М 444-555-6666
ін. Шевченко 2

Хоча обидва джерела представлені в реляційному форматі, однак вони відображають

конфлікти схеми й даних. На рівні схеми існують конфлікти імен (синоніми
Замовник/Клієнт, Ідентифікатор/Номер, Стать/Рід) і структурні конфлікти (різні
представлення імен і адрес). На рівні елемента даних можна спостерігати різні
представлення роду (0/1 проти Ж/M) і ймовірно записи, що дублюються (Петренко
Євгенія). Останнє також дозволяє побачити, що, незважаючи на те, що
Ідентифікатор/Номер обоє є ідентифікаторами, характерними для конкретних джерел,
їхній уміст не порівнянний між собою; різні номери (11/493) можуть відноситися до тієї
самої особи, а різні особи можуть мати той самий номер (24). Рішення даних проблем
вимагає одночасно й інтеграції схеми й очищення даних; третя таблиця демонструє
можливе рішення.
Клієнти (об'єднання цільових даних з очищеними)
Id Прізвищ Ім'я Рід Вулиця Місто
е
1 Петренко Євгенія Ж вул. Шевченко 2 Білгород-Дністровський
2 Петренко Євгеній М вул. Шевченко 2 Білгород-Дністровський
3 Петренко Євгеній М вул. Шевченко 2 Первомайськ

(продовження)
Область Індекс Телефон Факс Id замовника N клієнта
Одеська 67700 333-222-6542 333-222-6599 11 493
Одеська 67700 444-555-6666 24
Миколаївська 55200 444-555-6666 24
Слід зазначити, що конфлікти схеми необхідно врегулювати в першу чергу, щоб
забезпечити можливість очищення даних, особливо – виявлення дублікатів на основі
уніфікованого Представлення імен і адрес і зіставлення значень Рід/Стать.

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

1. Які проблеми окремих джерел даних Ви знаєте?
 2. Перелічите проблеми очищення даних для множини джерел.
3. У чому можуть бути причини виникнення «брудних даних»?

Методичні вказівки до лекції: [2, с. 31–37]; [6,с. 91–102, 189-251].

Вправи
1. Приведіть приклади виникнення проблем одного джерела даних на рівні схеми
для предметної області «Поліклініка».
2. Приведіть приклади виникнення проблем одного джерела даних на рівні
елемента даних для предметної області «Банк».
3. Приведіть приклади виникнення проблем множини джерел даних для
предметної області «Відділ кадрів студентів» для ВНЗ, що має множину факультетів.
 ЛЕКЦІЯ №11
Очищення даних (продовження)

Розглядаються наступні питання:

· методи очищення даних;
· вирішення конфліктів;
· приклади виникнення «брудних даних».

Методи очищення даних

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

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

Data mining допомагає знайти специфічні моделі даних у великих наборах даних –
наприклад, відношення між декількома атрибутами. Саме на це спрямовані так звані
описові моделі data mining, включаючи угруповання, узагальнення, пошук асоціацій і
послідовностей. При цьому можуть бути отримані обмеження цілісності в атрибутах –
наприклад, функціональні залежності або характерні для конкретних застосувань бізнес-
правила, – які можна використовувати для заповнення втрачених і виправлення
неприпустимих значень, а також для виявлення дублікатів записів у джерелах даних.
 Приклади використання модернізованих метаданих для роботи із проблемами
якості даних
Проблеми Метадані Приклади/пояснення
Наприклад, кількість елементів (Стать)>2 указує
Кількість елементів
на проблему
Неприпустимі Max і min не повинні виходити за межі області
Max, min
значення припустимих значень
Невідповідності, Невідповідності й відхилення статистичних
відхилення величин не повинні перевищувати граничних
Невизначені значення Відсоток/число невизначених значень
Втрачені Значення атрибутів +
Наявність значення за замовчуванням може
значення значення за
вказувати на відсутність справжнього значення
замовчуванням
Різні
Порівняння множини значень атрибутів стовпця
представлення
Значення атрибутів однієї таблиці з тією же множиною для стовпця
значень
іншої таблиці
Проблеми Метадані Приклади/пояснення
Дублікати Кількість елементів + Кількість значень атрибута повинне дорівнювати
унікальність кількості рядків
Сортування значень по числу входжень; більш 1
Значення атрибутів
входження означає дублікат.

Визначення перетворень даних

Описати необхідні перетворення можна відповідною мовою, наприклад,
підтримуваною графічним інтерфейсом користувача. Різні засоби ETL містять таку
можливість, підтримуючи власні мови правил. Більш загальний і гнучкий підхід полягає в
застосуванні стандартної мови запитів SQL для виконання перетворень даних і
використання можливостей розширень мов застосувань, особливо функцій, визначених
користувачем (UDF). UDF можуть бути реалізовані в SQL або мовою програмування
загального призначення, що містить вкладені оператори SQL. Вони дозволяють
реалізовувати широкий спектр перетворень даних і підтримують просте використання
різних перетворень і обробки запитів. Більш того, їхнє виконання СКБД може знизити
вартість доступу до даних.
Приклад опису кроку перетворення
CREATE VIEW Client2
(FamCl, NameCl, OtchCl, Gender, Street, City, Region, IndexCl, Id)
AS
SELECT FamExtract(FIO), NameExtract (FIO), OtchExtract (FIO), Sex,
StreetExtract(Address), CityExtract (Address),
RegionExtract (Address), IndexExtract (Address), Id
FROM Client
Ці перетворення визначають представлення, відповідно до якого можуть
виконуватися наступні мапування. Перетворення виконує зміну схеми, шляхом додавання
нових атрибутів, отриманих розщепленням імені й адреси джерела. Необхідні витяги
даних досягаються за допомогою UDF. Реалізації UDF можуть містити логіку очищення,
наприклад, для видалення невірного написання найменувань міст або відновлення
втрачених індексів.

Вирішення конфліктів
 Іноді потрібно виконати підготовку окремого джерела до інтеграції з іншими
джерелами, що може включати наступні етапи:
· Витяг значень із атрибутів вільного формату (розщеплення атрибутів).
Атрибути вільного формату часто містять множину окремих значень, що підлягають
витягу для підвищення точності представлення й підтримки наступних етапів очищення –
таких, як зіставлення елементів даних і видалення дублікатів. Типовими прикладами є
поля імен і адрес. Необхідні на цьому етапі перетворення перерозподіляють значення в
полі для одержання можливості переміщення слів і витягають значення для розщеплених
атрибутів.
· Перевірка допустимості й виправлення. На цьому етапі кожний елемент даних
джерела даних досліджується на наявність помилок, а виявлені помилки в міру
можливості автоматично виправляються. Перевірка орфографії на основі перегляду
словника потрібна для ідентифікації й виправлення помилок у написанні слів. Словники
географічних найменувань і поштових індексів допомагають коректувати адресні дані.
Атрибутивні залежності (дата народження – вік, загальна вартість – ціна за шт., місто –
регіональний телефонний код, і т.д.) можуть використовуватися для виявлення проблем і
заміни втрачених або виправлення невірних значень.
· Стандартизація. Для співвіднесення й інтеграції елементів даних, значення
атрибутів варто перетворити в погоджений і уніфікований формат. Наприклад, записи про
дату й час повинні бути оформлені в спеціальному форматі, імена й інші символьні дані
повинні конвертуватися або в прописні, або в малі літери, і т.д. Текстові дані можуть бути
стислі й уніфіковані за допомогою виявлення основи, видалення префіксів, суфіксів і
вступних слів. Абревіатури й зашифровані схеми підлягають погодженій розшифровці за
допомогою спеціального словника синонімів або застосування визначених правил
перетворення.
Вирішення проблем множини джерел вимагає зміни схем для досягнення інтеграції,
у тому числі й розщеплення, злиття, згортання й розгортання атрибутів і таблиць. На рівні
елемента даних повинні дозволятися проблеми із суперечливими представленнями й
даними, що перекривають один одного. До видалення дублікатів звичайно приступають
після того, як більша частина інших етапів перетворення й очищення вже виконані,
особливо – після очищення від помилок і суперечних представлень даних окремого
джерела. Цей процес виконується або над двома очищеними джерелами одночасно або
над окремим, уже інтегрованим набором даних. Видалення дублікатів вимагає, у першу
чергу, виявлення (тобто зіставлення) схожих записів, що відносяться до того самого
об'єкта реального оточення. Другим кроком повинне стати злиття схожих записів в один,
що включає всі відповідні атрибути без надлишковості.
У найпростішому випадку для кожного запису існує ідентифікаційний атрибут або
комбінація атрибутів, яку можна використовувати для зіставлення записів, наприклад,
якщо різні джерела мають загальний первинний ключ або якщо існують різні інші загальні
унікальні атрибути. У випадку окремого набору дані зіставлення можуть визначатися
сортуванням по ідентифікуючому атрибуті й перевіркою погодженості сусідніх записів.
Для визначення більшості або навіть всіх зіставлень в «нечіткому зіставленні»
(приблизному об'єднанні) необхідно знайти подібні записи, засновані на правилі
зіставлення. Наприклад, таке правило може затверджувати, що записи по деякій особі,
швидше за все, погоджені, якщо погоджене ім'я й фрагменти. Ступінь схожості між
записами часто виміряється числовими значеннями між 0 і 1, що звичайно залежать від
характеристик застосування. Наприклад, різні атрибути в правилі зіставлення можуть
надавати різного значення загальному рівню подібності. Для строкових компонентів
(наприклад, ім'я споживача, найменування компанії й ін.) можуть виявитися корисними
точне зіставлення й неявні методи, засновані на групових символах, частоті знаків,
редакторських відстанях, відстанях клавіатури й фонетичної подібності (soundex).
 Такий метод визначення відповідності елементів даних, як правило, є надзвичайно
довгою операцією при великих об’ємах даних.
Всі записи, для яких показник подібності перевищує граничний, можуть
розглядатися як відповідності або як кандидати на відповідність, далі підтверджувані або
відхилені користувачем.
Сьогодні на ринку існує великий вибір засобів для підтримки перетворень і
очищення даних. Ряд засобів орієнтовані на специфічну область – наприклад, на
очищення даних по іменах і адресах або на специфічні фази очищення – наприклад, аналіз
даних або виключення дублікатів. Завдяки своїй обмеженій області застосування,
спеціалізовані засоби звичайно дуже ефективні, однак для роботи із широким спектром
проблем перетворення й очищення вони мають потребу в доповненні іншими
інструментами. Загальною проблемою засобів ETL є обмежені можливості взаємодії за
рахунок власних API і форматів метаданих, що ускладнюють спільне використання різних
засобів.

Приклади виникнення «брудних даних»

Фіктивні значення
Можуть бути уведені фіктивні значення, такі, як ідентифікаційний код 9999999999,
або вік клієнта 999, або поштовий індекс 99999. Наявність строгих перевірок змушує
оператора видумувати значення в тих місцях, де реальні значення невідомі. Такі значення
відносно просто виявити, але особа, що вводить дані, може використовувати свій
ідентифікаційний код, вік або поштовий індекс.
Іноді зустрічаються фіктивні значення, які дійсно мають якийсь зміст (наприклад,
ідентифікаційний код 8888888888 для вказівки на статус клієнта-іноземця, або місячний
дохід у розмірі 99999.99 для вказівки на те, що клієнт має роботу. Якби довелося
підраховувати середньомісячний дохід клієнтів, результати були б некоректні.
Відсутність даних
Це відбувається тому, що різні бізнес-підрозділи мають різні потреби в існуванні
конкретних значень даних для виконання своєї роботи. Відділ, що видає іпотечні кредити,
може мати необхідність у формуванні звітів для виявлення статі й етнічної приналежності
клієнта, тоді як відділ, що видає комерційні кредити, її не має.
Багатоцільові поля
Два кредитних відділи з наведеного вище приклада, можливо, мають загальні
системи для видачі й обслуговування своїх кредитів і 80% потреб у даних є загальними
для обох типів кредитів. Проблема є у використанні тих 20% полів, що не є загальними.
Тут можуть бути поля даних, що використовуються для множини цілей, де те саме
значення в деякому полі в підсумку означає багато різних речей залежно від (1) того, який
відділ його ввів, і (2) наявності конкретних значень в одному, або в декількох полях
даних. Розмір і вміст таких записів може бути чим завгодно, починаючи з рядка дат або
рядка сум. Причому значення можуть згодом перевизначатися. Окремі користувачі
можуть використовувати це поле зовсім з іншою метою для виконання своїх
функціональних обов'язків, не інформуючи про це кого-небудь, і видалення «поганих
значень» просто прикриє всю роботу. Хтось взагалі не знав про перевизначення поля й
міг видавати важливу фінансову інформацію на підставі цих «поганих значень».
Незрозумілі (кодовані) дані
Наприклад, скажемо, кредитна система спочатку відслідковувала, чи виконуються з
іпотечного кредиту податкові відрахування. Код «О» міг використовуватися для
позначення «Ні, податкові відрахування з рахунку відсутні». Потім компанія почала
стягувати страхові внески. Оскільки код «О» уже використовувався для терміна
«Податкові відрахування відсутні», використовувався код «С» для вказівки «Страхові
відрахування відсутні». Необхідно пам'ятати, що обоє вони являють собою заперечення і є
такими, що перемикаються. Ще через кілька років потрібно було відслідковувати деякі
іпотечні кредити, застраховані державним органом і не потребуючі звичайного
страхування. Код «С» уже використовувався для позначення відсутності страхових
відрахувань, однак він має інше значення з погляду нових вимог, тому був доданий новий
код "Г". І оскільки необхідно відслідковувати в цьому полі «виключення з обробки
платежів», додане «І» як загальне позначення всіх і будь-яких виключень. Нехай є
кредити, для яких необхідно знати, що ні податків, ні страхових відрахувань із них не
виробляється. Можна написати логіку для опитування поля Сальдо Відрахувань; і якщо
там знаходиться значення, більше 0, варто перевірити, чи існує заключний запис про
відрахування.
Суперечливі дані
Наприклад, адреса нерухомості показує поштовий індекс Київської області й Одесу
як місто й область. Перевірка вулиці показує, що такої вулиці в Одесі немає.
Невідповідне використання адресних полів
Адреса складається з декількох складових. Адресне поле 1 було спочатку
призначено для особистого П.І.Б. або найменування компанії, можливо, що
випереджається зірочкою для вказівки на те, що це адреса юридичної особи, адресне поле
2 - для номера будинку й назви вулиці, і так далі. При уведенні може бути плутанина й
змішання значень.
Порушення бізнес-логіки
Наприклад, іпотека з регульованою процентною ставкою, у якій величина
мінімальної процентної ставки вище, ніж максимальної, або коли множинні процентні
ставки виявляються в кредиту з фіксованою процентною ставкою, що має той самий її
рівень протягом усього часу існування кредиту.
Повторне використання первинних ключів
Оскільки OLTP-системи рідко зберігають дані за весь період, значення первинних
ключів часто використовуються повторно. Наприклад, відділення банку № 84, що видало
й обслуговує більше 1000 іпотечних кредитів, закривається й передає обслуговування цих
кредитів відділенню № 207. Протягом одного року номер 84 привласнюється новому
відділенню. Вхідні 1000 кредитів продовжують указувати на відділення № 84 як на таке,
що видало їх, і всі ці кредити помилково приписуються новому відділенню № 84.
Неунікальні ідентифікатори
Наприклад, те саме фізичне відділення має два або більше ідентифікатори.
Наприклад, те саме відділення може бути позначене як відділення № 65 у кредитній і як
відділення № 389 у депозитній системах.
Проблеми інтеграції даних
Ці проблеми існують у двох видах: дані, які повинні, але не можуть бути зв'язані, і
дані, які ненавмисно зв'язані, хоча й не повинні б. Останнє трапляється найбільше часто,
коли поля або записи використовуються для множини цілей. Наприклад, якщо й для
покупок і для продажів використовується та сама програма для обліку продажів, і якщо
первинний ключ продавців може приймати ті ж значення, як і первинний ключ покупців, і
якщо продажі від покупок відрізняються тільки по різних прапорцях або перемикачам або
деякому спектру значень у певних полях, для того, щоб уникнути асоціювання продавця
або покупця не з тим типом транзакції, буде потрібною розширена програмна логіка.
Серйозною проблемою є неможливість з'єднати дані, які повинні бути з'єднані. Іноді
це пов'язане з попередньою проблемою неунікальних ключів, але частіше через
відсутність ключів взагалі. Наприклад, усі банки привласнюють унікальні номери
рахунків, але тільки деякі привласнюють унікальний номер клієнта. Десятиліттями
клієнти асоціювалися зі своїми рахунками згідно з полем з іменем клієнта в записі по
рахунку. У результаті з'являються різні написання або абревіатури того самого імені
клієнта, іноді клієнт фігурує під псевдонімом або дошлюбним ім'ям, а час від часу двоє
або троє клієнтів мають об'єднаний рахунок і всі їхні імена стиснуті в одне поле імені. У
результаті проаналізувати рахунки одного клієнта стає просто неможливо.
 Можливі ситуації, коли дані не існують і не можуть бути відновлені, поза
залежністю від кількості прикладених людських або автоматизованих зусиль.
Зустрічаються ситуації, коли значення настільки заплутані або знайдені в стільки
непорівнянних місцях з такими на вид різними й протилежними значеннями того самого
факту, що будь-яка спроба розшифрувати такі дані може породити ще більш невірні
результати. Виходить, такі дані не слід очищати.
Виникає також питання, чи очищати оперативні дані в рамках OLTP-систем або
перетворення, що очищають, виконувати протягом процесу витягу й завантаження в СД.
Часто користувачі OLTP-системи для оперативних цілей не мають потреби в більш чистих
даних, чим вони мають на даний момент, і будуть заперечувати проти їхньої зміни. Крім
того, часто це досить трудомістке завдання, до того ж неефективне з погляду ціни або
просто нереалізоване; тоді очищення виконується в процесі витягу й завантаження.
Користувачі й ІТ-фахівці повинні зрозуміти, як кожний випадок «брудних даних»
може перешкодити одержанню відповіді на питання бізнесу, і які зусилля знадобляться
для очищення таких даних.
Якщо вигоди перевищують вартість таких зусиль, дані певно повинні бути очищені.
Далі повинне бути ухвалене рішення, вносити чи ні необхідні зміни в OLTP-системи для:
- очищення існуючих даних;
- для запобігання уведення «брудних даних» у майбутньому.
Потрібно поліпшити OLTP-системи, якщо зусилля для цього не занадто великі
(наприклад, у випадку багаторічних архівних даних або коли це просто неможливо
зробити через те, що вхідні джерела даних більше не існують). Найчастіше більша частина
очищення в підсумку виконується під час процесів витягу й завантаження.
Якщо ціна переважує виграш, необхідно прийняти інше важливе рішення: чи варто
поміщати «брудні дані» у сховище як є або їх варто виключити. Знову, користувачі й ІТ-
фахівці повинні зважити кожну можливу вигоду від включення таких даних з можливим
збитком, що вони можуть принести, наприклад, з перекручуванням результатів аналізу
важливих тенденцій, роблячи їх у такий спосіб марними, або, ще гірше, забезпечуючи
помилкову інформацію, що веде до невірних рішень для бізнесу.

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

1. Які методи очищення даних Ви знаєте?
2. Перелічите етапи підготовки окремого джерела до інтеграції з іншими
джерелами.
3. У чому можуть бути причини виникнення «брудних даних»?
4. Чи потрібно виконувати очищення даних у самих джерелах даних?

Методичні вказівки до лекції: [2, с. 31–37]; [6,с. 91–102, 189-251].

Вправи
1. Приведіть приклади виникнення брудних даних у предметній області
«Поліклініка».
2. Приведіть приклади процедур очищення даних в предметній області «Деканат».
 Змістовний модуль 5
Мова багатомірних виражень MDХ
ЛЕКЦІЯ №12
Мова багатомірних виражень MDX. Основні поняття

Розглядаються наступні питання:

· історія виникнення мови MDX;
· задачі мови;
· основні концепції мови MDX;
· доступ до члена виміру;
· поняття кортежу;
· поняття множини (набору);
· основні операції з множинами.

Мова MDX (Multi-Dimensional eXpressions – мова багатомірних виражень) була

вперше представлена як складова OLE DB for OLAP в 1997 р. компанією Microsoft.
Незабаром з’явилася комерційна реалізація мови в Microsoft OLAP Services 7.0 (1998 р.),
потім – в Microsoft Analysis Services. Незважаючи на те, що MDX не є загальним
стандартом, а тільки внутрішньою специфікацією Microsoft, вона була прийнята багатьма
провідними розповсюджувачами технології OLAP. У їхньому числі розроблювачі
серверних застосувань, такі, як Applix, Microstrategy, SAS, SAP, Whitelight, NCR, а також
розроблювачі клієнтських застосувань: Panorama Software, Proclarity, AppSource, Cognos,
Business Objects, Brio Technology, Crystal Reports, Microsoft Excel, Microsoft Reporting
Services і інші. З появою XML for Analysis, у якому MDX була прийнята як стандартна
мова запитів, все більше число компаній (у їхньому числі, наприклад, Hyperion Solutions),
стали підтримувати MDX. Деякі компанії розширюють стандарт, щоб забезпечити
додаткову функціональність, але передбачається, що всі компоненти таких розширень
MDX розроблені відповідно до стандарту.
Задачі мови можна визначити в такий спосіб:
- MDX «розуміє» багатомірну модель устрою даних (куб, вимір, міра, комірка);
- мова дозволяє здійснювати навігацію по багатомірному просторі й визначеним
над ним ієрархіям;
- MDX потрібна не тільки розроблювачам і адміністраторам — вона може бути
корисною практично всім користувачам аналітичних застосувань.
MDX має два режими. При використанні як вираження MDX дозволяє визначати
багатомірні об'єкти й дані для обчислення значень, а також управляти ними. Як мова
запитів вона використовується для добування даних з багатомірних баз даних.
Хоча мова запитів MDX використовує синтаксис, подібний до синтаксису мови SQL,
ці мови значно відрізняються.

Основні концепції
Кожний вимір має одну або кілька ієрархій, а кожна ієрархія містить один або кілька
рівнів. Кожна ієрархія виміру містить один або кілька елементів, називаних членами
(members). Кожний член відповідає одному або декільком входженням цього значення в
базову таблицю вимірів.
Простір куба – це сукупність елементів ієрархій вимірів куба з мірами куба. Тому
простір куба визначається комбінаторним сполученням всіх елементів ієрархії виміру в
кубі й мер куба й визначає максимальний розмір куба. Важливо мати на увазі, що цей
простір включає всі можливі сполучення елементів ієрархії виміру, навіть сполучення, які
можуть здатися неможливими в реальному світі, наприклад сполучення, де містом є
Париж, а країнами — Англія, Іспанія, Японія або Індія, і т.д.
 Поняття автоматичної перевірки існування обмежує простір куба комірками, які
дійсно існують. Елементи ієрархії виміру можуть не існувати з елементами іншої ієрархії
у тому же вимірі.
Наприклад, простір куба, що містить ієрархію Місто, ієрархію Країна й міру
ОбсягПродажу, включає тільки ті елементи, які існують один з одним. Наприклад, якщо
ієрархія Місто містить елементи Київ, Одеса, Москва, Тула й Краків, а ієрархія Країна
містить країни Україна, РФ, Польща, то простір куба не містить комірку на перетинанні
елементів Москва й Україна.
Запит до неіснуючих комірок повертає значення NULL.
Об'єкт Measures (міри), по суті, являє собою спеціальний вимір, що є набором мір.
Доступ до члена виміру
Можна одержати доступ до члена виміру за допомогою імені цього виміру, імені
ієрархії й імені рівня. Наприклад:
[Місце]. [Ієрархія_Місце].[Україна].[Одеса].[Проспект Гагаріна].[будинок
№10].[квартира №123],
[Місце]. [Ієрархія_Місце].[Україна].[Одеса]
У наведених прикладах використаний докладний запис:
[<Вимір>].[<Ієрархія>].[<Член верхнього рівня>]. … ... . [<Член нижнього рівня>]
У деяких випадках унікальні в межах виміру елементи такого запису можна
опускати.
Наприклад, якщо перший квартал кожного року називається Q1, то такий член
виміру не можна опускати, необхідно буде уточнити вираження MDX, використовуючи
ім'я рівня. Якщо все-таки використовувати даний формат звертання до члена ієрархії,
MDX завжди буде витягати член Q1 для першого із представлених в ієрархії років.
Можна організувати кілька ієрархій для одного виміру, наприклад:
[Дата].[Ієрархія1].[<Рік>].[<Місяць>].[<Число>] і
[Дата].[Ієрархія2].[<№ тижня>].[<День тижня>]
У випадку єдиної ієрархії на неї можна послатися по імені виміру, тобто:
[Дата].[Ієрархія1].Members еквівалентно [Дата].Members ,
[Місце].[Ієрархія_Місце].[Міста].Members еквівалентно [Місце].[Міста].Members .
Кожному рівню ієрархії (Level) привласнене своє ім'я. Імена рівнів застосовуються в
конструкціях виду:
[<Вимір>].[<Ієрархія>].[<Рівень>].Members .
Наприклад: [Дата].[ Ієрархія1].[Місяця].Members - всі можливі місяця;
[Місце].[Ієрархія_Місце].[Вулиці].Members - всі вулиці, незалежно від країни й
міста.
Імена вимірів, ієрархій, рівнів і членів обов'язково потрібно брати у квадратні
дужки, якщо в ім'ї зустрічається пробіл, цифра або ім'я являє собою ключове слово MDX.
Таким чином, у МDХ існують три способи посилання на об'єкти вимірів, ієрархій,
рівнів і елементів:
- по імені;
- по повному імені;
- по унікальному імені.
Для визначення члена, посилання на який виконується по імені, сервер повинен
пройти по всіх вимірах і всіх їхніх ієрархіях у пошуку елемента із заданим ім'ям. Це
вимагає великої кількості ресурсів, особливо коли елементи виміри зберігаються в
реляційній базі даних (ROLAP-виміри). Крім того, посилання на об'єкт по імені можуть
привести до неоднозначних результатів, наприклад, коли елементи з однаковими іменами
існують у різних вимірах, наприклад, елемент Україна існує у вимірі Клієнт і у вимірі
Магазин.
Посилання на об'єкти по повному імені швидше, ніж посилання на об'єкти по їхніх
іменах. Вона працює добре для вимірів, ієрархій і рівнів, але має недоліки при
використанні для посилання на елемент. Якщо повне ім'я створене з'єднанням імен батьків
елемента, елемент перестає бути мобільним. Повне ім'я стане неправильним, якщо
елемент перейде від одного батька до іншого. Якщо розглядати покупця в ієрархії
Покупці, який може переїхати жити в інше місто, і ім'я елемента, що його представляє,
поміняється.
Третій спосіб посилання на об'єкти складається у використанні їхніх унікальних
імен. Сервер привласнює унікальне ім'я кожному виміру, ієрархії, рівню й елементу.
Клієнтськезастосування, що генерує МDХ, або програміст, що пише запит, може
одержувати унікальне ім'я об'єкта, використовуючи опис схеми або з результатів іншого
запиту.
Існують досить складні правила для генерації унікальних імен. Постачальники, що
підтримують МDХ, можуть мати різні алгоритми для генерації унікальних імен. Тому при
написанні запитів унікальні імена повинні запитуватися із сервера, наприклад, за
допомогою функції UniqueName

Якщо у вибірці обрано осей менше, ніж кількість вимірів у кубі, не задані значення
атрибутів призначаються.
У кожного виміру існує член за замовчуванням. Як правило, у ролі Default Member
виступає єдиний член спеціального рівня ієрархії [All], автоматично створюваного при
створенні виміру. Цей рівень містить сукупні результати по всім вимірі.
Вказівка на член за замовчуванням можна записати за допомогою вираження
DefaultMember:
[Клієнти].DefaultMember .
Якщо рівень [All] відсутній, у його ролі виступає перший член наступного рівня.
У деяких системах членом за замовчуванням можна призначити будь-який член або
MDX-вираження виміру.
Оскільки сукупність мер ([Measures]) теж є одним з вимірів, те й серед мір є елемент
за замовчуванням.

Кортеж (tuple) – це набір членів одного або декількох різних вимірів. Кортеж
однозначно визначає зріз даних у кубі. Кортеж представлений членами вимірів куба даних
(по одному члену з кожного виміру), розділеними комами. Кортеж указує на
конкретнукомірку або набір комірок усередині куба. Кортежі задаються за допомогою
круглих дужок.
Приклади:
([Місце].[Україна].[Київ].[вулиця Хрещатик], [Піл].[Ж], [Тип місця].[Місце
проживання] ) - усі жінки, що живуть на вулиці Хрещатик у Києві;
([Місце].[Україна].[Харків], [Тип місця].[Місце народження] ) – всі клієнти, що
народилися в Харкові.
Кортеж необов'язково повинен явно містити члени всіх вимірів куба даних.
Елемент кортежу повинен належати різним ієрархіям.
([2010], [Франція]) - правильно
([США], [Франція]) - неправильно, елементи кортежу з однієї ієрархії
Порядок, у якому представлені члени вимірів у кортежі, не має значення.
Кортеж, представлений єдиним членом, називають простим кортежем. Простий
кортеж можна не брати в круглі дужки. Наприклад, кортеж ([Клієнт].[Стана].[Україна]) є
простим кортежем і може бути представлений у вигляді [Клієнт].[Країна].[Україна] або
просто Клієнт.Країна.Україна.

Множина (або набір) (set) – це сукупність (об'єднання) кортежів, певних з

використанням однакової кількості тих самих вимірів.
Приклади:
 {[Дата].[1980].[Січень], [Дата].[1980].[Лютий] } – всі клієнти, що народилися в січні
або в лютому 1980 р.
{([Місце].[Україна].[Одеса], [Тип місця].[Місце проживання], [Дата
народження].[1980]), ([Місце].[Україна].[Херсон], [Тип місця].[Місце проживання], [Дата
народження].[1980])} – всі клієнти 1980 року народження, що проживають в Одесі або в
Херсоні.
Множинаукладається у фігурні дужки.
Кортежі (Клієнт.Країна.Україна, [Товар].[Категорія].[Продукти]) і
(Клієнт.Країна.РФ, [Дата].[2010].1 квартал]) не можна об'єднати для формування
множини. Хоча обоє вони засновані на двох вимірах, але збігається тільки перше із
включених у їхній состав вимірів (Клієнт).
Множина може містити нуль, один або кілька кортежів. Множина із нульовою
кількістю кортежів називається порожньою множиною. Порожній множині відповідає
запис { }.
Множина може містити кортежі, що дублюються.
{ Клієнт.Країна.Україна, Клієнт.Країна.РФ, Клієнт.Країна.Україна }
Перетинання кортежу або множини з якою-небудь мірою дає значення міри на даній
множині.
Набір всіх членів в інтервалі задається за допомогою двокрапки:
{[Час].[2007]:[Час].[2010]}

Основні операції з множинами

Множина або набір в MDX – це множина у математичному розумінні, і всі закони,
установлені алгеброю множин, можуть бути застосовані до цих множин.
Існують три операції алгебри множин і дві основні операції з множинами, які
дозволяють створювати нові множини із уже існуючих множин:
Об'єднання (Union);
Перетинання (Intersect);
Різниця (Except);
Перехресне з'єднання (Crossjoin);
Добування (Extract)
Union поєднує дві й більше множини однієї розмірності в одна множину.
Результуюча множина містить всі кортежі з кожної множини. Якщо кортеж існує в обох
первісних множинах, у новумножину Union він буде доданий тільки один раз –
повторюваний кортеж доданий не буде. Операція Union ({[Іванов],[Петров]},{[Сидоров]})
повертає множину
{Іванов, Петров, Сидоров}
Union являє собою еквівалент операції додавання, тому для створення об'єднання
множин також можна використовувати оператор +.
{[Іванов],[Петров]}+{[Сидоров]}
Крім того, MDX підтримує синтаксис операції Об'єднання (Union) з використанням
фігурних дужок, але ця операція не є точним еквівалентом функції Union або оператора +.
Якщо дві множини, поєднувані з використанням фігурних дужок, містять повторювані
кортежі, у результуючій множині дублікати зберігаються.
{{[Іванов],[Петров],[Сидоров]},{[Сидоров]}} повертає наступну множину
{Іванов, Петров, Сидоров, Сидоров}
Перетинання (Intersect) створює нову множину, що містить кортежі, загальні для
двох множин.
Наприклад, код
INTERSECT({[Шевченко], [Іванов], [Петров]}, {[Іванов], [Петров],[Сидоров]})
поверне наступнумножину {Іванов, Петров}
 Різниця (Ехсерt) знаходить розходження між двома множинами. Ця операція
створює нову множину, що містить елементи, що є елементами однієї множини, але не
елементами іншого.
Наприклад, код
Except({[Іванов],[Петров],[Сидоров]},{[Сидоров]}} поверне наступну множину
{Іванов, Петров}.
Тому що операція Ехсерt еквівалентна операторові вирахування, її можна записати
за допомогою знака «-»:
{[Іванов],[Петров],[Сидоров]}-{[Сидоров]}
Перехресне з'єднання (Crossjoin) генерує множину, що містить всі можливі
комбінації двох (або більше) множин зі збереженням у результуючій множині порядку
ієрархій, використаних в оригінальних множинах.
Ця функція часто використовується для проектування елементів з різних ієрархій на
ту саму вісь куба. Операція Crossjoin еквівалентна операторові множення.
Наприклад, код:
CROSSJOIN({[2009], [2010]},{[Україна] , [РФ], [Польща]})
поверне наступнумножину:
{([2009],[Україна]),([ 2009],[РФ]),([2009],[Польща]), ([2010], [Україна]), ([2010],
[РФ]), ([2010], [Польща])}
І цей код:
{[2009],[2010]}*{[Україна],[РФ],[Польща]}
поверне та ж сама множину.
Добування (Extract) створює множину, що містить кортежі тільки заданої ієрархії.
Ця операція протилежна Crossjoin. Наприклад, код:
Extract(CROSSJOIN({[2009],[2010]},{[Україна],[РФ], [Польща]}), [Дата].[Рік])
поверне наступнумножину:
{[2009],[2010]}

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

1. Як можна одержати доступ до члена виміру?
2. Для чого призначений вимір Measures?
3. Як визначається член за замовчуванням?
4. Що таке кортеж?
5. Які обмеження накладаються на кортежі, які можна поєднувати в множину?
6. Перелічите операції над множинами.

Методичні вказівки до лекції: [8, с. 84–93].

Вправи
1. Створіть куб К на основі бази даних Борею з вимірами Клієнт, Співробітник,
Товар, Час виконання замовлення й мірами Кількість і Ціна замовлення.
2. Приведіть приклади кортежів для кожного виміру.
3. Приведіть приклади множин для пар вимірів.
4. Створіть БД для предметної області «Біржа праці». На її основі розробіть СД.
При необхідності виконайте денормалізацію.
5. Створіть для СД із п.4 багатомірний куб зі схемою "сніжинка". Куб повинен
містити таблицю фактів з 2-3 мірами й не менш трьох вимірів. Хоча б один з вимірів
повинун представлятися двома зв'язаними таблицями. Один вимір повинне бути виміром
часу.
 ЛЕКЦІЯ №13
Мова багатомірних виражень MDX. Запит до кубу

Розглядаються наступні питання:

· синтаксис оператора SELECT;
· завдання осей результуючого куба;
· речення WHERE;
· іменовані множини;
· контекст запиту й контекст сеансу;
· члени, що обчислюються.

Для запиту MDX використовується наступний синтаксис.

[WITH <formula_expression> [, <formula_expression> ...]]
SELECT [<axis_expression>, [<axis_expression>...]]
FROM [<cube_expression>]
[WHERE [slicer_expression]]
Найпростіший запит виглядає в такий спосіб.
SELECT
FROM [Mycube]
Цей запит MDX повертає єдине значення, отримане в результаті агрегації значень
всіх комірок куба, що ставляться до заданої за замовчуванням міри, для заданих за
замовчуванням значень кожного виміру куба.
Вираження axis_expression визначає вимір, дані з якого потрібно витягти й має
наступний синтаксис.
<axis_expression> := <набір> ON Axis (номер осі)
В інструкції SELECT можна вказати до 128 осей.
Для спрощення уведення можна опускати слово axis, дужки й писати тільки номер,
що відповідають осі: on 0 або on 1.
Перші п'ять осей мають псевдоніми. Це осі COLUMNS (стовпці), ROWS (рядки),
PAGES (сторінки), SECTIONS (розділи) і CHAPTERS (глави). Наступні осі вказуються за
допомогою слова Axis, за яким слідує номер осі.
Приклад:
SELECT Measures.[Обсяг продажів] ON COLUMNS,
[Клієнти].[Країна].MEMBERS on ROWS,
[Товар].[Категорія].MEMBERS on PAGES
FROM [Mycube]
В MDX не можна пропускати «нижчі» осі (тобто осі з меншими порядковими
номерами). Якщо необхідно вказати в запиті вісь PAGES, то необхідно вказати осі
COLUMNS і ROWS.
В SQL речення SELECT використовується для визначення розміщення стовпців у
результуючій таблиці. У МDХ речення SELECT використовується для завдання осей у
результуючому багатомірному просторі.
Можна спроектувати на різні осі множини, що посилаються на той самий вимір,
якщо вони повинні посилатися на різні ієрархії цього виміру.
Приклад:
SELECT
{([Побутова хімія], [Квартал1]), ([Побутова хімія], [Квартал 2]),
([Напої], [Квартал 1]),( [Напої], [Квартал 2])} ON COLUMNS,
{[Measures].[Сума продажів],[Measures].[Витрати] } ON ROWS
FROM [Mycube]
 Вимірами куба є: Клієнт, Товар, Час, Магазин і Міри (Measures). Координати по
трьох із цих вимірів визначені оператором SELECT. Виміри Клієнт і Магазин залишені
невизначеними в запиті.
Коли кількість вимірів, спроектованих на осі, менше кількості вимірів у кубі,
система створює додаткову вісь, називану Вісь Зрізу (Slicer Axis), що містить всі інші
виміри. Вісь зрізу складається з одного члена кожного із цих атрибутів – елемента за
замовчуванням.

Речення FROM у запиті MDX визначає куб, з якого витягають дані для аналізу. Воно
нагадує речення FROM мови SQL, у якому вказується ім'я таблиці.
Вираження cube_expression позначає ім'я куба або підрозділу куба, з якого потрібно
витягти дані. Мова SQL допускає використання в реченні FROM декількох таблиць, однак
у запиті MDX можна вказати ім'я тільки одного куба даних. Куб, зазначений у речення
FROM, називають контекстом куба (cube context), і запит MDX виконується усередині
цього контексту. Тобто, кожна частина вираження axis_expression буде витягатисяі з
контексту куба, зазначеного в реченні FROM.
Приклад запиту, що витягає розмірність [Обсяг продажів] по осі X.
SELECT {[Measures].[Сума продажів]} ON COLUMNS
FROM [Mycube]
Зазначена в SELECT міра витягається з контексту куба [Mycube].
Можна одержувати дані з інших кубів, використовуючи спеціальну функцію
LookupCube. Якщо є два (або більше) куби із загальними членами вимірів, то ця функція
дає можливість за допомогою цих членів витягти розмірності, що не входять у поточний
контекст куба.

У запитах MDX використовуються аналогічні SQL інструкції, що задають умову

відбору, яка забезпечує повернення запитами тільки необхідних даних.
SELECT {Measures.[Сума продажів]} ON COLUMNS,
[Товар].MEMBERS on ROWS
FROM MyCube
WHERE [Час].[2010]
Вимір зрізу (slicer dimension) створюється при визначенні речення WHERE; по суті,
це фільтр, що виключає небажані виміри й члени.
Речення WHERE не обов'язково повинне бути в запиті; і навіть якщо в запиті воно є,
необов'язково вказувати в ньому координати із всіх можливих ієрархій.
Речення WHERE в SQL і МDХ відрізняються концептуально. Речення WHERE в
SQL використовується для обмеження записів, що читаються з таблиць. Речення WHERE
у МDХ використовується для визначення зрізу куба. Основне його призначення –
уточнення координат вимірів, які не були визначені в реченні SELECT.

Контекст виконання запиту

Коли сервер одержує запит, він у першу чергу проходить по елементах множин,
спроектованим на осі.
Ці елементи будуть повернуті клієнтському застосуванню, і клієнтськезастосування
звичайно відображає їх у вигляді заголовків таблиці або, можливо, у вигляді міток уздовж
осей діаграми.
Потім сервер обчислює значення комірок на перетинанні від кожної осі. Координати,
у контексті яких обчислюється значення, називаються поточними координатами.
У простому випадку існує тільки один кортеж у реченні WHERE, і сервер створює
поточні координати кожного виміру в кубі. Якщо в реченні WHERE задана множина
кортежів, то це вже більш складна структура даних – підкуб.
 Поточні координати створюються зі членів вимірів, які використовувалися в реченні
WHERE, і зі членів вимірів, що відповідають поточної ітерації по кожній осі. Для вимірів,
на які немає посилань ні на осях, ні в реченні WHERE, сервер використовує члени за
замовчуванням. Розглянемо, що відбувається усередині сервера, коли обчислюється
однакомірка у простому запиті.
SELECT { (Клієнт.Країна.Україна) } ON COLUMNS,
{(Товар.Категорія.Напої, Час.Рік.[2010])} ON ROWS
FROM MyCube
WHERE [Measures].[Продана кількість]
//Крок 1. Поточна координата заповнюється елементами за замовчуванням всіх
ієрархій вимірів. Усередині системи це виглядає в такий спосіб:
(Measures. DefaultMember,
Клієнт.All, Клієнт.Місто.All, Клієнт.Країна.All, Клієнт.Освіта.All, Клієнт.Стать. All,...,
Товар.All, Товар.Виробник.All, Товар.Категорія.All, ...,
Час.All, Час.Дата.All, Час.День.All, Час.Місяць.All, Час.Квартал.All, Час.Рік.All, ...,
Магазин.All, Магазин.[Місто магазина].All, Магазин.[Країна магазина].All, Магазин.
Менеджер.All,...
)
//Крок 2. Поточна координата перезаписується елементами, використовуваними в
реченні WHERE.
([Measures].[Продана кількість],
Клієнт.All, Клієнт.Місто.All, Клієнт.Країна.All, Клієнт.Освіта.All, Клієнт.Стать. All,...,
Товар.All, Товар.Виробник.All, Товар.Категорія.All, ...,
Час.All, Час.Дата.All, Час.День.All, Час.Місяць.All, Час.Квартал.All, Час.Рік.All, ...,
Магазин.All, Магазин.[Місто магазина].All, Магазин.[Країна магазина].All, Магазин.
Менеджер.All,...
)
//Крок 3.Поточна координата перезаписується елементами, заданими на осях
Columns і Rows.
([Measures].[Продана кількість],
Клієнт.All, Клієнт.Місто.All, Клієнт.Країна.Україна, Клієнт.Освіта.All, Клієнт.Стать.
All,...,
Товар.All, Товар.Виробник.All, Товар.All, Товар.Категорія.Напої, ...,
Час.All, Час.Дата.All, Час.День.All, Час.Місяць.All, Час.Квартал.All, Час.Рік.2010, ...,
Магазин.All, Магазин.[Місто магазина].All, Магазин.[Країна магазина].All, Магазин.
Менеджер.All,...
)
//Значення першоїкомірки обчислюється з координати, отриманої на кроці 3.
У багатьох випадках у вираженнях МDХ необхідно посилатися на поточну
координату. Для цього МDХ надає функцію доступу до поточного елемента:
<ієрархія>.CurrentMember. Ця функція повертає проекцію поточної координати на задану
ієрархію.

Побудова іменованих множин у багатомірних вираженнях

Щоб полегшити роботу з довгими, складними або часто використовуваними
вираженнями, у багатомірних вираженнях можна визначити таке вираження як іменована
множина.
По суті, іменованамножина являє собою вираження множини, якому призначений
псевдонім. В іменовану множину можуть входити будь-які елементи або функції, які
можуть звичайно включатися в множину. Псевдонім може використовуватися скрізь, де
припустимі множини.
Іменована множина можна визначити в одному з наступних контекстів:
 Контекст запиту. Щоб створити іменованумножину, що визначена як частина
запиту, з областю, обмеженої цим запитом, використовується ключове слово WITH. Потім
іменованумножину можна використовувати усередині оператора MDX SELECT. У такому
випадку іменована множина, створена з використанням ключового слова WITH, може
бути змінена без змін в інструкції SELECT.
Контекст сеансу. Щоб створити іменованумножину, область якої ширше контексту
запиту, тобто множина, що діє протягом сеансу багатомірних виражень, варто
використовувати інструкцію CREATE SET. Іменований набір, визначений з
використанням інструкції CREATE SET, доступний для всіх запитів багатомірних
виражень у цьому сеансі. Наприклад, інструкція CREATE SET корисна в клієнтському
застосуванні, у якому набір багаторазово застосовується в різних запитах.
Створення іменованих множин з областю дії запиту
WITH ( SET <Псевдонім> AS '<Вираження>')
[, ( SET <Псевдонім> AS '<Вираження> ') ... ]
SELECT <опис осей> ...
FROM <куб>
[ <WHERE ...> ]
Вираження – припустиме багатомірне вираження, що повертає множину.
Набір кортежів не обов'язково заключати в одинарні лапки (''). Одинарні лапки
використовуються для версії Analysis Services 2000.
Приклад. Нехай потрібно витягти відомості про продажі вин Шардоне й Каберне.
Цей запит повертає досить простий результуючий набір, однак є дуже довгим і
громіздким з погляду його обслуговування.
SELECT {
[Товар].[Всі товари].[Напої].[Алкоголь].[Пиво й вина].[Вино]. [Шабо].[Шабо Шардоне],
[Товар].[ Всі товари].[Напої].[Алкоголь].[Пиво й вина].[Вино].[ФБ].[ФБ Шардоне],
…
[Товар].[Всі товари].[Напої].[Алкоголь].[Пиво й вина].[Вино]. [Шабо].[Шабо Каберне],
[Товар].[ Всі товари].[Напої].[Алкоголь].[Пиво й вина].[Вино].[ФБ].[ФБ Каберне],
…
} ON COLUMNS,
{Measures.[Кількість продажів]} ON ROWS
FROM MyCube
Щоб спростити запит, можна створити іменованумножину[ШардонеКаберне] за
допомогою ключового слова WITH:
WITH SET [ШардонеКаберне] AS {
[Товар].[Всі товари].[Напої].[Алкоголь].[Пиво й вина].[Вино]. [Шабо].[Шабо Шардоне],
[Товар].[ Всі товари].[Напої].[Алкоголь].[Пиво й вина].[Вино].[ФБ].[ФБ Шардоне],
…
[Товар].[Всі товари].[Напої].[Алкоголь].[Пиво й вина].[Вино]. [Шабо].[Шабо Каберне],
[Товар].[ Всі товари].[Напої].[Алкоголь].[Пиво й вина].[Вино].[ФБ].[ФБ Каберне],
…}
SELECT [ШардонеКаберне] ON COLUMNS,
{Measures.[Кількість продажів]} ON ROWS
FROM MyCube
/Синтаксис оператора створення іменованої множини з областю сеансу для
поточного куба.
CREATE [SESSION] [HIDDEN] SET
CURRENTCUBE | <ім'я куба> .<псевдонім> AS '<Вираження>'
Для звертання до поточного куба замість вказівки імені куба рекомендується
використовувати змінну CURRENTCUBE.
 Ключове слово HIDDEN позначає елементи, що обчислюються, як сховані. Такі
елементи, що обчислюються, не видні користувачам, що звертаються до куба із запитом.
CREATE SET [MyCube].[Мійтовар] AS '{[Товар].[Категорія].[Напої]}'
SELECT [Мійтовар] ON 0
FROM [MyCube]
Іменована множина, створена за допомогою оператора CREATE SET, видаляється
тільки при закритті сеансу багатомірних виражень.
Область запиту має пріоритет у порівнянні з областю сеансу.

Член, щообчислюється, можна створити в будь-якому місці ієрархії. Крім того,

члени,що обчислюються, можуть залежати не тільки від існуючих елементів куба, але й
від інших елементів, що обчислюються, визначених у тім же багатомірному вираженні.
При визначенні члена, що обчислюється, для нього можна задати один з наступних
контекстів.
· Область запиту. Для створення члена, що обчислюється, обумовленого як
частина багатомірного запиту, застосовується ключове слово WITH. Після створення
обчислюється член, що, можна використовувати в операторі SELECT.
· Область сеансу. Для створення члена, що обчислюється, область якого
ширше контексту запиту й поширюється на весь сеанс багатомірних виражень,
застосовується оператор CREATE MEMBER. Такий член, що обчислюється, доступний
для всіх запитів поточного сеансу.

Створення членів, що обчислюються, для області запиту

WITH [ CALCULATED ] MEMBER <Псевдонім> AS <Вираження>
<Властивість>= <Значення> [ , ... ] ]
SELECT <Опис осей>
FROM <Куб>
[ WHERE <Вираження>]
У синтаксисі WITH аргумент Псевдонім – це повне ім'я члена, що обчислюється.
Повне ім'я містить у собі вимір або рівень, з яким зв'язаний член, що обчислюється.
Можна задати значення властивостей комірки для члена, що обчислюється, указавши ім'я
властивості комірки й значення властивості. Також речення WITH забезпечує можливість
змінювати вміст комірок за допомогою виклику функцій із зовнішніх бібліотек,
реалізувати деякі складні концепції типу порядку обчислення й черговості проходу й ін.
Приклад. Визначити член, що обчислюється, [Measures].[Спеціальна знижка], що
розраховує особливу знижку, виходячи з початкової суми знижки.
WITH
MEMBER [Measures].[Спеціальна знижка] AS
[Measures].[Сума знижки] * 1.5
SELECT
[Measures].[Спеціальна знижка] on COLUMNS,
NON EMPTY [Product].[Product].MEMBERS ON Rows
FROM [MyCube]
WHERE [Товар].[Категорія].[Напої]
Члени, що обчислюються, можна створювати в будь-якій точці ієрархії. Наприклад,
у наступному запиті визначається член, що обчислюється, [Гарний продавець], за
допомогою якого визначається, чи продав заданий магазин більше 100 пляшок пива й
вина. Однак у запиті член, що обчислюється, [Гарний продавець], створюється не як
нащадок виміру [Товар], а як нащадок члена [Пиво й вина].
WITH
MEMBER [Товар].[Пиво й вино].[Гарний продавець] AS
IIf([Товар].[Пиво й вино] > 100, "Так","Ні")
 SELECT
{[Товар].[Гарний продавець]} ON COLUMNS,
Магазин.[Назва магазина].Members ON ROWS
FROM MyCube
Для виміру Measures також можна створювати члени, що обчислюються. Фактично
більшість членів, що обчислюються, застосовуваних у реальних бізнес-процесах, звичайно
створюється саме для виміру Measures. Члени, що обчислюються, створені для виміру
Measures, прийнято називати мерами, що обчислюються.
Члени, що обчислюються, також можуть створюватися на основі інших членів, що
обчислюються, обумовлених у тім же багатомірному вираженні. Наприклад, у наступному
запиті значення, створене в першому члені, що обчислюється, [Measures].[Спеціальна
знижка], використовується для формування значення другого члена, що обчислюється,
[Measures].[Сума спеціальної знижки].
WITH
MEMBER [Measures].[Спеціальна знижка] AS
[Measures].[Відсоток знижки] * 1.5,
MEMBER [Measures].[Сума спеціальної знижки] AS
[Measures].[Ціна одиниці] * [Measures].[Спеціальна знижка],
SELECT
{[Measures].[Спеціальна знижка],
[Measures].[ Сума спеціальної знижки]} on COLUMNS,
NON EMPTY [Товар].MEMBERS ON Rows
FROM [MyCube]
WHERE [Товар].[Категорія].[Напої]

Параметр SOLVE_ORDER визначає порядок, у якому повинні обчислюватися

члени, якщо задано кілька членів, що обчислюються.
Нехай потрібно зрівняти якість роботи компаній між двома роками й побачити
зміни. Можна побудувати запит, що використовує {[2010], [2011]}як осі й переглядати
пари чисел для кожної міри. А можна визначити член, що обчислюється, на рівні Рік,
паралель між 2010 і 2011, що буде визначати різницю між ними:
WITH MEMBER Час.[11 до 10] AS 'Час.[2011] -Час.[2010]'
SELECT
{ Час.[11 до 10] } ON COLUMNS,
Measures.MEMBERS ON ROWS
FROM MyCube
Якщо потрібно побачити різницю між груднем і жовтнем 2010 року, можна створити
член, що обчислюється, усередині члена 2010.
WITH MEMBER Час.[2010].[Дек до Окт] AS 'Час.[2010].[12] - Час.[2010].[10]'

WITH
MEMBER Measures.Прибуток AS 'Measures.Продаж – Measures.Собівартість'
MEMBER Час.[11 до 10] AS 'Час.[2011] - Час.[2010]'
SELECT
{Measures.Продаж, Measures.Собівартість, Measures.Прибуток } ON
COLUMNS,
{ Час.[2010], Час.[2011], Час.[11 to 10] } ON ROWS
FROM MyCube
Продаж Собівартість Прибуток
2010 300 220 80
2011 350 210 140
11 до 10 50 -10 60
 Створення елементів, що обчислюються, з областю дії сеансу
CREATE [ SESSION ] [HIDDDEN] [ CALCULATED ] MEMBER
CURRENTCUBE | <Ім'я куба >.<Псевдонім >
AS <Вираження>
[,<Властивість>= <Значення>, ...n]
[,SCOPE_ISOLATION = CUBE]
Аргумент <Властивість> може відноситися до стандартних або додаткових
властивостей елемента, що обчислюється.
У кожного елемента, що обчислюється, є набір стандартних властивостей. При
підключенні клієнтського застосування до Analysis Services стандартні властивості або
підтримуються, або доступні для підтримки на вибір адміністратора.
Додаткові властивості можуть бути доступні залежно від визначення куба.
Наступні властивості відображають відомості, що відносяться до рівня виміру в
даному кубі.
Властивість Опис
SOLVE_ORDER Порядок, у якому цей елемент буде обчислюватися у
випадках, коли один елемент, що обчислюється, посилається
на іншій.
FORMAT_STRING Рядок форматування Microsoft Office, використовувана
клієнтським застосування для відображення значень комірок
VISIBLE Визначення видимості елемента, що обчислюється, у наборі
рядків схеми. Ненульове значення вказує, що даний елемент,
що обчислюються, бачений. Значення цієї властивості за
замовчуванням дорівнює Visible.
Невидимі елементи, що обчислюються (для яких значення
властивості дорівнює нулю) звичайно використовуються як
проміжні етапи при обчисленні більш складних елементів.
До таким елементів, що обчислюються, можуть також
звертатися інші типи елементів, наприклад, міри.
NON_EMPTY_BEHAVIOR Указує міру або набір, використовувані для визначення
поводження елементів, що обчислюються, при дозволі
порожніх комірок

Приклад
CREATE MEMBER CURRENTCUBE.Measures. [Відносний прибуток]
AS 'Measures.[Сума продажу]/Measures.[Сума закупівель]', SOLVE_ORDER =
10

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

1. Перелічите речення оператора SELECT.
2. У чому відмінність між однаковими реченнями мов SQL і MDX?
3. Чим відрізняються контекст запиту й контекст сеансу?
4. Як створюється іменована множина?
5. Що таке член, що обчислюється?

Методичні вказівки до лекції: [3, с. 165–180]; [8, с. 94–100].

Вправи
1. Напишіть запит до куба К, створеному у вправах до попередньої лекції, що
формує двовимірну таблицю з виводом членів одного з вимірів.
 2. Одержати результати запитів до куба, створеному у вправі 5 лекції №10.
Продемонструвати наступні можливості MDX (для кожного випадку окремий запит):
1) простий запит, що повертає двовимірну таблицю, на одній осі виводяться члени
виміру, на іншій – міри куба;
2) запит, що повертає тривимірний куб, з використанням конструкції Where;
3) застосування операцій з множинами Unіon, Іntersect або Except;
4) застосування операцій з множинами Crossjoіn;
5) створення й використання іменованих множин з областю дії запиту;
6) створення й використання елементів, які обчислюються, з областю дії запиту.
При необхідності відредагувати дані в СД, щоб мати можливість побачити
результати запитів.
 ЛЕКЦІЯ №14
Функції мови багатомірних виражень MDX

Розглядаються наступні питання:

· категорії функцій;
·функції для навігації в ієрархіях;
·фільтрація даних;
·сортування даних.

Із синтаксичної точки зору функції МDХ можна розділити на методи й властивості.

Методи мають наступний синтаксис:
<function_name> ([<parameter> [, <parameter>...])
Наприклад:
CROSSJOIN({[2010],[2011]},{[Україна],[РФ], [Молдова]}), [Час])
А властивості мають наступний синтаксис:
<object_name>.<property_name>[ (<parameter>[,<parameter>...]
Наприклад:
[Час].DefaultMember
Обидві ці різновиди функцій повертають значення одного з наступних типів:
Dimension (Вимір), Hierarchy (Ієрархія), Level (Рівень), Member (Член), Tuple (Кортеж), Set
(Множина) і Scalar (Скалярне значення), які, у свою чергу, можуть бути передані як
параметри в інші функції
Функції для навігації в ієрархіях
Функція Members застосовується до ієрархій або до рівнів.
При застосуванні до ієрархії функція повертає набір всіх членів ієрархії, незалежно
від рівня.
Приклад:
[Дата].[Ієрархія1].Members – повертає повний перелік всіх років, місяців і днів.
При застосуванні до рівня функція повертає набір всіх членів виміру, що
перебувають на даному рівні.
Приклад: [Місце].[Ієрархія_Місце].[Міста].Members – повертає повний перелік всіх
міст.
Функція AllMembers працює аналогічно функції Members, але Members повертає всі
елементи ієрархії, крім тих, що обчислюються, а AllMembers повертає також і елементи,
що обчислюються.
Для переміщення в межах одного рівня, використовуються функції PrevMember і
NextMember:
[Дата].[2009].[Березень].NextMember – повертає квітень 2009 року,
[Дата].[2009].[Березень].PrevMember – повертає лютий 2009 року,
[Дата].[2009].[Березень].PrevMember.PrevMember – повертає січень 2009 року.
Для більш компактного запису застосовуються функції Lag(.) і Lеad(.):
[Дата].[2009].[Березень]. Lag(2) – повертає січень 2009 року,
[Дата].[2009].[Березень]. Lеad(5) – повертає серпень 2009 року,
[Дата].[2009].[Березень]. Lag(-1) – повертає квітень 2009 року.
Розглянемо приклад ієрархії Магазини (Stores) виміру Магазин (Store).
У цій ієрархії елемент ALL – батько (parent) елементів наступного рівня ієрархії:
Україна, РФ і Молдова. Області Одеська, Київська й Херсонська є дочірніми (children) для
Україна, і т.д. Області Одеська, Київська й Херсонська також є нащадками (descendants)
елемента ALL, а ALL – це предок (ancestor) членів, що представляють області.
Для переміщення нагору й униз по рівнях використовуються функції Children і
Parent:
[Дата].[2009].[Березень].Children – повертає всі дні березня,
 [Дата].[2009].[Березень].Parent – повертає [Дата].[2009],
[Дата].[2009].[Березень].[25].Parent.Parent – повертає [Дата].[2009] .
Функція Children створює множину елементів, які є дочірніми стосовно заданого
елемента
SELECT [Україна].Children ON COLUMNS FROM [MyCube]
Київська Херсонська Одеська
12345 3456 345678

Функція Descendants небагато складніше, але вона більш гнучка, чим функція
Children. Вона використовується для одержання нащадків члена.
Наприклад, необхідно проаналізувати продажі магазинів, розташованих у різних
містах України
SELECT DESCENDANTS([Україна],[Місто магазина]) ON COLUMNS
FROM [MyCube]
Функція Descendants повертає множину членів, які є нащадками заданого члена на
заданому рівні ієрархії.
Щоб побачити листові елементи (leaf memebers) – елементи, у яких немає нащадків,
що є нащадками елемента Україна, використовується ключове слово LEAVES.
SELECT DESCENDANTS([Магазин.[Країна магазина].[Україна], LEAVES)
on COLUMNS
FROM [MyCube]
МDХ підтримує цілий ряд функцій, які підпадають під категорію функцій для
навігації по ієрархії, наприклад, FirstChild, LastChild, функції для роботи з елементами
одного рівня, і т.д.

Функція Filter має два параметри: множина і вираження МDХ, що задає критерій і
повертає значення типу Boolean. Для обчислення результату функції Filter сервер
проходить множину, що була передана як перший параметр функції. Потім для кожного
кортежу в множині обчислює вираження, передане як другий параметр. Якщо це
вираження приймає значення True, кортеж включається в результуючу множину.
Наприклад, нехай потрібно визначити магазини, продажі в які знизилися в 2010 р., у
порівнянні з 2009 р.
SELECT Filter([Магазин].members,
([Кількість продажів], [2010]) < ([Кількість продажів],[2009])) ON COLUMNS,
{[2009], [2010]} ON ROWS
FROM [MyCube]
WHERE [Кількість продажів]
Для виконання функції Filter сервер обчислює вираження фільтра ([Кількість
продажів],[2010]) < ([Кількість продажів],[2009]). Це вираження містить тільки члени
вимірів Measure і Час. Всі інші члени визначаються по кроках, описаних у визначенні
контексту запиту: сервер спочатку встановлює в поточну координату члени за
замовчуванням всіх атрибутів, а потім перезаписує їхніми членами вимірів, зазначеними в
реченні WHERE. Потім сервер перезаписує члени, зазначені у вираженні критерію. І,
нарешті, перезаписуються члени, зазначені у множині,яка фільтрується.
Інший приклад
SELECT Filter([Клієнт]. [Країна].members,
[Measures].[Кількість продажів].Value>1000) ON COLUMNS
FROM [MyCube]
WHERE ([Час].[Рік].[2009])
У цьому запиті фільтруються магазини в міру Кількість продажів. Нехай мережа
магазинів спочатку була тільки в Україні; так що в 2009 р. всі продажі були тільки в
Україні. Але в 2010 р. товари продавалися також у Росії й Молдові. Якби вираження Filter
обчислювалося в контексті вираження, а не в контексті всього запиту, у результаті були б
отримані всі три країни: Україна, РФ і Молдова. Для виміру Час використовується член за
замовчуванням ALL. У запиті із приклада буде отримана тільки одна країна: Україна,
тому що поточний контекст для виконання вираження включає члени, зазначені в реченні
WHERE
Україна
22786
Тобто речення WHERE впливає на обчислення вираження критерію й на результат
функції Filter.
Щоб краще зрозуміти правила обчислення контексту у функції фільтрації,
розглянемо, що відбудеться, якщо виміри, використовувані у вираженні критерію, були б
тими ж самими, що й у реченні WHERE. Допустимо, що в запиті вимір Measure існує й у
речнні WHERE, і у вираженні критерію. При виконанні вираження критерію сервер буде
використовувати міру Кількість продажів, але для обчислення значень комірок буде
використана міра Сума продажів.
SELECT Filter([Клієнт].[Країна].members,
[Measures].[Кількість продажів].Value>1000) ON COLUMNS
FROM [MyCube]
WHERE ([Час].[Рік].[2009], [Measures].[Сума продажів])

Функція Order сортує кортежі в множині у відповідності зі значенням вираження,

що передається як другий параметр.
Приклад. Відсортувати магазини за значеннями міри Сума продажів.
SELECT Order( [Магазин].members, [Measures].[Сума продажів], BDESC)
ON COLUMNS
FROM [MyCube]
У цьому операторі результуюча множина відсортована в порядку убування. Але при
цьому зігнорована ієрархічність множини.
Розглянемо приклад, що показує сортування зі збереженням ієрархічності.
Наприклад, треба проаналізувати продуктивність магазинів, але потрібно зробити це в
контексті країни, у якій розташований магазин. Тому необхідно не просто відсортувати
магазини, порівнюючи їхній один з одним. Спочатку потрібно відсортувати значення для
країн, у яких розташовані магазини. Потім будуть відсортовані області, міста й тільки
після всього цього – магазини. Тепер можна порівнювати значення продажів в одному
магазині зі значеннями продажів в інших магазинах того ж самого міста. Ключове слово
DESC у функції Order указує системі, що при упорядкуваннімножини в убутному порядку
треба зберегти ієрархічність, визанчену користувальницькою ієрархією.
SELECT Order(([Магазин].[Країна магазина].members,
[Магазин].[Область магазина].members),
[Measures].[Сума продажів], DESC) ON COLUMNS
FROM [MyCube]

Україна Одеська Херсонська Київська Молдова РФ Московська Брянська …

6 3 2 1 5 4 3 1

Результати цього запиту показують, що найбільше продажів було зроблено в

Україні, і серед областей в Україні найбільше продажів в Одеській області, потім ідуть
магазини в Херсонській області й потім – у Київській.
Невизначені члени
Члени виміру, використані в MDX-Запиті, можуть не існувати в кубі (наприклад,
вони можуть бути задані неправильно). Комірки багатомірного простору теж можуть
виявитися порожніми.
 Наприклад, в MDX-вираженні використовується член, що перебуває поза границями
куба. Це може відбутися, наприклад, коли запит вибирає батьківський елемент елемента,
що перебуває на верхньому рівні ієрархії. Для обробки таких випадків уведена концепція
невизначених членів (Null Members) і невизначених кортежів (Null tuples):
- сервер використовує невизначений член для посилання на координату, що
перебуває поза простором куба;
- якщо кортеж містить хоча б один невизначений член, він називається
невизначеним кортежем.
У деяких випадках використання невизначених членів і кортежів дозволено, в
інших– приводить до повідомлення про помилку. Деякі функції МDХ повертають
помилку, якщо як параметр передається невизначений член або кортеж.
Якщо множина не містить кортежів або містить тільки невизначені кортежі, воно
називається порожньою множиною (empty set). Якщо множина містить як звичайні, так і
невизначені кортежі, користувачеві вертаються тільки звичайні кортежі. Наприклад,
наступний запит поверне тільки один кортеж:
SELECT {[All], [All].Parent} ON COLUMNS
FROM [MyCube]
All
22786

Режим відсутності члена

В Analysis Services 2000 при посиланні на член по імені, що не відповідає ніякому
елементу в кубі, видавалася помилка, що приводило до проблем у деяких клієнтських
застосуаннях. Наприклад, клієнтські затосувння зберігають текст запитів МDХ, які
використовувалися для формування звітів. Згодом, якщо члени видалялися із системи,
запити, що посилаються на вилучені елементи, переставали працювати, і звіти
переставали відкриватися. Analysis Services 2005 представлена нова можливість – Режим
Відсутності члена (Missing Member Mode).
Цей режим дозволяє запиту або вираженню МDХ посилатися на члени, які не
існують у кубі. Система перетворить такі члени в невизначені.
Наприклад, якщо потрібно вибрати деяких покупців, можна написати наступний
запит SQL
SELECT Прізвище, Ім'я, По батькові, Посада
FROM Клієнт
WHERE Прізвище = 'Іванов' or Прізвище ='Петров'
Якщо в базі даних не існує покупця на прізвище Петров, запит поверне тільки один
запис для клієнта Іванов і не викличе помилку.
Аналогічний МDХ-запит
SELECT {[Клієнт].[Іванов],[ Клієнт].[Петров]} ON COLUMNS
FROM [MyCube]
В Analysis Services 2000 відсутність елемента Петров у базі даних привело б до
помилки. Analysis Services 2005 у режимі відсутності елемента виконає запит успішно й
поверне результат зі значенням тільки для покупця Іванов.
Іванов
22786

Режим відсутності члена може бути включений і виключений у рамках виміру. Деякі
виміри більш гнучкі, і дані в них міняються частіше, чим в інших. Наприклад, вимір
покупців буде часто мінятися, а вимір часу, наприклад, досить постійно.
Для керування режимом відсутності члена вимір має властивість Режим Відсутності
члена (MdxMissingMemberMode), що може бути встановлена в стан Помилки (Error) або
Ігнорувати Помилку (IgnoreError). За замовчуванням режим відсутності члена
встановлений в Ігнорувати Помилку (IgnoreError).
Режим відсутності елемента не поширюється на імена вимірів, і неправильно
зазначене ім'я виміру приведе до помилки.

Кортежі, автоматична перевірка існування

Відомо, що простір куба визначається елементами ієрархій атрибутів. Але в
дійсності багатомірний простір обмежений. Існують комбінації елементів з різних ієрархій
членів вимірів, які просто не існують у таблиці виміру або в кубі. Наприклад, покупець
Ірина Петрова – Жінка, і в таблиці виміру Покупець існує запис Ірина Петрова, Ж. Це
значить, що кортеж ([Клієнт].[Стать].[Ж], [Ірина Петрова]) існує у вимірі Клієнт. Чоловіка
з ім'ям Ірина Петрова у вимірі не задано, тому кортеж ([Клієнт].[Стать].[M], [Ірина
Петрова]) не існує. Коли вираження МDХ посилається на кортеж, що не існує у вимірі, то
система перетворить його до невизначеного кортежу. Наприклад, наступний запит
поверне порожній результат:
SELECT {([Клієнт].[Стать].[M], [Ірина Петрова]) } on COLUMNS
FROM [MyCube]
Результатом виконання вираження МDХ не може бути неіснуючий кортеж. Тому
система видаляє неіснуючі кортежі з результуючої множини спеціальною операцією,
називаної автоматична перевірка існування (Auto-Exists). Результати застосування
системою операції Auto-Exists можна побачити при виконанні наступної функції Crossjoin.
Якщо множини, що беруть участь у функції Crossjoin, належать тому самому виміру,
неіснуючі кортежі видаляються. Наприклад, якщо взяти множину із двох покупців –Ірина
Петрова (жінка) і Василь Іванов (чоловік) – і використовувати функцію Crossjoin для
об'єднання цієї множини з множиною, що складається з одного елемента,
[Клієнт].[Стать].[M], що результуючамножина не буде містити повне перехресне
з'єднання ([Ірина Петрова], [M]), ([Василь Іванов], [M]), а тільки один кортеж ([Василь
Іванов, [M]).
SELECT { [Ірина Петрова], [Василь Іванов] } * [Клієнт].[Стать].[M] on COLUMNS
FROM [MyCube]
WHERE [Measures].[Кількість продажів]
Іванов
М
44
Сервер не виконує Auto-Exists між осями, але Auto-Exists виконується для множин,
спроектованих на осі, з множиною, заданою в реченні WHERE. Наприклад, якщо
помістити множину {[Ірина Петрова], [Василь Іванов]} на вісь, але елемент
[Клієнт].[Стать].[M] у речення WHERE – кортеж [Ірина Петрова] буде вилучений з
множини, спроектованої на вісь COLUMNS.
SELECT { [Ірина Петрова], [Василь Іванов] } ON COLUMNS
FROM [MyCube]
WHERE ([Measures].[ Кількість продажів],[Клієнт].[Стать].[M])
Іванов
44
Для того щоб визначити, які елементи існують із іншими елементами, на додаток до
операції Auto-Exists, можна використовувати МDХ-Функцію Exists, уведену в Analysis
Services 2005. Функція Exists приймає як параметри дві множини й повертає множину
кортежів з першої множини, які існують хоча б для кортежу із другої множини.
Наприклад,
SELECT Exists({[Ірина Петрова], [Василь Іванов]}, [Клієнт].[Стать].[M]) ON
COLUMNS
FROM [MyCube]
 WHERE [Measures].[Кількість продажів]
Приклад. Одержати відомості про продажі для покупців, які працюють
менеджерами.
SELECT [Measures].[ Кількість продажів] on COLUMNS,
Exists([Клієнт].members,
[Клієнт].[Посада].[Менеджер]) ON ROWS
FROM [MyCube]

Невизначені значення й порожні комірки

Логічний простір куба, до якого можна звертатися із запиту МDХ, є дуже великим.
Воно включає комбінації всіх елементів всіх ієрархій, незалежно від того, чи існують які-
небудь дані для цих комбінацій.
Нехай організація почала працювати в Україні, а потім розширила своє діяльність на
РФ і Молдову. Тому в 2009 р. продажі були тільки в магазинах в Україні, так що в
багатомірному просторі не існує даних про продажі в РФ і Молдові. Нехай є запит для
одержання інформації про продажі в 2009 р. і про посади покупців, які зробили покупки в
магазинах різних країн:
SELECT [Клієнт].[Посада].members ON COLUMNS,
[Магазин]. [Країна магазина].members ON ROWS
FROM [MyCube]
WHERE ([Measures].[Сума продажів],[Час].[Рік].[2009])
Директор Фахівець Менеджер
Молдова (null) (null) (null)
РФ (null) (null) (null) …
Україна 345 567 891
Не визначена (null) (null) (null)

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

використовувати оператор NON EMPTY.
SELECT [Клієнт].[Посада].members ON COLUMNS,
NON EMPTY [Магазин].[Країна магазина].members ON ROWS
FROM [MyCube]
WHERE ([Measures].[Сума продажів],[Час].[Рік].[2009])

Директор Фахівець Менеджер

Україна 345 567 891

Однак навіть якщо використовується оператор NON EMPTY, результати запиту

однаково можуть містити порожні комірки, тому що оператор NON EMPTY видаляє
кортежі з множини, спроектованої на вісь, для яких всі комірки порожні.
Оператор NON EMPTY діє на верхньому рівні запиту. Це означає, що спочатку
генеруються множини, що визначають осі, а потім видаляються кортежі, що приводять до
порожніх комірок. Існують випадки, коли продуктивність застосування буде значно вище,
якщо порожні кортежі були б вилучені раніше в логіці виконання запиту.
Якщо запит МDХ використовує функцію Filter для фільтрації дуже великої множини,
на підставі вираження, що містить значення кортежу, і простір куба дуже розріджений,
було б ефективніше видалити всі кортежі, що створюють порожні комірки, перед тим, як
виконувати фільтрацію. МDХ надає функцію NonEmpty, що дозволяє видаляти такі
кортежі з множини.
Наприклад, необхідно одержати всіх покупців з усіма магазинами, у яких покупець
купив більше 10 одиниць товару. Для цього можна написати наступний запит:
SELECT Filter([Клієнт].members * [Магазин].[Країна магазина].members,
 [Measures].[Кількість продажів] >10) ON COLUMNS
FROM [MyCube]
WHERE [Measures].[ Кількість продажів]
Перехресне з'єднання всіх клієнтів з усіма магазинами дає досить великумножину, але
множина, що відповідає реальним покупкам у магазині, значно менше. Тому можна
використовувати функцію NonEmpty для оптимізації цього запиту, так що вона видалить
порожні кортежі до фільтрації множини:
SELECT Filter(NonEmpty([Клієнт]..members * [Магазин].[Країна Магазина],
[Measures].[Кількість продажів]), [Measures].[Кількість продажів]>10) ON COLUMNS
FROM [MyCube]
WHERE [Measures].[ Кількість продажів]
На перший погляд, функція NonEmpty і оператор NON EMPTY роблять те саме, але
виконуються вони в різних контекстах. Запити, які виглядають схоже, можуть повертати
різні результати. Нехай є два запити, один з функцією NonEmpty, інший– з оператором
NON EMPTY:
SELECT [Час].[Рік].[2009] ON COLUMNS,
NONEMPTY ([Магазин].[Країна магазина].members) ON ROWS
FROM [MyCube]
и
SELECT [Час].[Рік].[2009] ON COLUMNS,
NON EMPTY [Магазин].[Країна магазина].members ON ROWS
FROM [MyCube]
Ці запити повертають різні результати.
2009 2009
Молдова (null) и Україна 234
РФ (null)
Україна 234

Функція NonEmpty обчислюється, коли обчислюється множина, поміщена на осі

ROWS. Це обчислення виконується незалежно від обчислення множини, поміщеної на осі
COLUMNS. У прикладі безліч осі ROWS посилається тільки на вимір Магазин, а не на
вимір Час. Так що вимір Час представлений елементом за замовчуванням All . Значення
елемента All – непусте й для РФ, і для Молдови. Тому кортежі для РФ і Молдови не
видаляються з множини після застосування функції NonEmpty. Але коли обчислюються
фактичні значення комірок, вони обчислюються для перетинання осей COLUMNS і
ROWS. Таким чином, що поточна координата виміру Час дорівнює 2009 р. (де не існує
даних для РФ і Молдови), і тому виходять невизначені значення.
Оператор NON EMPTY бере до уваги кортежі всіх осей. Тому результати
обчислюються в контексті 2009 р., у якому немає даних для РФ і Молдови. Тому NON
EMPTY видаляє кортежі для РФ і Молдови з результатів.

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

1. У чому відмінності синтаксису при визначенні функцій як методів і як
властивостей?
2. Перелічите відомі Вам функції навігації по ієрархіях вимірів.
3. У чому відмінність між функціями AllMembers і Members?
4. У чому відмінність між функціями Children і Descendants?
5. Які параметри передаються функції Filter?
6. Як речення WHERE впливає на обчислення вираження критерію й на результат?
7. У чому відмінність між опціями BDESC і DESC у функції Order?
8. Що таке режим відсутності члена?
9. Є чи розходження між оператором NON EMPTY і функцією NonEmpty?
 Методичні вказівки до лекції: [3, с. 181–186]; [8, с. 105–113].

Вправи
1. Одержати результати запитів до куба, створеного у вправі 5 лекції №10.
Продемонструвати наступні можливості MDX (для кожного випадку окремий запит):
1) застосування функцій для навігації в ієрархіях;
2) застосування функції fіlter;
3) застосування функції order.
При необхідності відредагувати дані в СД, щоб мати можливість побачити
результати запитів.
 Змістовний модуль 6
Проблеми побудови СД
ЛЕКЦІЯ №15
Ключові показники ефективності

Розглядаються наступні питання:

· поняття ключових показників ефективності (KPI);
· способи визначення ключових показників ефективності;
· види KPI;
· правила для визначення KPI.

Ключові показники ефективності (KPI, Key Performance Indicator) є частиною

системи сбалансованих показників (Balanced Scorecard – BSC), у якій установлюються
причинно-наслідкові зв'язки між цілями й показниками для того, щоб бачити
закономірності й взаємні фактори впливу в бізнесі – залежності одних показників
(результатів діяльності) від інших.
Проектування інформаційно-аналітичних систем на основі BSC починається із
проектування карти стратегії – її графічного опису у вигляді набору причинно-
наслідкових зв'язків. Для кожної перспективи (фінанси, маркетинг, технології, інновації)
повинні бути визначені стратегічні цілі й побудовано дерево цілей.
Для торгівельної організації основною стратегічною метою може бути збільшення
обсягу реалізації товарів. Це – фінансова перспектива. Досягнення цієї мети лежить в
області маркетингу. Наприклад, для досягнення цієї мети компанія може вибрати два
шляхи: розширення клієнтської бази й утримання «старих» клієнтів. Перше може бути
досягнуто, за рахунок розширення географії збуту. Для цього компанія може
сформулювати організаційне завдання розвитку мережі представництв. Це завдання
відноситься до внутрішньої технології розвитку компанії й відображає організаційно-
технологічну перспективу.
Клієнтська база може бути розширена не тільки за рахунок виходу на нові
регіональні ринки, але й за рахунок неохоплених сегментів ринку комплексних замовлень.
Орієнтація на великих комплексних замовників може зажадати поліпшення керування
ланцюжками поставок, що являє собою ще одну цільову настанову для перспективи
розвитку технологій. Сама по собі організація гнучких ланцюжків поставок неможлива
без розвитку партнерських відносин з постачальниками, перевізниками, кредитними й
страховими компаніями. Пошук таких партнерів і розробка ланцюжків являють собою
інноваційну діяльність торгівельної організації, а відповідні цілі відносяться до
перспективи інновацій.
Росту обсягів реалізації сприяє втримання «старих» клієнтів, однак відносно складно
двічі продати той самий товар, якщо це товар тривалого користування, тому для «старих»
клієнтів необхідне розширення асортиментів. Торгівельна організація буде вести
постійний пошук, що нового можна запропонувати «старим» клієнтам – здатність гнучко
реагувати на потенційний попит є однією із цілей інновацій. У технологічній перспективі
втримання «старих» клієнтів може бути підтримане за рахунок підвищення ефективності
взаємодії підрозділів компанії. Якщо якийсь підрозділ знайшов клієнта по своєму
товарному профілі, то, можливо, і інший підрозділ може також щось йому запропонувати
зі свого асортименту.
Наступний етап проектування інформаційно-аналітичної системи – визначення
«ключових показників ефективності», чисельних характеристик обраних цілей (метрик,
які необхідно збирати в сховище даних).
Найбільше просто оцінити досягнення фінансових цілей, наприклад, обсяг продажів
у грошовому вираженні. Ефективність досягнення цієї мети оцінюється також просто
шляхом порівняння фактичних значень із цільовими. Досягнення цілей маркетингу
оцінити трохи складніше. Для розширення клієнтської бази ключовим показником можна
вибрати кількість нових клієнтів за певний період (місяць, рік) і з порівняння цього
показника із цільовим значенням буде ясно, чи досягається ця мета чи ні. Ступінь
утримання «старих» клієнтів можна оцінювати по їхній частці в загальному числі клієнтів.
Установивши поріг, наприклад, в 50% для цього показника, можна відслідковувати,
наскільки великі втрати «старих» клієнтів.
Найбільше складно оцінити ефективність внутрішніх технологічних процесів
компанії, але й вони піддаються виміру. Наприклад, ефективність взаємодії підрозділів
може бути оцінена по середній кількості підрозділів, що беруть участь в обслуговуванні
одного клієнта. Розвиток мережі представництв зручно оцінювати по росту кількості
представництв у кожному регіоні. Ступінь поліпшення керування ланцюжками поставок
можна побачити по такому індикаторі, як частка угод, у яких такі ланцюжки були
використані.
Для перспективи інновацій також повинні бути визначені KPI. Наприклад, щоб
розширення асортиментів пропонованих товарів не стало самоціллю, потрібно
відслідковувати не поповнення списку найменувань товарів, а частку проданих одиниць
нових товарів. Ефективність розширення партнерських відносин також краще оцінювати
за допомогою відносної величини, що характеризує частку угод за участю партнерів.
Таким чином, KPI – система оцінки, що допомагає організації визначити досягнення
стратегічних і тактичних (операційних) цілей. Використання ключових показників
ефективності дає організації можливість оцінити свій стан і допомогти в оцінці реалізації
стратегії. KPI дозволяють виконувати контроль ділової активності співробітників і
компанії в цілому в реальному часі.
Часто компанії не можуть правильно визначити ключові показники ефективності
тому, що в них відсутній чіткий поділ процесів на основні, тобто стратегічні, і другорядні.
У результаті, стає досить проблематично виділити ключові показники з повного набору
показників ефективності. Як наслідок, відбувається моніторинг не настільки значимих
показників, виконується істотний обсяг роботи, що не приводить до яких-небудь певних
результатів.

Способи визначення ключових показників ефективності:

· дослідження;
· карти стратегії;
· інформація з карт;
· групові опитування;
· обговорення способів визначення KPI;
· аналіз фактичних бізнес-процесів;
· індивідуальні потреби співробітників;
· перегляд існуючих систем звітності;
· аналіз корпоративних задач.

Щодо використання KPI можна відзначити наступне:

- автоматизація розрахунків зменшує помилки ручного обчислення. Чим менше
помилок у розрахунках, тим менше помилкових рішень;
- KPI – це не набір цифр; часто люблять дивитися на кілька аркушів цифр і даних,
але це скоріше допоміжна статистика, тому що самих KPI не буває багато, має сенс
розділити поняття KPI і допоміжної статистики;
- KPI не відповідають на запитання “Чому?”, а тільки сигналізує, що проблема є, але
для одержання причин потрібно аналізувати допоміжну статистику;
- визначені мету й період; одна із ключових вимог KPI – можливість прогнозування
цілей;
 - KPI статистично стабільний, на тривалих періодах на графіку значень показника
можна чітко побачити тренд, а не набір «хаотичних» рухів.

При розрахунку KPI необхідно опиратися на дані, які повинні бути достовірними,
актуальними, об'єднаними, загальними й надавати можливість історичного аналізу; саме
такі дані й утримуються в СД. По суті, KPI задають состав даних у сховищі.
При розрахунку більшості показників використовуються підсумки даних, які
перебувають у СД, і доступ до яких є у всіх співробітників – для цього досить
спеціалізованого інтерфейсу.

Ключові показники ефективності можна розділити на наступні види:

· запізнілі — відбивають результати діяльності після закінчення періоду;
· випереджальні — дають можливість управляти ситуацією в межах звітного
періоду з метою досягнення заданих результатів по його завершенні.
Варто розрізняти KPI верхнього й нижнього рівня. У СД повинна втримуватися як
інформація для стратегічного керування, так і детальні дані, на основі яких ця інформація
була отримана, щоб забезпечити можливість переходу від стратегічних цілей до
фактичних даних, які знаходяться за цими цілями. Такий перехід (drill-down – спуск за
даними) в інформаційно-аналітичній системі реалізується за допомогою OLAP-
інструментів, що реалізують багатомірне (і одночасно багаторівневе) представлення
даних.
В Microsoft SQL Server Analysis Services 2005 поняття KPI точно описується
наступними чотирма кроками:
· значення, що повинне бути отримане: фізична міра, така, як Sales, міра, що
обчислюється, така, як Profit, або обчислення, що було визначено безпосередньо в KPI;
· цільове значення: значення (або вираження MDX, що видає значення), що
визначає мету для міри;
· статус: вираження MDX для оцінки поточного статусу значення у вигляді
нормалізованого значення в діапазоні від -1 (дуже погано) до +1 (дуже добре);
· тенденція: вираження MDX для оцінки поточної тенденції значення. Чи стає
значення краще або гірше щодо цільового значення?

Експертами TDWI виділені наступні правила для визначення ключових

показників ефективності:
1. KPI повинні вимірятися по одній схемі.
Наприклад, компанія може виробити єдині стандарти для системи премій, розподілу
заробітної плати. Ці стандарти можуть бути убудовані в застосування планування для
того, щоб всі співробітники компанії могли працювати, опираючись на них.
2. KPI повинні ґрунтуватися на достовірних даних.
Навіть правильно розроблені ключові показники не будуть виконувати свої функції,
якщо немає даних, необхідних для їхнього визначення. Керівництво компаній часто
помилково думає, що в СД є вся інформація, необхідна для використання того або іншого
показника. Для рішення даної проблеми буде потрібно залучення системного аналітика,
що зможе встановити всі джерела даних, використовувані для роботи із ключовими
показниками. Якщо дані відсутні або вони ненадійні, то керівництво компанії повинне або
створити систему збору даних, або переглянути розроблені показники ефективності, щоб
вони опиралися на існуючі дані.
3. KPI повинні бути зрозумілі й прості у використанні.
Якщо користувач не зможе запам'ятати й зрозуміти показники ефективності, то він
не зможе з ними працювати. Тому важливим є навчання персоналу. Варто обмежити
кількість показників. У ході дослідження було встановлено, що в середньому в компаніях
використовується 64 показника, користувач же працює лише з 16. Разом з тим більша
частина організацій використовує менш 20 показників, а для кожного конкретного
користувача визначено 7 показників для моніторингу.
4. KPI забезпечують додаткову інформацію.
KPI відображають припустимий поріг значень показників і стратегічні задачі
компанії, які можна представити декількома способами.
Граничні значення показників ефективності відображають гранично припустимі
результати параметрів.
Задачі відображають планований результат на певний час.
Галузеві показники – надають можливість порівняння фактичних результатів із
зовнішніми стандартними показниками (показниками по галузях, статистичними даними
або показниками прямих конкурентів).
Не кожний показник, використовуваний у ВРМ-системі (BusinessProcessManagement,
керування бизнес-процесами), обов'язково є KPI, це може бути й загальний показник.
Основне розходження між ними полягає в тім, що в загальних показників немає
асоційованих з ними стратегічних задач.
5. У результаті використання технології KPI уживають ефективні дії.
Основною характеристикою використання KPI, безсумнівно повинен бути
позитивний результат, що досягається. Однак на практиці справа не завжди є саме такою.
Сам по собі, KPI не змінить поточний результат і не почне приносити дохід, тому що це
всього лише один з інструментів, за допомогою яких співробітники компанії можуть
сприяти досягненню намічених стратегічних цілей і, в остаточному підсумку, просуватися
по службі.
Відповідно до результатів дослідження, більшість компаній випробовує проблеми з
визначенням тих ключових показників ефективності, які позитивно впливають на роботу
співробітників. Одна із причин подібних складностей полягає в тім, що найчастіше,
співробітники з ліні або з якихось особистих міркувань намагаються обійти цю систему.
Крім того, іноді KPI можуть суперечити один одному, створюючи додаткові складності
для компанії.
6. Завдяки використанню системи KPI співробітники одержують додаткові
повноваження.
Не було б ніякого змісту у введенні системи ключових показників ефективності,
якби користувачі не могли вживати ніяких дій на основі її результатів. Більшість експертів
не рекомендують прив'язувати систему заохочень до системи ключових показників, тому
що спочатку необхідно переконатися в тім, що використання KPI не приведе ні до яких
негативних наслідків.
Крім того, як показало дослідження, зміни в структурі бізнес-процесів відбувалися в
основному до впровадження системи KPI (40% опитаних) і у два рази рідше після (19%
опитаних). При цьому 25% респондентів відзначили, що зміни не відбувалися взагалі (при
15% невпевнених).
7. KPI повинні зберігати свою релевантність.
Після впровадження системи KPI необхідно постійно перевіряти, чи продовжує вона
ефективно виконувати свою роботу, тому що використання деяких ключових показників
може привести до незапланованих результатів, інші показники можуть згодом втратити
свою актуальність.
Основними причинами перегляду показників є зміни в корпоративній стратегії (77%
опитаних) і підвищення актуальності показників (65% опитаних). Далі слідує необхідність
впровадження показників у роботу нових груп або підрозділів (44% опитаних) і розробка
більш простого й зручного інтерфейсу (19% опитаних).
Визначення коефіцієнтів KPI зажадає певного часу й навичок, які з'являться, як
правило, методом проб і помилок.
 Питання для самоперевірки
1. Для чого використовуються ключові показники ефективності?
2. Назвіть способи визначення ключових показників ефективності.
3. Визначите види ключових показників ефективності.
4. Перелічите правила для ключових показників ефективності.

Методичні вказівки до лекції: [3, с. 302–311].

Вправи
1. Назвіть можливі ключові показники ефективності для предметної області «Біржа
праці».
2. Назвіть можливі ключові показники ефективності для предметної області
«Провайдер мобільного зв'язку».
 СПИСОК ЛІТЕРАТУРИ

1. Архипенков С., Голубев Д., Максименко О. Хранилища данных. От концепции до

внедрения. - М.: Диалог-МИФИ, 2002. - 528 с.
2. Барсегян А.А., Куприянов М.С., Степаненко В.В., Холод И.И. Методы и модели
анализа данных: OLAP и Data Mining – СПб.: БХВ-Петербург, 2004. – 336 с.: ил.
3. Бергер А., Горбач И., Меломед Э., Щербинин В., Степаненко В. Microsoft SQL Server
2005 Analysis Services. OLAP и многомерный анализ данных. – СПб.: БХВ-Петербург,
2007. – 928 с.
4. Дейт, К. Дж. Введение в системы баз данных, 7-е издание: Пер. с англ./ К.Дж. Дейт. –
М. : Издательский дом «Вильямс», 2001. – 1072 с.
5. Коннолли, Т. Базы данных: Проектирование, реализация, сопровождение. Теория и
практика / Т. Коннолли, К. Бегг, А.Страчан. – М. : Издательский дом «Вильямс», 2001. –
1120 с.
6. Паклин Н.Б., Орешков В.И. Бизнес-аналитика: от данных к знаниям (+ СD): учеб.
пособие. — 2-е изд., перераб. и доп.— СПб.: Питер, 2010. — 704 с.: ил.
7. Спирли Э. Корпоративные хранилища данных. Планирование, разработка и
реализация. Т.1. – М.: Изд. дом Вильямс, 2001. – 400 с.
8. Харинатх С., Куинн С. SQL Server Analysis Services 2005 и MDX для профессионалов.–
М.: Издательство: Диалектика, 2008. – 848 с.
9. Хрусталёв Е.М. Агрегация данных в OLAP-кубах. – http://www.olap.ru/home/mut.asp
10. Федоров А., Елманова Н. Введение в OLAP-технологии MICROSOFT. – М.: Диалог-
Мифи, 2002. – 268 с.
11. КоломиецС., Кореневич В. Структура работ по созданию решения на базе технологий
DWH (Data WareHousing). – http://www.dwh-club.ru/node/16
 ЗМІСТ

ВСТУП ......................................................................................................................................5
Семестровий модуль 1 Змістовний модуль 1 Системи підтримки ухвалення рішення.........6
ЛЕКЦІЯ №1 Введення в бізнес-інтелект ................................................................................6
ЛЕКЦІЯ №2 Поняття сховища даних ...................................................................................10
Змістовний модуль 2 OLAP-системи .....................................................................................15
ЛЕКЦІЯ №3 Аналітичні (OLAP) системи .............................................................................15
ЛЕКЦІЯ №4 Архітектура сховища даних.............................................................................25
Змістовний модуль 3 Багатомірні куби..................................................................................31
Лекція №5 Багатомірний куб. Основні поняття ...................................................................31
ЛЕКЦІЯ №6 Ієрархії вимірів. Схеми кубу «зірка» та «сніжинка».......................................34
ЛЕКЦІЯ №7 Агрегація даних у багатомірному кубі ...........................................................40
ЛЕКЦІЯ №8 Агреговані значення для різних видів вимірів.................................................44
Семестровий модуль 2 Змістовний модуль 4 Підготовка даних для СД..............................54
ЛЕКЦІЯ №9 Витяг, перетворення й завантаження даних....................................................54
ЛЕКЦІЯ №10 Очищення даних.............................................................................................58
ЛЕКЦІЯ №11 Очищення даних (продовження) ...................................................................62
Змістовний модуль 5 Мова багатомірних виражень MDХ ...................................................68
ЛЕКЦІЯ №12 Мова багатомірних виражень MDX. Основні поняття .................................68
ЛЕКЦІЯ №13 Мова багатомірних виражень MDX. Запит до кубу......................................73
ЛЕКЦІЯ №14 Функції мови багатомірних виражень MDX.................................................81
Змістовний модуль 6 Проблеми побудови СД ......................................................................89
ЛЕКЦІЯ №15 Ключові показники ефективності..................................................................89
СПИСОК ЛІТЕРАТУРИ.........................................................................................................94