Меню
Главная
УСЛУГИ
Авторизация/Регистрация
Реклама на сайте
 
Главная arrow Информатика arrow Базы данных
< Предыдущая   СОДЕРЖАНИЕ   Следующая >

Процесс интеграции

РБД могут быть [10] однородными (рис. 11.3, а) и неоднородными (рис. 11.3, б).

Неоднородность определяется следующими обстоятельствами:

1) использование разных моделей данных;

2) отличие в синтаксисе и семантике даже одного вида моделей (например, реляционных);

3) различие методов управления БД (резервирования и восстановления, синхронизации, блокировки).

Независимо от однородности в общем случае данные из (любой) ЛБД с одной моделью данных могут быть переданы в (любую) ЛБД с другой моделью данных.

В связи с этим следует обсудить общую постановку задачи взаимного преобразования данных.

Интеграция однородных (а) и неоднородных (б) локальных БД

Рис. 11.3. Интеграция однородных (а) и неоднородных (б) локальных БД

Первоначально для построения неоднородных БД использовались процедуры выгрузки-загрузки фактически на физическом уровне. Информация:

• выгружалась из исходной аппаратно-программной среды;

• запоминалась в общем для исходной и объектной сред формате (например, ASCII);

• загружалась в объектную среду.

На этом пути встретились серьезные трудности. Если преобразование файлов с последовательной физической организацией достаточно просто, хуже обстоит дело при использовании произвольной выборки. Применение индексно-последовательных файлов практически исключает возможность автоматизации процедуры преобразования.

В этом случае необходимо сначала перейти к произвольному или последовательному способу доступа с уничтожением всех указателей и вспомогательных программных средств, осуществить преобразование, а затем – ввести новую систему указателей.

Реализация оказалась сложной, к тому же терялось свойство физической независимости.

Дальнейшие работы пошли по пути преобразований на логическом уровне, при этом выявились два направления.

1. Построение схем "попарного" взаимодействия моделей данных. При наличии η локальных БД требуется n(n-1) таких схем, что чрезвычайно неудобно.

2. Использование универсальной виртуальной промежуточной модели. Данные преобразуются в эту глобальную модель, и обратно. В качестве такой модели сначала использовали ER-диаграммы.

В дальнейшем более перспективным и успешным оказался современный вариант применения (глобальной) реляционной модели [14, 15], о котором поговорим детальнее.

Для формального описания этого варианта возможно использовать аппарат коммутативной алгебры (рис. 11.4).

Коммутативная диаграмма

Рис. 11.4. Коммутативная диаграмма

Пусть А1 и B1 – состояния системы (например, в прямоугольных координатах), a f1 – функция преобразования состояния системы. Пусть А2, В2 и f2 описывают ту же систему (например, в полярных координатах). Пусть φ – правило преобразования одной системы координат в другую. Для этого случая в строгих алгебраических исследованиях показано, что преобразование верно, если диаграмма на рис. 11.4 коммутативна, т. е. выполняется условие

f2 × φ = φ х f1, (11.5)

где × – некоторая алгебраическая операция.

Можем полагать, что А1 и Аг – исходные таблицы СУБД с разными, в общем случае, моделями данных, к которым осуществляется запрос; В1 и В2 – результаты операций обновления или запроса; f1 и f2 – правила получения данных (ЯОД или ЯМД или язык запроса); φ – правила перехода (по данным) из одной БД в другую.

Для "точечных", физических систем математические выкладки коммутативной алгебры выполнены детально.

Использование условия (11.5) для БД значительно труднее. Дело в том, что физические системы оперируют однородными, бесструктурными множествами состояний Аi и Вi, i = 1, 2.

В РБД осложнения вызываются следующими обстоятельствами [14, 15].

1. Множества А1 и А2 структурированы, при этом структура определяется принятой моделью данных. Даже при использовании различных СУБД с одной и той же моделью данных (например, реляционной) возможны различия в форматах данных, в командах ЯОД.

2. ЯМД и языки запросов могут быть различны даже для однородных РБД с разными типами ЛБД.

Часть этих трудностей уже преодолена. Так, проблема различия в ЯОД и ЯМД при использовании реляционных БД различного типа фактически снята при использовании "стандартного" языка SQL2 [26] или приложения Open DataBase Connectivity (ODBC). Сложнее обстоит дело с другими моделями данных, еще труднее, если в РБД используются различные модели данных ЛБД.

Перечисленные проблемы интеграции ЛБД [14, 15] обсудим в самом общем виде.

 
Если Вы заметили ошибку в тексте выделите слово и нажмите Shift + Enter
< Предыдущая   СОДЕРЖАНИЕ   Следующая >
 
Предметы
Агропромышленность
Банковское дело
БЖД
Бухучет и аудит
География
Документоведение
Журналистика
Инвестирование
Информатика
История
Культурология
Литература
Логика
Логистика
Маркетинг
Медицина
Менеджмент
Недвижимость
Педагогика
Политология
Политэкономия
Право
Психология
Религиоведение
Риторика
Социология
Статистика
Страховое дело
Техника
Товароведение
Туризм
Философия
Финансы
Экология
Экономика
Этика и эстетика