Корпоративные субд. Основные возможности по работе с распределенными базами данными. Сравнение возможностей работы с распределенными бд в Oracle, ms sqlServer.

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

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

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

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

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

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

MS SQL Server

Для того чтобы обеспечить работу всех пользователей в едином информационном пространстве, необходимо решить задачу согласования данных на различных серверах. Решать эту задачу можно по-разному. За согласование может отвечать любой слой многослойного приложения - клиентское приложение или промежуточный слой бизнес-объектов (если он есть). В большинстве случаев наиболее целесообразной, однако, является реализация согласования данных путем непосредственного взаимодействия серверов баз данных. При таком способе клиентские приложения могут "забыть" о распределенной структуре данных и работать только с одним сервером. Кроме того, взаимодействие на уровне серверов баз данных является, как правило, более эффективным с точки зрения быстродействия и надежности.

Основное средство взаимодействия двух SQL-серверов - это удаленные хранимые процедуры. Запрос или хранимая процедура, выполняемые на одном сервере, могут включать вызов процедуры, хранящейся на другом сервере. Другого способа непосредственного межсерверного взаимодействия не существует - один сервер не может напрямую обратиться к данным другого сервера при помощи операторов языка SQL (эта возможность появится в будущих версиях. Примечание: данная часть материала взята из статьи про 6.5 версию, так что, возможно, это уже и реализовано). Для того, чтобы один сервер мог вызывать процедуры другого, необходимо эти серверы "познакомить", т.е. определенным образом зарегистрировать. Делается это достаточно просто при помощи административного средства SQL Enterprise Manager.

Oracle

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

Концепция построения распределенных БД в Oracle основана на децентрализованной их организации. Серверы взаимодействуют друг с другом с помощью уже знакомого нам протокола SQL*Net. Ссылки друг на друга - так называемые каналы связи БД (database links) - серверы хранят в качестве объектов БД. В свою очередь, полное имя объекта может включать в себя канал связи (т. е. вместо самого объекта в локальной базе данных может храниться как бы ссылка на него): это, безусловно, требует обеспечения уникальности имен серверов ("сервисов" в терминологии Oracle) в сети, что достигается с помощью иерархической организации доменов, подобной существующей в Internet.

Поскольку вместо "настоящих" имен объектов можно использовать их синонимы (также в свою очередь являющиеся объектами БД), то приложение клиента может попросту не знать, является ли данный объект локальным для сервера, с которым установлена связь, или нет. Конечно, механизм каналов связи и синонимов - лишь внешняя сторона той системы, которая позволяет сделать структуру распределенной БД Oracle абсолютно прозрачной для приложений независимо от размещения данных и режима взаимодействия серверов. А таких вариантов организации Oracle предлагает множество - как говорится, на любой вкус, хотя точнее было бы сказать, для любой ситуации.

19