Самостійна робота №10 огляд концепцій зберігання інформації

Література: Шквір В.Д., Загородній А.Г., Височан О.С. Інформаційні системи і технології в обліку: Навч. посіб.- 3-тє вид., перероб. і доп. – К.: Знання, 2007. ст.104-110.

Різновидом баз даних є сховище даних (Data Waren House DW). Появу DW обумовили такі фактори:

• Поява систем підтримки прийняття рішень, основаних OLAP-технології (реалізації аналітичних запитів).

• СППР почали конфліктувати з трансакційними системами оперативної обробки даних (OLTP-системами), що призвели до нестачі ресурсів.

• Формування аналітичних звітів на основі традиційних БД займає багато часу, що призвело до того, що менеджери не встгали готувати відповідні рішення на основі отриманих аналітичних звітів.

• В організаціях часто функціонувало декілька OLTP-систем з окремими БД, що унеможливлювало побудову зведеного аналітичного запиту на основі декількох баз даних без попередньої узгодженості даних у різних базах.

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

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

Предметна орієнтація

• дані в DW організовані відповідно до основних напрямів діяльності підприємства чи фірми (дебіторська заборгованість, замовники, склад тощо), а не до процесів (відвантаження товарів, виписання рахунків тощо), як у БД;

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

Інтегрованість. Первинні дані оперативних баз даних перевіряють, певним чином добирають, зводять до одного вигляду, необхідною мірою агрегують і завантажують у DW. Наприклад, оцінка змінних величин може бути лише в метрах, формат подання дат — PPMMDD, структура розшифровки для статі людини — ч/ж тощо.

Підтримка хронології (варіантність у часі)

•В операційному середовищі:

— інформація є точною на момент її введення;

— часовий горизонт або не існує, або є коротким, напри­клад, 60—90 днів;

— ключ може і не містити елемент часу.

• DW нагромаджує дані у вигляді "історичних пластів":

— історичні дані, наприклад, 5—10 років;

— ключ містить елемент часу.

Незмінність

— після вводу інформації до DW вона не підлягає оновленню (на відміну від оперативних даних БД, які можуть часто змінюватись);

— історична інформація в DW є незмінною. Її можна лише первинно завантажити, шукати та читати.

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

Наведемо деякі характеристики даних у DW:

— таблиці дуже великі (деякі в терабайтах);

— розмірні дані є незалежними в об'єктах (розмірностях);

— основний тип доступу — це незапланований (порівняної з обумовленим наперед у БД) — запити, звіти, оператори OLAР;

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

— доступ до даних здійснюється здебільшого у режимі лише для читання";

— дані потрібно періодично поновлювати з численних джерел;

— більшість зібраних даних є архівними (тобто залежать від часу).

У табл. 4.3 наведено відмінності між операційними базами; даних та сховищами даних.

Оскільки існують суттєві відмінності між БД та DW, то при­родно, що і проектування DW здійснюється за своїми алгоритмами. Загалом, процес проектування сховищ даних складається з таких етапів:

Етап 1. Проаналізуйте бізнес-процеси, які генерують дані, та інформаційні потреби організації.

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

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

Етап 3. Визначте структуру кожної таблиці фактичних даних. Наприклад, запишіть щоденні обсяги реалізації марок товарів в окремих магазинах.

Етап 4. Визначення для кожної таблиці фактичних даних:

