Основним завданням будь-якої корпоративної інформаційної системи є оперативне забезпечення достовірною інформацією управлінського персоналу для прийняття оптимальних рішень. Це завдання значно полегшується, якщо КІС базується на використанні сховища даних. Корпоративне сховище даних є серцевиною сучасних КІС, і від того, як воно побудоване, залежить ефективність роботи всієї системи.
У сховищі акумулюється інформація з різних джерел, що характеризують бізнесову діяльність корпорації, яка зберігається у вигляді, що забезпечує практичні потреби користувача. Оперативне аналітичне оброблення даних за допомогою технології OLAP дозволяє аналітикам, менеджерам і управлінцям сформувати власне бачення даних, використовуючи швидкий, одноманітний, оперативний доступ до різноманітних форм подання інформації.
Перш ніж перейти до характеристики архітектурних рівнів сховища даних, спинімося на технології комплексного багатовимірного аналізу даних, що дістала назву OLAP (On-Line Analytical Processing). OLAP — це головний компо-
нент організації сховищ даних (Data Warehousing), тобто збирання, очищення й попереднього оброблення даних з метою надання результативної інформації користувачам для оперативного аналізу та складання звітів. Концепцію OLAP сформулював і описав 1993 року Е. Ф. Кодд, відомий дослідник баз даних і автор реляційної моделі даних.
У 1993 році Е. Ф. Кодд із партнерами опублікували статтю «Забезпечення OLAP для користувачів-аналітиків», де описали 12 правил OLAP. Пізніше (1995-го) до них було долучено іще шість правил. Ці правила Е. Ф. Кодд розбив об’єднав у групи, назвавши їх особливостями, які ми розглянемо далі.
1. Багатовимірне концептуальне подання даних (правило 1). Це оригінальне правило є серцевиною OLAP.
2. Інтуїтивне маніпулювання даними (правило 10). Це означає, що маніпулювання даними має здійснюватися безпосередніми діями над комірками в режимі перегляду без застосування меню і численних операцій. Нині таким інструментом є використання мишки чи інших подібних пристроїв.
3. Доступність (правило 3). У цьому правилі Е. Ф. Кодд особливо наголошує роль OLAP як посередника (шару) між гетерогенними джерелами даних і поданням їх кінцевому користувачеві.
4. Пакетне вилучення замість інтерпретації (нове правило із 1995 року). Це правило вимагає, щоби програмний продукт однаковою мірою ефективно забезпечував доступ як до власного сховища даних, так і до зовнішніх даних. Зауважимо, що Е. Ф. Кодд наполягав на багатовимірному поданні даних із частковими попередніми обчисленнями для великих багатовимірних баз даних у такий спосіб, щоб будь-які детальні дані були прозорі й доступні. Сьогодні цьому визначенню відповідають гібридні OLAP, які стають найпопулярнішими, що підтверджує далекоглядність Е. Ф. Кодда.
5. Моделі аналізу OLAP (нове правило). Згідно з цим правилом доктор Кодд вимагає, щоб OLAP-продукти підтримували всі чотири моделі аналізу, які він описує у своїй статті (категоріальний, тлумачний, абстрактний і стереотипний). Ідеться, відповідно, про формування параметрично налаштовуваних звітів, розрізів і групувань з обертанням, аналізом у стилі «що, якщо» і моделями пошуку цілей. Як правило, всі сучасні OLAP інструментальні засоби підтримують перші дві моделі аналізу, більшість із них — третю (певною мірою) і лише деякі — четверту модель в окремих корисних розширеннях. Можливо, у цьому правилі Е. Ф. Кодд передбачав системи добування даних (data mining), які ще називають моделями пошуку цілей.
6. Архітектура «клієнт-сервер» (правило 5). Це правило вимагає, щоб програмний продукт був не лише клієнт-серверним, а й щоб серверний був достатньо інтелектуальним аби різні користувачі могли підключатися з мінімумом зусиль і навичок програмування. Це правило диктує жорстку архітектуру. Але в теперішній час клієнт-серверна архітектура поступово витісняється Web-серверною, про яку Е. Ф. Кодд не згадував.
7. Прозорість (правило 2). Цілковита відповідність цьому правилу означає, що користувач електронної таблиці здатен отримувати всі необхідні дані з OLAP-системи, не підозрюючи навіть, звідки вони беруться. Щоб виконувати
це правило, програмний продукт має забезпечувати безпосередній доступ до гетерогенних джерел даних і одночасно мати вбудовану повнофункціональну електронну таблицю. Це правило висуває жорсткі вимоги до OLAP-систем, які в більшості продуктів не мають цілковитої підтримки, тобто не підтримують безпосереднього прозорого доступу до зовнішніх даних. Більшість програмних продуктів не надають або доступу до електронних таблиць, або безпосереднього доступу до гетерогенних джерел.
8. Багатокористувацька підтримка (правило 8). Це правило вказує на стратегічну спрямованість розвитку OLAP. Інструменти OLAP мають забезпечити одночасне читання і запис даних, їх інтеграцію та конфіденційність. Але й досі багато прикладень OLAP працюють лише в режимі читання.
9. Оброблення ненормалізованих даних (нове правило). Правило вказує на необхідність інтеграції між OLAP-системою і ненормалізованими джерелами даних. Згідно з цим правилом Е. Ф. Кодда модифікації даних, виконувані в середовищі OLAP, не мають приводити до змін даних, що зберігаються у вихідних зовнішніх системах.
10. Збереження результатів OLAP: зберігання їх окремо від вихідних даних (нове правило). У цьому правилі Е. Ф. Кодд дотримується поширеної думки про те, що OLAP-додатки, що працюють в режимі читання-запису, не мають безпосередньо впливати на оброблювані дані, а дані, модифіковані в OLAP, мають зберігатися окремо від даних транзакцій. Удалою реалізацією цього правила є метод зворотного запису даних, що використовується в Microsoft OLAP Services, який дозволяє зберігати дані, змінені в середовищі OLAP, окремо від основних даних.
11. Вилучення значень, яких немає (нове правило). Усі значення, яких немає, вилучаються з визначеної версією 2 реляційної моделі даних, тобто значення, яких немає, повинні відрізнятися від нульових. Це правило має рацію лише в плані компактності зберігання даних, утім деякі сучасні OLAP-інструменти ігнорують це правило без особливих втрат у функціональності.
12. Оброблення значень, яких немає (нове правило). Усі значення, яких немає, будуть ігноруватися OLAP-аналізатором без урахування їхнього джерела. Ця особливість пов’язана з попереднім правилом і є природним наслідком того, як OLAP-система обробляє всі дані.
Третя група правил (особливості подання звітів)
13. Гнучкість формування звітів (правило 11). Правило вимагає, щоб показники могли бути розміщені у звіті так, як це потрібно користувачу. Більшість сучасних програмних продуктів можуть це забезпечити у своїх засобах формування звітів, але не всі здатні забезпечити цю гнучкість в інтерактивному режимі під час перегляду. Для цього необхідно, щоб засоби аналізу й можливості формування звітів були комбіновані в одному програмному модулі.
14. Стандартна продуктивність звітів (правило 4). У цьому правилі Е. Ф. Кодд вимагає, щоби продуктивність формування звітів істотно не зменшувалася зі зростанням кількості вимірів і розмірів бази даних. Зауважимо, що з приводу цієї особливості між програмними продуктами існують серйозні відмінності, однак принциповим чинником впливу на продуктивність є кількість виконува-
них обчислень і те, де вони виконуються (на машині клієнта, на сервері багатовимірної бази даних чи в реляційній СУБД). Досвід показує, що просте збільшення кількості вимірів або розмірів БД істотно не впливає на продуктивність у базах даних із повним попереднім обчисленням, що й мав на увазі Е. Ф. Кодд у своєму твердженні. Але звіти з великою місткістю обчислювальних показників формуються довше. Продуктивність практично лінійно залежить від кількості використовуваних під час формування звіту комірок, яких може бути значно більше, ніж тих, що з’являються в кінцевому звіті. Деякі розміщення вимірів у звіті можуть бути повільнішими за інші, оскільки потребують більшої кількості операцій зчитування з диска.
15. Автоматичне налаштування фізичного рівня (правило 7). Правило вимагає, щоб OLAP-система автоматично налаштовувала свою фізичну схему залежно від типу моделі, обсягів даних і розрядності бази даних. Ніхто не заперечує це твердження, але більшість постачальників OLAP-систем надто далекі від цього ідеалу. ???????? ????? ?????? (?????????? ????????)
16. Універсальність вимірів (правило 6). Е. Ф. Кодд наполягає на тому, що всі виміри мають бути рівноправними, кожнн вимір повинен бути еквівалентним і в структурі, і в операційних можливостях. Щоправда, він не заперечує проти додаткових операційних можливостей для окремих вимірів (як правило, часових), але наполягає, щоб такі додаткові функції могли бути надані будьякому виміру. Дослідник також категорично виступає проти того, щоби базові структури даних, обчислювальні або звітні формати були більшою мірою притаманні якомусь одному виміру. Досвід експлуатації OLAP-систем довів, що це найсуперечливіше правило з усіх 12-ти початкових правил. Якщо технологія орієнтує програмний продукт на відповідність цьому правилу, то постачальники відповідних продуктів підтримують його. Якщо прикладне застосування зорієнтовує продукт не докладати зусиль на його дотримання, то постачальники програм ігнорують його. На практиці вироблено такий стереотип. Якщо OLAPсистема потрібна для універсальних цілей, для множинних досліджень, то це правило треба враховувати, а якщо продукт передбачено для специфічного використання, його можна ігнорувати.
17. Необмежена кількість вимірів і рівнів агрегації (правило 12). Слід сказати, що технічно неможливо реалізувати цю вимогу в повному розумінні необмеженості, оскільки не може бути необмеженого об’єкта на обмеженому комп’ютері. Принаймні небагато прикладних задач потребують більш як 8— 10 вимірів.
18. Необмежені операції між розмірностями (правило 9). Згідно із твердженням Е. Ф. Кодда всі види операцій мають бути дозволені для будь-яких вимірів, а не лише для вимірів типу «міра». Більшість сучасних продуктів із багатовимірною базою даних задовольняють цю вимогу. Але програмні продукти, що використовують реляційну структуру зберігання даних, слабкі в цій галузі. Цей тип операцій важливий, якщо OLAP потрібна для комплексних складних досліджень, а не лише для перехресної вибірки даних.
Названі вище правила доцільно використовувати при визначенні того, який програмний продукт правомірно відносити до категорії OLAP. Але пам’ятати й
використовувати 18 особливостей OLAP надто обтяжливо для більшості фахівців. Практика підказала, що можна описати OLAP-визначення п’ятьма головними словами — швидкий аналіз розподіленої багатовимірної інформації. Техніка реалізації OLAP охоплює кілька архітектур зберігання даних для цих цілей. На рис. 5.1 показано структуру корпоративного сховища даних. Можна бачити, первинні дані можна завантажити в спеціальну базу даних OLAP або залишити в реляційній чи змішаній базі.
БД1
БДn
Оперативні бази даних
Реляційне сховище
Змішане сховище OLAPсховище
АРМ користувача OLAPклієнт
Репозитарій
Екстракція і трансформація даних
Потоки даних (Data Flow)
Потоки метаданих (Meta Flow)
Рис. 5.1. Структура корпоративного сховища даних
Поряд із потоками даних існують потоки метаданих, які забезпечують взаємодію різних компонентів сховища й розміщуються в репозитарії. Репозитарій є центральною частиною сховища даних. Репозитарій метаданих дає змогу визначити семантичну структуру додатка у вигляді опису термінів предметної галузі, їх взаємозв’язки й атрибути. Терміни предметної галузі, визначеної в репозитарії метаданих, можуть бути використані для створення розділюваних розмірностей і структури довідників для визначення взаємодії між документами.
Крім того, завданням метаданих є відстежування змін у структурі моделі предметної галузі та забезпечення порівнювання даних, зібраних у різні періоди. Властивість метаданих відстежувати зміни структур даних і їх значення в часі називається контролем модифікацій (versioning).
Корпоративне сховище даних може функціонувати у трьох архітектурах — реляційній (ROLAP), багатовимірній (MOLAP) і гібридній, або змішаній (HOLAP).
У ROLAP-архітектурі (Relational OLAP) детальні дані перебувають у реляційній БД, агреговані дані (підсумкові) — там само у спеціально створених службових таблицях. Реляційні таблиці та зв’язки між ними генеруються автоматично. Частина таблиць створюється під час інсталяції системи (таблиці для
зберігання метаданих, таблиці обов’язкових реквізитів об’єктів, таблиці для зберігання залишків на рахунках бухгалтерського обліку), частина — під час опису логічної моделі даних (метаданих системи).
Підхід побудови ROLAP-архітектури (оперативного аналітичного оброблення реляційних даних) базується на посиланні, що дані не обов’язково мають зберігатися в багатовимірному вигляді для того, щоб потім їх можна було використати в багатовимірному аналізі. Виробники ROLAP, як правило, розподіляють головні функції системи OLAP між трьома логічними рівнями:
— масштабована паралельна реляційна база даних забезпечує зберігання і швидкий доступ до даних;
— середній рівень аналізу підтримує багатовимірне подання даних і розширені функціональні можливості, які недоступні на базовому реляційному сервері;
— рівень подання відповідає за донесення результатів до користувачів.
Переваги системи ROLAP полягають у повноті функціональних можливостей поряд з відкритістю, масштабованістю та продуктивністю, які є головними якостями реляційних баз даних провідних розробників.
На рис. 5.2 подано схему роботи зі сховищем даних у ROLAP-архітектурі. За такої архітектури на сервері створюється реляційне сховище, а на клієнтських машинах встановлюються інструментальні засоби оброблення запитів або механізм OLAP чи інші зовнішні системи.
Записи
Куби
Рис. 5.2. Архітектура реляційної OLAP
Реляційна архітектура забезпечує високу швидкість роботи зі сховищем, в якому зберігається значний обсяг інформації. За дуже великих обсягів даних продуктивність системи, побудованої на ROLAP-архітектурі, значно знижується. У цьому разі для забезпечення високої швидкості багатовимірного аналізу будують гібридну OLAP-архітектуру (НOLAP).
НOLAP-архітектура (Hybrid OLAP) — це спеціалізований механізм, який дає змогу зберігати дані у власних форматах, які являють собою масиви, що відповідають зручному для користувачів поданні даних у так званих ділових вимірах. Основною ознакою цієї архітектури є те, що детальні дані залишаються на відведеному для них місці — в реляційному сховищі, а агреговані (підсумкові) дані зберігаються в багатовимірній базі (Multidimensional OLAP
— MOLAP).
Висока швидкість оброблення запитів у багатовимірній базі даних забезпечується ефективним механізмом попереднього обчислення показників для задоволення запитів. Швидкість оброблення запитів значно підвищується за рахунок того, що можна отримати відповідь на запитання на підставі результатів попередніх обчислень, а не виконуючи їх «на льоту». Використання НOLAP-архітектури найефективніше в разі оброблення надто великих обсягів даних.
На рис. 5.3 зображено архітектуру гібридної OLAP.
Рис. 5.3. Архітектура гібридної OLAP
Згідно з рис. 5.3, у реляційному сховищі збираються первинні дані корпорації. OLAP-механізм реалізований на базі багатовимірної СУБД. Як багатовимірне сховище можуть використовуватися вітрини даних. У вітрини даних зі сховища буде періодично імпортуватися агрегована інформація з вузьких предметних галузей. Створювати вітрини даних і підключати їх до корпоративного сховища можна, наприклад, за допомогою сервісу MS Analysis Services, який входить до складу MS SQL Server, або за допомогою подібних OLAP-серверів інших виробників. У цій архітектурі OLAP-клієнт працюватиме не безпосередньо з реляційним сховищем, а з багатовимірною БД (МOLAP). Щоб забезпечити актуальний OLAP-аналіз, необхідно регулярно поповнювати вітрини даними сховища.
Кожна з цих архітектур має певні переваги й вади та має використовуватися залежно від наявних умов — обсягу даних, потужності реляційної СУБД, парку ЕОМ тощо.
Нещодавно OLAP-продукти підтримували або реляційне, або багатовимірне зберігання даних. На теперішній час, як правило, той самий продукт забезпечує обидва ці види зберігання даних.
Ми розглянули архітектури корпоративних сховищ даних у плані зберігання інформації у сховищі. Але мову можна вести про побудову функціональної архітектури корпоративного сховища даних. Функціональна архітектура в кожному конкретному випадку матиме свої особливості та залежатиме від діяльності фірми, від її бізнес-платформи, територіального розподілу тощо.
Як приклад наведемо загальну функціональну архітектуру корпоративного сховища даних з огляду на те, що в його складі мають бути такі блоки:
— сховище даних. Структура сховища має бути зорієнтована на зберігання бізнес-даних корпорації;
— клієнтська частина системи. Клієнтська частина може охоплювати різноманітні програмні засоби залежно від потреб користувача. Як приклад наведемо програми, що містять дизайнер сховища, засоби розроблення додатків, засоби адміністрування користувачів, інструменти аналізу даних, завантаження словника метаданих з XML-файла (eXtensible Markup Language) у сховище і вивантаження його зі сховища в XML-файл. Крім клієнтів системи можуть бути використані зовнішні OLAP-клієнти для аналізу даних;
— сервер обміну даними (Data Exchange Server). Це набір програм завантаження/вивантаження даних сховища й каталогів для організації обміну даними із зовнішніми OLТP-системами. Сервер забезпечує завантаження даних із XML-файлів відповідних форматів у сховище і вивантаження зі сховища в XML-файл;
— бібліотеки прикладних класів. Окрім загальновідомих бібліотек АРІ (Application Program Interface), які вбудовуються в ядра операційних систем для абстрагування прикладних програм від типів устаткування і низькорівневих протоколів обміну інформацією, використовуються додаткові бібліотеки, що постачаються з багатьма засобами оброблення з метою зменшення трудомісткості й термінів розроблення програм. Найпоширеніші бібліотеки прикладних класів такі: ACL (Application Class Library), VCL (Visual Components Library), Win Lite тощо. ACL — це об’єктна оболонка сховища даних, яка вміщує структуру реляційних таблиць і процедур SQL, що зберігаються. Вона реалізована мовою Python і використовується для оброблення XML-документів та інших функцій. Кожен клас забезпечує інтерфейс для окремого об’єкта між його XML-поданням і поданням об’єкта в БД.
У Delphi використовується дуже потужна і складна бібліотека VCL (Visual Components Library), яка окрім безпосередніх абстракцій уводить також велику кількість своїх функціональних класів. У цій бібліотеці є компоненти для візуального відображення інформації, роботи з базами даних, із системними об’єктами, компоненти для роботи з Internet тощо. Win Lite — це компактна бібліотека оконних класів. Вона є мінімальною за розміром і не містить вищих рівнів абстракції, ніж існують у Win32 API, але значно полегшує роботу під час переведення програмування в об’єктно-орієнтоване русло. Вона може бути використана разом з VCL-бібліотекою.
