1.3.2 Виды распределенных баз данных (следующий слайд)

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

1.4. Сложности и возможные решения

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

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

1.5. Принципы открытого доступа и функциональной совместимости баз данных

Комитет Open Group организовал рабочую группу (Specification Working Group — SWG), призванную подготовить ответ на поступающие запросы по поводу открытого доступа и функциональной совместимости баз данных. Цель работы этой группы состоит в подготовке спецификаций (или в получении подтверждений того, что требуемые спецификации существуют или разрабатываются), регламентирующих инфраструктуру среды базы данных, включающую следующие элементы.

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

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

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

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