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

РБД могут быть [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] обсудим в самом общем виде.

 
< Пред   СОДЕРЖАНИЕ     След >