Сховища даних і OLAP-технології
Різновидом баз даних є сховище даних (Data Waren House-DW). Появу DW обумовили такі фактори:
• Поява систем підтримки прийняття рішень, основаних на ОLАР-гехнології (реалізації аналітичних запитів).
• СППР почали конфліктувати з транзакційними системами оперативної обробки даних (ОLТР-системами), що призвело до нестачі ресурсів.
• Формування аналітичних звітів на основі традиційних БД займає багато часу, що призвело до невстигання готувати менеджерами відповідних рішень за основі отриманих аналітичних звітів.
• В організаціях часто функціонувало декілька ОLТР - систем з окремими БД, що унеможливлювало побудову зведеного аналітичного запиту на основі декількох баз даних без попередньої узгодженості даних у різних базах
Вирішення перерахованих проблем було знайдено в розробці концепції сховища даних (DW) - особливої форми організації бази даних, призначеної для вберігання в погодженому вигляді агрегованої інформації, що отримується на основі БД різних ОLТР - систем та зовнішніх джерел.
DW характеризуються предметною орієнтацією, інтегрованістю, підтримкою хронології, незмінністю і мінімальною надлишковістю.
Предметна орієнтація
• дані в DW організовані відповідно до основних напрямків діяльності підприємства чи фірми (дебіторська заборгованість, замовники, склад тощо),а не до процесів (відвантаження товару, виписання рахунків тощо) як у БД;
• застосування DW спрямовуються даними і організуються навколо тем (клієнт, постачальник тощо), тобто сховища орієнтовані на бізнес-поняття, а не на бізнес-процеси.
|
|
|
Інтегрованість. Первинні дані оперативних баз даних перевіряються, певним чином добираються, приводяться до одного вигляду, необхідною мірою агрегуються і завантажуються у DW. Наприклад, оцінка змінних величин може в метрах, формат подання дат- РРММDD, структура розшифровки для статі людини - ч/ж тощо.
Підтримка хронології (варіантність у часі):
Ÿ В операційному середовищі
- інформація є точною на момент її введення;
- часовий горизонт або не існує, або є коротким, наприклад 60 - 90 днів;
- ключ може і не містити елемент часу;
Ÿ DW нагромаджує дані у вигляді "історичних пластів"
-історичні дані, наприклад 5 - 10 років;
- ключ містить елемент часу.
Незмінність
Ÿ Після вводу інформації до DW вона не підлягає оновленню (на відміну від оперативних даних БД, які можуть часто змінюватись);
Ÿ Історична інформація в DW є незмінною. Її можна лише первинно завантажити, шукати та читати.
Мінімальна надлишковість. Зведення до мінімуму надлишковості даних забезпечується тим, що перш ніж завантажувати дані до сховищ, їх фільтрують і певним чином очищають від таких даних, які не потрібні і не можуть бути використані в ОLАР-системах.
|
|
|
Наведемо деякі характеристики даних в DW:
Ÿ таблиці дуже великі (деякі в терабайтах);
Ÿ розмірні дані є незалежними у об'єктах (розмірностях);
Ÿ основний тип доступу – це незапланований (порівняно з обумовленим наперед БД) - запити, звіти, оператори ОLАР;
Ÿ| порівняно велика кількість таблиць для доступу (наприклад, щонайменше одна для кожної розмірності та таблиця фактичних даних);
Ÿ доступ до даних здійснюється здебільшого у режимі "лише для читання";
Ÿ дані слід періодично поновлювати з численних джерел;
Ÿ більшість зібраних даних є архівними (тобто залежать від часу).
У Табл. 3. наведені відмінності між операційними базами даних та сховищами даних.
Таблиця 3.
Відмінності між БД та СД
| Операційні БД | Сховища даних (DW ¥) ^^ |
| транзакційні | аналітичні "^"^ |
| операційні | інформаційні ^~^^ |
| прикладні | тематично- орієнтовані |
| наперед обумовлений тип доступу, пошукова система | незаплановании пошук (запити,звіти,оператори ОЬТР) |
| застосовуються в ОЬТР-системах | застосовуються в ОЬАР-системах |
| зберігають детальні дані | зберігають узагальнені дані |
| в часі зберігаються поточні дані | зберігаються історичні (архівні) дані |
| дані подаються в нормалізованому вигляді | дані подаються в денормалізованому вигляді |
| доступ для читання-запису | доступ лише для читання |
Оскільки існують суттєві відмінності між БД та DW, то природньо, що і проектування DW здійснюється за своїми алгоритмами. У загальному випадку процес проектування сховищ даних складається з таких кроків:
|
|
|
1 крок. Проаналізуйте бізнес-процеси, які генерують дані, та інформаційні потреби організації.
Наприклад, бізнес-процесами можуть бути замовлення, відвантаження, продажі тощо. Інформаційні потреби - це наявність відповідної інформації, наприклад, щоб визначити тенденції (тренди) бізнесу, сформувати стратегію маркетингу, проаналізувати конкурентоспроможність цін тощо.
Крок 2. Застосуйте цю інформацію для визначення структури таблиці (таблиць) фактичних даних, тобто структури окремих записів низького рівня, які слід ввести до таблиць фактичних даних. Наприклад, ми хочемо записати обсяги продажу продукції в різних магазинах.
|
|
|
Крок 3. Визначте структуру кожної таблиці фактичних даних. Наприклад, запишіть щоденні обсяги реалізації марок товарів в окремих магазинах.
Крок 4. Визначте для кожної таблиці фактичних даних:
• якими є розмірності (об'єкти) та точно визначте поля для кожної розмірності;
• які фактори потрібно записувати у таблиці фактичних даних (наприклад, які одиниці товарів продані, суми реалізації тощо).
Крок 5. Прийміть рішення, чи нормалізувати схему типу "зірка", чи ні.
Крок 6. Прийміть рішення як часто потрібно витягувати та завантажувати дані в DW. Наприклад, щогодини, щодня, щотижня тощо.
Спроектоване сховище необхідно заповнити даними. Для цього використовуються інструменти ЕТL (Ехtгасt Тгаnsform Load), призначені для витягування, перетворення (трансформації) та завантаження даних.
ЕТ L є інтегрованим набором програмних інструментів, які підтримують такий процес (ЕТL):
• витягування даних з джерел операційних даних (баз даних);
• транспортування їх до цільового середовища (DW);
• очистка даних (фільтрація);
• перетворення (трансформація) даних;
• завантаження очищених та трансформованих даних до DW.
Потрібно зауважити, що деякі інструменти ЕТL об'єднують кілька кроків цього процесу, інші - здійснюють їх окремо. Сам процес ЕТL може вимагати дуже багато часу і управління мета-даними.
При витягуванні даних операційні дані можуть знаходитися в таких джерелах:
• базах даних, наприклад, ORACLE, SQL Serveг;
Ÿ системах ЕRР;
Ÿ ієрархічних системах, наприклад, Аdabas, ІМS, dВАSЕ, IDМS, Focus тощо;
Ÿ плоских файлах, наприклад АSС II files, VSАМ. ІSАМ тощо;
Ÿ даних на рівні Web.
На цьому кроці заповнення DW треба визначити, до яких полів в яких джерелах здійснити доступ та які записи витягувати. Може бути повне витягування, коли DW є пустим, або витягування з прирощенням (додаються дані до вже заповненого DW).
Під час транспортування даних потрібно визначити:
Ÿ цільове середовище, тобто чи потрібно направляти витягнені дані просто до DW, чи їх зберігати в деякій БД для "повідомлення";
Ÿ як транспортувати дані. Деякі з джерел даних є віддаленими і їх потрібно перенести у мережу. Крім того, необхідно визначити, чи завантажувати дані до DW із застосуванням звичайних методів чи спеціальних інструментів завантаження.
При очищенні (фільтрації) даних, витягнутих з джерел (БД), необхідно знайти і виправити:
Ÿ дублікацію даних;
Ÿз різаний текст (наприклад, назва вулиці не вміщується у поле);
Ÿ орфографічні помилки;
Ÿ скорочення (наприклад, М.S. або МS).
На цьому кроці заповнення DW виникає проблема злиття - видалення (merge - purge). Наприклад, Алекс Тужілін і Александр Тужліу.
Для перетворення (трансформації) даних потрібні різноманітні і гнучкі засоби трансформації, що повинні давати змогу консолідації, інтеграції, узагальнення і підсумовування. Наведемо приклади випадків, коли трансформація:
• різне кодування одних і тих самих даних;
• різні умовні назви;
• оперативні дані містять окремі торговельні операції, а нам у таблиці фактів потрібні підсумки щоденного продажу за марками товарів за кожним магазином.
Зазначимо, що часто трансформацію виконують за допомогою SQL-запитів.
На останньому кроці потрібно завантажити очищені та трансформовані дані до DW. Кроки очищення і/або трансформації можна об'єднати з кроком завантаження. Під час завантаження даних до DW потрібні спеціальні утиліти завантаження, оскільки існують величезні обсяги даних.
Засоби ЕТL розроблені для спрощення і упорядкування процесу ЕTL шляхом забезпечення user-friendly (дружнього до користувача) програмного забезпечення, що допомагає розробникам DW у виконанні кроків завантаження. Є багато постачальників ЕТL. Інформація про них подана на www/dwinfocenter.org/clean.html.
Деякі компанії DW мають свої власні засоби ЕТL (наприклад, Огасlе, IBM, Sybase).
Фізична організація DW . Чітко виділились два підходи. Дані можна зберігати:
• винятково у реляційних таблицях (ROLАР);
• таблиці факторів можна організувати як багатовимірний куб (МОLАР) і цей куб може бути зв'язаний з таблицями вимірів через індекси.
В основу ОLАР систем покладено поняття гіперкуба, тобто багатовимірного куба, у комірках якого зберігаються необхідні для аналізу дані.
У RОLАР-системах гіперкуб є віртуальним - це лише користувацький інтерфейс, який моделюється на традиційній реляційній базі даних. Дані в сховищі представляються у вигляді моделі, що отримала назву "зірка" (star schemа). Ця модель складається з таблиць двох типів: однієї таблиці даних, що аналізуються, тобто фактів (fact table) - центр зірки і декількох таблиць, які характеризують певні виміри цих фактів (demensiоn table).Таблиця фактів вмішує числові характеристики якогось напрямку діяльності компанії чи фірми, наприклад, обсяги продажу, а також ключі таблиць вимірів (наприклад, назва товару і його виробника, тип товару тощо).
Дані таблиць вимірів денормалізовані. Якщо ж таблиці вимірів нормалізовані, то така модель називається "сніжинкою" (snow flake schema). У RОLАР–системах зберігаються агреговані дані. До переваг RОLАР-систем можна зарахувати такі:
Ÿ підтримує відкриті стандарти SQL;
Ÿмінімізує вимоги до навчання і підтримки;
Ÿ підходить для простого аналізу великих обсягів даних.
У МО L АР-системі гіперкуб будується фізично і реалізується як спеціальна модель нереляційної структури, яка швидше забезпечує доступ до даних ніж реляційні моделі, але вимагає додаткових витрат пам'яті.
Переваги МОLАР -систем:
Ÿ оптимізовані для використання переваг кубічної організації розріджені елементи компресуються (тобто ущільнюється інформація внаслідок виникнення порожніх комірок при завантаженні DW);
Ÿ запити і огляди (drowsing) у МОLАР в середньому виконуються краще, ніж у ROLАР.
До недоліків МОLАР-систем належить насамперед те, що куби даних, можуть бути величезними навіть після ущільнення інформації.
Постійні полеміки між прибічниками RОLАР і МОLАР призвели до появи НОLАР-комбінованого варіанта зберігання даних, який використовує обидва типи СКБД. У багатовимірній СКБД зберігаються агрегати даних, а докладні дані з невеликим обсягом зберігаються в реляційній СКБД НОLАР -системи є компромісом між таборами МОLАР та RОLАР.
Реалізація проекту DW для бізнесу збільшує конкурентоспроможні шляхом:
• зменшення витрат;
- раціональні витрати на прийняття рішень;
- покращується управління активами (зобов'язаннями);
- реорганізація процесу бізнесу;
Ÿ збільшуються прибутки і лояльність клієнтів за рахунок кращого знання клієнтів;
Ÿ визначення нових можливостей бізнесу і проблем через краще знання бізнесу.
Переваги сховищ даних:
Ÿ єдиний інтегрований (в масштабі підприємства) погляд на бізнес, що забезпечує
- доступ до взаємопогоджених даних, інтегрованих з багатьох джерел;
- доступність історичних даних;
- краще забезпечення користувачів інформацією за рахунок
легшого доступу до даних, на підставі яких приймаються компетентні рішення
одержання відповідей на багато ключових запитань щодо бізнесу шляхом використання різноманітних засобів аналізу даних DW; швидкого і гнучкого способу отримання доступу до даних;
• забезпечують платформу для знання менеджменту;
• забезпечують мінімальне переривання діючих систем, тобто витрати часу на запити у виробничих системах зведені до мінімуму;
• покращує або створює нові процеси бізнесу.
Дата добавления: 2019-02-13; просмотров: 417; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!