Однородные и неоднородные базы данных. Распределенные системы часто строятся путем «интеграции» разнородных аппаратных и программных средств

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

Использование неоднородных СУБД обычно является следствием формирования распределенной базы данных из ряда существовавших ранее автономных баз данных. Стоящая перед разработчиками цель — достичь прозрачности доступа, что представляет собой нечто большее, чем простое обеспечение доступа к удаленным СУБД и их базам данных. Прозрачность означает, что пользователю либо неизвестно расположение данных, либо такие сведения для работы с базой данных ему не требуются. В системах с неоднородными СУБД такое возможно лишь в том случае, если локальная СУБД, управляющая данными, также «прозрачна», т. е. пользователь не обязан знать, какая локальная СУБД обслуживает его запрос. Это можно реализовать двумя принципиально отличными путями [8]. Один путь состоит в том, чтобы дать пользователю возможность использовать в каждом узле пользовательский интерфейс, предоставляемый локальной СУБД. При этом имеющаяся схема должна быть расширена с целью включения данных, имевшихся в других узлах, но пользователи должны работать так, как если бы удаленные данные были добавлены в данную локальную базу данных.

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

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

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

Существует множество вариантов однородной системы распределенных баз данных. На каком-то узле может находиться одна глобально доступная «главная машина СУБД», с которой связаны компоненты для доступа к данным локальных баз данных, размещенные совместно с этими базами данных в пределах всей организации (или отдельного ее подразделения в зависимости от масштаба распределения). Более сложные модели могут допускать распределенность самой СУБД, когда каждый ее компонент на равных правах имеет доступ к данным любого другого узла [13;18]. Однако относительно собственного управления данными содержатся тождественные модели хранения, структуры индексирования и форматы данных в рамках всей распределенной среды.

Неоднородные распределенные системы баз данных являются альтернативой однородной системы распределенных баз данных. Они могут содержать в себе два или более существенно различающихся продукта управления данными (например, реляционные СУБД от разных поставщиков, таких, как Oracle и Digital Equipment Corp., или СУБД одного поставщика, но функционирующие на разных платформах и использующие различные структуры баз данных, такие, как DB2 и SQL/DS компании IBM).

Имеется возможность подразделить неоднородные системы баз данных на классы в широком диапазоне - от федеративных систем до различных типов систем мультибаз данных, а также есть и формальная таксономия неоднородных моделей.

Однородные распределенные системы баз данных в основном проектируются методом «сверху вниз». Неоднородные наоборот чаще всего строятся методом «снизу вверх» для того, чтобы можно было организовать общую среду управления над существовавшими ранее разрозненными информационными ресурсами [22].

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

Однако проектирование распределенной базы данных методом «сверху вниз» предполагает то, что ее объекты не будут направлены в одно место, а будут распределяться по нескольким вычислительным системам.

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

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