Тема 7. Моделі інтеграції - глобальна Global As View (GAV) та локальна Local As View (LAV)

МОДЕЛІ ІНТЕГРАЦІЇ -

ГЛОБАЛЬНА GLOBAL AS VIEW

(GAV) ТА ЛОКАЛЬНА LOCAL AS

VIEW (LAV)

Підготував:

Мулярчук Богдан

Інтеграція даних - це об’єднання даних, які спочатку вводяться

в різні системи. Самі ці системи можуть розташовуватися в одній

локальній мережі, але мати різні платформи і внутрішню архітектуру.

Така ситуація практично неминуча у всіх підприємствах, що

займаються складеним бізнесом. Як правило, один єдиний постачальник

не може створити систему, в якій однаково добре вирішені питання

бухгалтерського обліку і автоматизації виробничого циклу, керування

кадрами і документообігу і так далі.

Перші засоби інтеграції з’явились на початку 90-х pp. минулого

століття. Вони дозволяли описувати процедури перетворення даних на

мовах програмування, наприклад, на COBOL. Середина 90-х pp. XX ст.

знаменна появою нових засобів інтеґрації даних, заснованих на

пропрієтарному ядрі і мові програмування. Протягом наступних десяти

років розробники СКБД істотно збільшували можливості SQL і утиліт

СКБД. У 1998 p. Sunopsis випускає унікальний засіб інтеґрації даних,

що ґенерує оптимізований SQL-код і що дозволяє задіяти всі

можливості і переваги СКБД, які використовуються в проекті.

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

Методи інтеграції даних

Консолідація даних - це збирання даних з територіально віддалених або

різноплатформенних джерел даних в єдине сховище даних з метою їх подальшого

опрацювання та аналізу. Консолідовані дані необхідні центральному керівництву для

того, щоб здійснювати глобальне керування бізнесом, впроваджувати єдину політику у

філіалах і здійснювати контроль над їх діяльністю.

Методи інтеграції даних

Федералізація даних забезпечує єдину віртуальну картину одного

або декількох первинних файлів даних. Якщо бізнес-застосування генерує

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

дані з відповідних первинних сховищ даних, інтегрує їх так, щоб вони

відповідали віртуальній картині і вимогам запиту, і відправляє результати

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

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

на підставі зовнішніх вимог. Всі необхідні перетворення даних

здійснюються при їх витяганні з первинних файлів. Інтеграція корпоративної

інформації (Enterprise information integration, EII) - це приклад технології,

яка підтримує федеральний підхід до інтеграції даних.

Методи інтеграції даних

Застосування розповсюдження даних здійснюють копіювання даних

з одного місця в інше. Ці застосування зазвичай працюють в

оперативному режимі і здійснюють переміщення даних до місць

призначення, тобто залежать від певних подій. Оновлення в первинній

системі можуть передаватися в кінцеву систему синхронно або

асинхронно. Синхронне передавання вимагає, щоб оновлення в обох

системах відбувалися під час однієї і тієї ж фізичної транзакції.

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

розповсюдження гарантує доставку даних в систему призначення. Така

гарантія - це ключова ознака розповсюдження даних. Більшість технологій

синхронного розповсюдження даних підтримують двосторонній обмін

даними між первинними і кінцевими системами. Прикладами технологій,

що підтримують розповсюдження даних, є інтеграція корпоративних

застосувань (Enterprise application integration, ЕАІ) і тиражування

корпоративних даних (Enterprise data replication, EDR).

Підходи інтеграції

Фізична інтеграція передбачає створення централізованого сховища і переміщення в нього

даних з баз, що інтегруються. При віртуальній інтеграції дані не дублюються, зберігаються в

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

завдання масової інтеграції, розглянемо другий підхід - віртуальну інтеграцію.

Загальна, яка не залежить від додатків архітектура віртуальної інтеграції вперше

запропонована в журналі IEEE Computer, 1992р. Центральним компонентом в цій архітектурі є

медіатор, який грає роль посередника між клієнтським додатком і СУБД джерел.

Моделі інтеграції

З концептуальної точки зору ключовою проблемою інтеграції є інтеграція даних.

Навіть якщо моделі інтегрованих БД однакові, їх схеми можуть різнитися, і в різних базах

однотипні дані можуть бути представлені по-різному. В результаті інтеграції користувач

отримує уніфіковану структуру даних з уніфікованою семантикою її елементів. Запити до

медіатора формулюються в термінах глобальної схеми, що дозволяє, по-перше,

абстрагуватися від особливостей окремих БД і, по-друге, адресувати за допомогою одного

елемента глобальної схеми дані, що зберігаються в кількох базах. Медіатор обробляє

вихідний запит, перетворюючи його в запити до одного або декількох джерел відповідно

до їх схем. Методи, використовувані для таких перетворень, засновані на визначенні

відображення між елементами глобальної схеми і схем джерел. На практиці найбільш

споживані два підходи, і при тому, і при іншому відображення задається у вигляді набору

правил. При першому підході (Global As View - GAV) кожне правило відображення

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

запитом до одного або декількох джерел, які містять відповідні дані. При другому (Local

As View - LAV), навпаки, схеми джерел визначаються через глобальну схему: правило

відображення пов'язує елемент схеми джерела із запитом до глобальної схеми.

Перевагою підходу GAV є те, що правила відображення прямо визначають

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

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

підхід ефективний тільки в разі стабільного складу: додавання нового джерела може

вплинути на визначення різних елементів глобальної схеми, в результаті відповідні

правила відображення повинні коригуватися. У цьому відношенні перевагу має підхід

LAV: правила відображення визначаються незалежно для кожного джерела, і додавання

нового джерела означає просто додавання нових правил. З іншого боку, відомо, що

завдання перетворення запитів у LAV є важкими, а алгоритми підходу мають високу

