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

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 і ін.

Рівень керування (адміністрування)

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