9.4. Проблеми збереження і пошуку даних

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

Основний висновок з наведеного (і далеко не повного) переліку достатньо однозначний: традиційні БД, орієнтовані на використання в корпоративних операційних СОД, не можуть слугувати ефективним засобом збереження інформації в системах ІАД.

Вирішення виниклих проблем вимагало нової концепції збереження надвеликих об'ємів даних і оперативного пошуку необхідної різнорідної інформації у власних архівах. В якості можливих варіантів рішень були запропоновані концепції сховищ даних (СД, Data Warehouse) Б.Інмона і інформаційних сховищ (Information Warehouse), розроблена IBM ще у 80-х рр. ХХ ст. При цьому в основу концепції СД були покладені принципи наявності предметної орієнтації, засобів інтеграції даних, незмінності і хронологізму даних. Запропоновані концепції несли в собі й позитивне ядро, і низку спірних моментів. Однак, як і будь-які інші концепції, вони носили сугубо ідеологічний характер. Технологічна реалізація проголошених принципів неминуче вела до конкретних задач модифікації уже існуючих БД.

Найбільш поширеним засобом збереження даних в корпоративних ІС є реляційні БД (РБД). Серед негативних факторів РБД, що ускладнюють їх застосування в системах с ІАД, треба вказати невпорядкованість даних, що істотно ускладнюють розв'язок динамічних задач data mining, апріорну фіксацію типів можливих запитів, втрату семантичних зв'язків між реквізитами в процесі нормалізації таблиць, орієнтацію на обробку невеликих груп записів і високу інтенсивність модифікації даних (шляхом різних модифікацій індексів з використанням B-дерев).

Одним з напрямків розвитку РБД в інтересах системах ІАД, напевно, є розробка таблиць з денормалізованою формою (модифікації схеми організації даних типу зірка). Відомі й інші напрямки підвищення ефективності РСУБД: застосування Bitmap-індексів, поділ великої фактологічної таблиці на декілька окремих фрагментів (горизонтальна фрагментація), інші варіанти горизонтального або вертикального поділу таблиць, застосування оптимізаторів обробки запитів зі схемою зірка тощо.

Альтернативний підхід до вирішення задачі збереження інформації пов'язаний з використанням багатомірних БД (МБД) і поданням даних у вигляді багатомірних гіперкубів. Така форма подання даних більш гармонічна з точки зору її застосування в ІАД, хоча й вимагає більшої сумарної пам'яті. На даний час існують МБД об'ємом в десятки гігабайт.

Однак МБД також володіють певними недоліками. Зокрема, вони неефективно використовують зовнішню пам'ять, коефіцієнт використання фізичної пам'яті носія в МБД також значно нижче, чим в реляційних. Крім того, в якості граней багатомірного куба повинні вибиратися достатньо стабільні у часі реквізити (з точки зору незмінності їх взаємозв'язків), що не цілком зручно для низки задач ІАД.

Таким чином, існуючі на сьогодні БД вимагають серйозних змін для роботи в ІС з ІАД. Однак, навіть у модифікованому вигляді варіант єдиного, монолітного і незмінного джерела даних не цілком конструктивний. Зокрема, аналіз поведінки досліджуваного об'єкта в різноманітних умовах передбачає генерацію різноманітних віртуальних ситуацій і відповідних до них даних; захаращення такими даними незмінного а все запам'ятовуючого сховища даних було б щонайменше нераціонально. Крім того, трудно очікувати задовільної оперативності ситуаційного аналізу, коли кожний запит експерта поринає у багатогігабайтні глибини інформації.

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

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

Очевидно, що розв'язок задачі побудови сховища другого рівня вимагає концептуальних підходів, відмінних від постулатів Інмона. В рамках OLAP-технології (On-Line Analytical Processing) динамічного інтерактивного багатомірного аналізу, запропонованого Е. Коддом, роль такого сховища виконує „OLAP Server”. При цьому Кодд не висуває певних вимог до сховища першої ступеня. Дані для вирішення конкретної задачі можуть збиратися з різних неузгоджених джерел за допомогою спеціального інструментарію, OLAP Tools, наявного у розпорядженні аналітика. Очевидно, що при цьому якісно зростає роль вимог до структури і об'єму метаданих, які визначають не тільки адресацію і структуру інформації, що зберігається в різноманітних джерелах, але й її семантику. Іншими словами, рівень метаданих повинен бути наближений до рівня кінцевого користувача.

Альтернативним підходом до побудови другого рівня сховища даних є концепція вітрин даних (ВД, Data Mart), що була запропонована Forrester Research. Концепція ВД передбачає, що експерт працює тільки з тими даними, які потрібні для розв'язку конкретної задачі, цільова БД вітрин максимально наближена до кінцевого користувача і не вимагає надвеликої пам'яті, характерної для першого рівня СД.

Така багаторівнева схема СД „поступово стає стандартом де-факто, дозволяючи найбільш повно реалізувати і використовувати достоїнства кожного з підходів”.

Досить високі вимоги до структури метаданих, мабуть, приведуть до необхідності включення до структури ІС з ІАД фахівця з управління даними в СД – адміністратора даних, озброєного спеціалізованими програмними засобами.