обчислювальну складність і ряд обмежень.

Для прийняття адекватних рішень необхідно, щоб дані, які надходять із різних

джерел, задовольняли такі вимоги:

− бути повними, несуперечливими та надходили вчасно;

− бути інформативними, оскільки повинні застосовуватися для прийняття рішень;

− бути однакової структури, щоби можна було завантажити їх у єдине сховище даних та

проаналізувати;

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

розроблення, щоби можна було використовувати їх в інших засобах.

У GAV підмножина кортежів, що відображається посередником, є набагато

меншою, ніж множина кортежів джерел даних. У LAV кількість кортежів глобальної

схеми є набагато більшою, ніж кількість кортежів у джерелах даних. Тому у LAV системах

часто доводиться зустрічатися з неповними відповідями. Опрацювання запитів у системах

інтеграції даних зазвичай відображається за допомогою об’єднання.

У GAV-системах розробник посередника пише код, щоб перевизначити запис.

Кожен елемент в запиті користувача відповідає правилу заміни так само, як кожен елемент

глобальної схеми відповідає запиту до джерела.

У LAV-системах процес переписування запитів є радикальніший, оскільки немає

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

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

знайти ті, які відповідають запиту користувача. У результаті перезапису є ймовірність

отримати нееквівалентний запит, але такий, що найбільше відповідає запиту користувача,

внаслідок чого і виникає невизначеність у відповіді на запит. Алгоритм MiniCon вважався

найкращим серед алгоритмів перезапису запитів для LAV.

У кожного з цих підходів є свої переваги і недоліки.

1. У підході LAV складно сформулювати запит. Подання елемента в ГС одне, а запит

формується в термінах БД (алфавіт БД, мова ІD). Але додавання нової БД не є

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

2. У підході GAV легко сформулювати запит, так як ми одразу знаємо, який запит до

БД відповідає елементу ID. Подання елемента єдине, алфавіт і мова формулювання

запитів єдині. Але додавання нового джерела є проблемою, так як деякі уявлення

необхідно перевизначити для формулювання запитів і до нового джерела теж.

3. У той час, як проектувальник LAV концентрується на тому, як представити дані

джерела в термінах БД, проектувальник GAV вирішує проблему, як витягти необхідні

дані з наданих джерел.

4. Підхід LAV потрібен для задач, в яких багато різнорідних БД, але обсяг даних не

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

дуже великим обсягом даних.

Семантична інтеграція

Іншою назвою «теорії інтеграції» є семантична інтеграція. Зазвичай під

семантичною інтеграцією розуміють підхід GAV. Для реалізації пропонується

використання онтологій та посередника.

Семантична інтеграція даних на основі онтологій. Найперспективнішим, на

сьогодні, підходом до інтеграції семантики даних є інтеграція на основі онтологій. Цей

метод передбачає використання основних елементів двох попередніх методів –

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

семантики даних. Вперше застосування онтологій як засобу семантичної інтеграції було

запропоновано в Extensible ontological modeling framework for subject mediation.

Загалом онтологію розглядають як цілісну формалізовану специфікацію деякої

предметної області, яка має на меті забезпечити однакову інтерпретацію знань про цю

предметну область на людському та комп'ютерному рівнях. У випадку інтеграції даних

об’єктом опису поданого у вигляді онтології є певний інформаційний ресурс.

Згідно до вимог стандарту IDEF5, концепти поділяють на класи та значення

класів. При цьому класи можуть утворювати ієрархію, тобто значенням класу може

бути інший клас (підклас), наприклад, до класу "документи" можуть як значення

входити підкласи "текстові документи", "XML-документи", "PDF-документи" тощо.

Зв’язки між концептами поділяють на класифікаційні – між класами і підкласами і

структурні, які описують взаємодію класів.

Кількість рівнів ієрархічної класифікації залежить від конкретних вимог та

особливостей процесів інтеграції даних. На рисунку показано приклад онтології, що

описує структуру наукової статті у вигляді концептів, які описують її змістові елементи

та зв’язки між ними.

Така онтологія описує семантичний зв'язок визначених і специфікованих

елементів даних з поняттями предметної області, утворюючи цілісну структуру "дані–

зміст". Оскільки об’єктом опису онтології у випадку семантичної інтеграції є дані, то її

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

спеціального вигляду. Тобто, проблему семантичної інтеграції даних можна звести до

проблеми виявлення відповідностей та суперечностей між їх онтологіями.

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

послідовність вимог щодо елементів двох онтологій даних: два набори даних Di та Dj

вважають придатними до семантичної інтеграції, якщо для двох онтологій Oi та Oj, які

відповідають цим наборам даних, виконуються правила:

1. у множинах концептів X(Di) та X(Dj):

- немає однакових понять, описаних по-різному;

- немає понять різного змісту, описаних однаково.

2. у множинах зв’язків R(Di) та R(Dj) :

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

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

3. у множинах функцій інтерпретації Fi та Fj :

- немає функцій, одночасна реалізація яких призведе до неоднозначності

інтерпретацій;

- з однотипними концептами різних онтологій не пов'язано обмежень, які не

можуть бути виконані одночасно.

Перевірити зазначену низку критеріїв семантичної інтеграції даних можна як на

формальному, так і на експертному рівні, при цьому результат має бути однаковим.

Виконання всієї множини вимог дає змогу зробити висновок про можливість інтеграції

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

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

людському рівні, так і на рівні інформаційних технологій забезпечує основну перевагу

методу семантичної інтеграції на основі онтологій:

- можливості її технічної реалізації за допомогою спеціалізованих програмних

засобів;

- формування та аналіз критеріїв семантичної інтеграції на формальному рівні;

- отримання семантично коректного результату без безпосередньої участі людини-

експерта.