Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Лекція №7 el.doc
Скачиваний:
5
Добавлен:
23.11.2019
Размер:
134.14 Кб
Скачать

Деякі характеристики даних в dw:

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

  • розмірні дані є незалежними у об’єктах (розмірностях);

  • основний тип доступу – це незапланований (порівняно з обумовленим наперед у БД) – запити, звіти, оператори OLAP;

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

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

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

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

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

Відмінності між бд та dw

Операційні БД

Сховища даних DW

транзакційні

Аналітичні

Операційні

Інформаційні

прикладні

Тематично-орієнтовані

Наперед обумовлений тип доступу, пошукова система

Незапланований пошук (запити, звіти,

оператори OLTP)

Застосовуються в

OLTP-системах

Застосовуються в OLAP-системах

Зберігають детальні дані

Зберігають узагальнені дані

В часі зберігаються поточні

дані

Зберігаються історичні (архівні) дані

Дані подаються в нормалізованому вигляді

Дані подаються в денормалізованому

вигляді

Доступ для читання-запису

Доступ лише для читання

Оскільки існують суттєві відмінності між БД та 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, dBASE, IDMS, Focus тощо;

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

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

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

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

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

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

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

  • дублікацію даних;

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

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

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

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

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

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

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

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

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

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

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

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

Фізична організація DW.

Чітко виділились два підходи. Дані можна зберегти:

  • винятково у реляційних таблицях (ROLAP);

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

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

Дані в OLAP-моделі подаються як показники (measures), кожен з яких визначений на деякій множині вимірів (dimensions). В задачі “Аналіз кредитного портфеля банку” можна виділити такі показники як “Кредитна сума”, “Залишки заборгованості”. Вимірами цих показників будуть: “Тип клієнту”, “Звітна дата”, “Вид кредиту”, “Валюта”, “Категорія ризику” та інші. При відомих значеннях всіх вимірів ми можемо отримати результатні дані показника, що нас цікавить. Виміри утворюють деякий віртуальний простір, в якому зберігаються показники – гіперкуб. Користувач із даними, що подані в багатовимірному вигляді може робити ряд OLAP-операцій: піднімання (консолідація по деяким напрямкам), спуск (деталізація по деякому напряму), поворот (зміни напряму сортування), відбір і проекція даних в будь-який вимір.

Для аналізу кредитного портфеля можна застосовувати наступні архітектури OLAP-систем: MOLAP (Multidimentional OLAP), засновані багатовимірних СУБД (БСУБД), ROLAP (Relation OLAP), в основі яких лежать класичні реляційні бази даних, HOLAP (Hybrid OLAP) – гібридні системи, DOLAP (Desk OLAP) – настільні однокористувацькі системи.

Елементи автоматичної обробки і аналізу даних, що називають Data Mining (знаходження знань) стають невід'ємною частиною концепції інформаційних сховищ даних (data warehouse) та організації інтелектуальних обчислень. Сховище даних — це предметно-орієнтований, інтегрований, прив'язаний до часу, незмінний набір даних для підтримки процесу прийняття рішень. Простий доступ користувача до сховища даних забезпечує тільки отримання відповідей на питання, що були задані, в той час як технологія data mining дозволяє побачити ("знайти") приховані правила і закономірності у наборах даних, які користувач не може передбачити, і застосування яких може сприяти виявленню більш ефективного результату.

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

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

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

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

- кластеризація (виділення різних однорідних груп даних, відрізняється від класифікації тим, що самі групи заздалегідь не задані);

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

- прогнозування часових послідовностей (побудова математичної моделі за "історичною" інформацією, що зберігається в інформаційних сховищах у вигляді часових рядів);

- асоціація (має місце в тому випадку, якщо кілька подій зв'язані між собою);

- послідовність (має місце, коли існує ланцюжок зв'язаних у часі подій).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • реорганізація процесу бізнесу;

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

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]