Гомогенные и гетерогенные распределенные СУБД

Распределенные СУБД можно классифицировать еще и как гомогенные и гетерогенные. В гомогенных системах все сайты (узлы) используют один и тот же тип СУБД.

В гетерогенных системах на сайтах могут функционировать различные типы СУБД, использующие разные модели данных, то есть гетерогенная система может включать сайты с реляционными, сетевыми, иерархическими и объектно-ориентированными СУБД.

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

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

В таких системах для организации взаимодействия между различными типами СУБД необходимо организовать трансляции передаваемых сообщений. При этом для обеспечения прозрачности в отношении типа используемой СУБД пользователи каждого сайта должны иметь возможность вводить интересующие их запросы на языке именно той СУБД, которая используется на данном сайте (то есть если на сайте C2 используется СУБД реляционного типа, то пользователь должен иметь возможность вводить запросы реляционного типа на данные из других (с нереляционными СУБД) сайтов).

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

¾ иной тип используемого оборудования;

¾ иной тип используемой СУБД;

¾ иной тип используемых и оборудования и СУБД.

Если используется иной тип оборудования, однако на сайте установлен тот же самый тип СУБД, то методы выполнения трансляции вполне очевидны и включают замену кодов и изменение длины слова. Если же типы используемых на сайтах СУБД различны, процедура трансляции усложняется тем, что необходимо, во-первых, отображать структуры данных одной модели (например, РМД) в соответствующие структуры данных другой модели (например, СМД). То есть отношения в РМД должны быть преобразованы в записи и наборы, типичные для сетевой модели данных. Кроме того, потребуется транслировать текст запросов с одного используемого языка на другой. Например, запросы с SQL-операторами SELECT потребуется преобразовывать в запросы с операторами FIND и GET языка манипулирования данными сетевой СУБД.

Если же отличается и тип используемого оборудования, и тип программного обеспечения, то потребуется выполнить оба вида трансляции. А это чрезвычайно усложняет обработку в гетерогенных СУБД.

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

Типичное решение, применяемое в некоторых реляционных системах, состоит в том, что отдельные части гетерогенных распределенных систем должны использовать шлюзы, предназначенные для преобразования языка и модели данных каждого из используемых типов СУБД в язык и модель данных реляционной системы. Однако, подходу с использованием шлюзов опять таки свойственны недостатки (или ограничения).

Во-первых, шлюзы не позволяют организовать систему управления транзакциями даже для отдельных пар систем. Другими словами, шлюзы не позволяют системе координировать управление

1) процедурами восстановления транзакций, включающих обновление данных в обеих базах;

2) параллельностью.

Во-вторых, использование шлюзов призвано лишь решить задачу трансляции запросов с языка одной СУБД на язык другой СУБД. Поэтому они не позволяют справиться с проблемами, вызванными неоднородностью структур и представлением данных в различных схемах.

В настоящее время организована в комитете Opcu Croup рабочая группа для подготовки спецификаций, регламентирующих инфраструктуру среды базы данных, включающую следующие элементы:

1. Унифицированный и достаточно мощный интерфейс языка SQL (SQLAPI), позволяющий создавать клиентские приложения таким образом, чтобы они не были привязаны к конкретному типу используемой СУБД.

2. Унифицированный протокол доступа к базе данных, позволяющий СУБД одного типа непосредственно взаимодействовать с СУБД другого типа, без необходимости использования какого-либо шлюза.

3. Унифицированный сетевой протокол, позволяющий осуществлять взаимодействия СУБД различного типа.

Самой важной задачей этой группы следует считать отыскание способа, позволяющего в одной транзакции выполнять обработку данных, содержащихся в нескольких базах и управляемых СУБД различных типов, причем без необходимости использования каких-либо шлюзов.