• якими є розмірності (об'єкти) та точно з'ясуйте поля для кожної розмірності;

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

Етап 5. Прийміть рішення, чи нормалізувати схему типу „зірка”, чи ні?

Етап 6. Прийміть рішення, як часто потрібно відбирати ТІ завантажувати дані в DW? Наприклад, щогодини, щодня, тре тижня тощо.

Спроектоване сховище необхідно заповнити даними. Для цього використовуються інструменти ETL (Extract Transform Load), призначені для відбору, перетворення (трансформації) та завантаження даних.

ETL є інтегрованим набором програмних інструментів, які підтримують такий процес (ETL):

— відбір даних з джерел операційних даних (баз даних); ,

— транспортування їх до цільового середовища (DW);

— очищення даних (фільтрація);

— перетворення (трансформація) даних;

— завантаження очищених та трансформованих даних до DW.

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

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

— базах даних, наприклад, ORACLE, SQL Server;

— системах ERP;

— ієрархічних системах, наприклад, Adabas, IMS, dBASЕ, IDMS, Focus тощо;

— плоских файлах, наприклад, ASC II files, VSAM, ISAМ тощо;

— даних на рівні Web.

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

Під час транспортування даних потрібно визначити:

— цільове середовище, тобто чи потрібно направляти відібрані дані просто до DW, чи їх зберігати в деякій БД для "повідомлення";

— як транспортувати дані. Деякі з джерел даних є віддаленими і їх потрібно перенести у мережу. Крім цього, необхідно визначити, чи завантажувати дані до DW із застосуванням звичайних методів або спеціальних інструментів завантаження.

При очищенні (фільтрації) даних, відібраних з джерел (БД), необхідно знайти і виправити:

• дублювання даних;

• зрізаний текст (наприклад, назва вулиці не вміщується у поле);

• орфографічні помилки;

• скорочення (наприклад, M.S. або MS).

На цьому етапі заповнення DW виникає проблема злиття-видалення (merge-purge). Наприклад, Алекс Тужілін і Олександр Тужіліу.

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

• різне кодування одних і тих же даних;

• різні умовні назви;

• оперативні дані містять окремі торговельні операції, а нам у таблицю фактів потрібні підсумки щоденного продажу за марками товарів за кожним магазином.

Зазначимо, що часто трансформацію виконують за допомогою SQL-запитів.

На останньому етапі потрібно завантажити очищені та трансформовані дані до DW. Етапи очищення і/або трансформації можна об'єднати з етапом завантаження. Під час завантаження даних до DW потрібні спеціальні утиліти завантажен­ня, оскільки існують величезні обсяги даних.

Засоби ETL розроблені для спрощення та упорядкування процесу ETL шляхом забезпечення user-friendly (дружнього до користувача) програмного забезпечення, що допомагає розробникам DW виконувати етапи завантаження. Є багато постачальників ETL. Інформація про них розміщена на www/dwinfocenter.org/ clean.html

Деякі компанії DW мають свої власні засоби ETL (наприклад Oracle, IBM, Sybase).

Фізична організація DW. Чітко розрізняють два підходи:

1) дані можна зберігати винятково у реляційних таблицях (ROLAP);

2) таблиці факторів можна організувати як багатомірний куб (MOLAP) і цей куб може бути зв'язаний з таблицями вимірів через індекси.

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

У ROLAP-системах гіперкуб є віртуальним — це лише користувацький інтерфейс, який моделюється на традиційній реляційній базі даних. Дані в сховищі подаються у вигляді моделі, що отримала назву "зірка" (star schema). Ця модель складається з таблиць двох типів: однієї таблиці даних, що аналізуються, тобто фактів (fact table) — центр зірки і декількох таблиць, які характеризують певні виміри цих факв (demension table). Таблиця фактів вміщує числові характеристики якогось напряму діяльності компанії чи фірми, наприклад, обсяги продажу, а також ключі таблиць вимірів (наприклад, назва товару і його виробника, тип товару тощо). Дані таблиць вимірів денормалізовані. Якщо ж таблиці вимірів нормалізовані, то така модель називається "сніжинкою" (snow flake schema). У ROLAP-системах зберігаються агреговані дані.

Переваги ROLAP-систем:

— підтримує відкриті стандарти SQL;

— мінімізує вимоги до навчання і підтримки;

— підходить для простого аналізу великих обсягів даних.

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

Переваги MOLAP-систем:

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

• запити й огляди (drowsing) у MOLAP у середньому використовуються краще, ніж у ROLAP.

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

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

Реалізація проекту DW для бізнесу збільшує конкурентоспроможність шляхом:

• зменшення витрат:

а) раціональні витрати на прийняття рішень;

б) покращується управління активами (зобов'язаннями);

• збільшення прибутків і лояльності клієнтів за рахунок кращого знання клієнтів;

• визначення нових можливостей бізнесу і проблем через краще знання бізнесу.