21. Інтеграція різнорідних джерел даних

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

Мається на увазі, що до будь-БЗ можуть бути застосовні 3 операції: визначити (define), сказати (tell) (тобто зробити твердження) і запитати (ask). Кожна з операцій може використовувати один або більше власних мов, наприклад мова опису схем та обмежень, мова поновлення (для нових тверджень), мова запитів і мова опису результату. Переваги застосування дескриптивної логіки (DL) для поліпшення кожного з мов широко вивчені в літературі по базах знань. Тут будуть розглянуті три важливі завдання, що виникають при управлінні даними:

вираження концептуальної моделі предметної області (онтології) для конкретного джерела даних,

інтеграція декількох джерел,

вираження і виконання запитів.

Для кожної з задач існує підхід з використанням DL.

Спочатку - кілька основних понять з області проектування БД та їх використання.

У першу чергу, ще до створення БД, виникає необхідність описати предметну область такою мовою, щоб опис було зрозуміло як звичайним користувачам, так і розробникам. Цей опис виконується мовою високого рівня і має форму вимог. В області БД такою мовою є ER-діаграми (ER-модель). В рамках ER-моделі навколишній світ представляється як набір сутностей (n-арних відносин). Отримана семантична модель предметної області може зберігатися на комп'ютері, так само як і самі дані, але, як правило, вона містить загальну і постійну інформацію (наприклад, про те, що "відділ підприємства має рівно одного керівника") в протилежність конкретним фактам (" Петров є керівником відділу поставок "). Ця семантична модель вводить терміни для опису предметної області та визначає їх значення шляхом завдання взаємозв'язків і обмежень. Цей рівень представлення даних найбільш близький онтологічної поданням.

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

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

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

Наприклад, формула

могла б визначати запит щодо тих одержувачів (значення вільної змінної), які забезпечувалися постачальником'' одним і тим же матеріалом в різні моменти часу (и).

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

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

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

Завдання "проектування системи інтеграції даних" складається з декількох підзадач. Онтологічний підхід може успішно застосовуватися для вирішення двох підзадач:

специфікації вмісту різнорідних джерел даних у вигляді онтології;

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