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

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

Навіть якщо всі дані зберігаються на центральному сервері БД, розібратися в їх складних структурах кінцевому користувачеві, як правило, дуже складно. Тому виникає потреба у поперед­ній обробці оперативних даних, що збираються в різних відділах організації, не тільки для того, щоб зібрати їх в одному місці, а й для того, щоб узгодити їх та, виходячи з особливостей задач, які потрібно розв’язувати, очистити від непотрібних даних і зберегти в простій, зрозумілій та зручній для формулювання нерегламентованих запитів структурі. Саме це й є основною причиною появи так званих сховищ, або складів, даних, які мають зберігати лише необхідну, актуальну і точну інформацію з метою доставки її певним особам у потрібний час для прийняття ними обґрунтованих і своєчасних рішень.

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

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

Основні компоненти сховища даних наведено на рис. 2.1.1. Оперативні дані збираються з різних джерел, очищуються, узгоджуються, інтегруються й складаються в реляційне сховище. Потім вони (цілком або частково) підготовлюються для OLAP-аналізу. Вони можуть бути завантажені в спеціальну БД OLAP або залишені в реляційному сховищі.

Рис. 2.1.1. Основні компоненти сховища даних

Дані реляційного сховища доступні для аналізу за допомогою різноманітних засобів побудови звітів. Але ті традиційні звіти, які створюються програмістами і призначені для безпосереднього використання особами, що приймають рішення, хоча і є надзвичайно простими у застосуванні, проте жорстко обмежені у функціональності (позбавлені гнучкості). Вони отримуються за допомогою певної множини запитів і, будучи достатніми для повсякденного застосування, неспроможні відповісти на всі запитання до наявних даних, що можуть виникнути при прийнятті рішень. Результатом виконання цих запитів, як правило, є багатосторінкові звіти. Особа, що приймає рішення, не може їх «прокрутити», «розгорнути» або «згорнути», щоб одержати бажане уявлення даних. Тому після ретельного вивчення цих звітів у неї з’являється нова серія запитань. Проте кожний новий непередбачений запит має бути спочатку формально описаний, закодований програмістом — тільки після цього він може бути виконаний. Час чекання в такому разі може сягати кількох годин і навіть днів, що здебільшого неприйнятне. Отже, зовнішня простота отримання інформації, чого активно домагається більшість замовників інфор­маційно-аналітичних систем, обертається катастрофічною втратою гнучкості. За не дуже великих обсягів даних у реляційному сховищі та не дуже складних взаємозв’язків між таблицями непоганий спосіб виходу з цієї ситуації — відбір потрібних даних і перенесення їх для наступного аналізу в Excel за допомогою програми MS Query. Але у разі роботи з великою кількістю реляційних таблиць така задача залишається надто складною і проведення оперативного аналізу даних стає практично неможливим.

Тому попереднє збирання, очищення та інтегрування даних — це ще не все, що потрібно кінцевому користувачеві. Йому потріб­ні також:

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

¾ гнучкі інструменти для обчислень і перегляду інформації, які дають змогу просто й зручно розгортати і згортати дані, забезпечуючи можливість як перегляду деталізованої інформації, так і комплексного погляду на зібрану інформацію, її узагальнення та агрегацію;

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

Одним із засобів вирішення перших двох проблем є OLAP (On-Line Analytical Processing — оперативне аналітичне оброблення) — технологія організації даних відповідно до методів їх аналізу, що зменшує витрати часу і зусилля на створення необхідних звітів. Хоча OLAP і не є необхідним атрибутом сховища даних, але саме він найчастіше застосовується для аналізу нагромаджених у сховищі відомостей.

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

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