Распределенные СУБД

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

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

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

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

1.2. Модель  клиент – сервер в технологии распределенных баз данных

     Вычислительная  модель клиент—сервер связана с  появлением в 1990-х гг. открытых систем. Термин «клиент—сервер» применялся к архитектуре программного обеспечения, которое состояло из двух процессов обработки информации: клиентской и серверной. Клиентский процесс запрашивал некоторые услуги, а серверный процесс обеспечивал их выполнение. При этом предполагалось, что один серверный процесс может обслужить множество клиентских процессов. Учитывая что аппаратная реализация этой модели управления базами данных связана с созданием локальных вычислительных сетей предприятия, такую организацию процесса обработки информации называют архитектурой клиент—сервер. Основной принцип технологии клиент—сервер применительно к технологии управления базами данных заключается в разделении функций стандартного интерактивного приложения на пять групп, имеющих различную природу:

• функции ввода и отображения данных (Presentation Logic);
• прикладные функции, определяющие основные алгоритмы решения задач приложения (Business Logic);
• функции обработки данных внутри приложения (Database Logic);
• функции управления информационными ресурсами (Database Manager System);
• служебные функции, играющие роль связок между функция 
  ми первых четырех групп.

     Структура типового приложения, работающего с  базой данных в архитектуре клиент—сервер, приведена рис. 2.

     Рисунок 2. Структура типового приложения, работающего с базами данных

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

• формирование экранных изображений;
• чтение и запись в информации экранные формы;

     управление  экраном;

     • обработка движений мыши и нажатие  клавиш клавиатуры.

     Бизнес-логика, или логика собственно приложений (Business processing Logic), — это часть кода приложения, которая определяет собственно алгоритмы решения конкретных задач приложения. Обычно этот код пишется с использованием различных языков программирования, таких как С, C++, Visual-Basic и др.

     Логика  обработки данных (Data manipulation Logic) — это часть кода приложения, которая непосредственно связана с об работкой данных внутри приложения. Данными управляет собственно СУБД. Для обеспечения доступа к данным используется язык SQL.

     Процессор управления данными (Database Manager System Processing) — это собственно СУБД. В идеале функции СУБД должны быть скрыты от бизнес-логики приложения, однако для рассмотрения архитектуры приложения их надо выделить в отдельную часть приложения [3].

     В централизованной архитектуре (Host-based processing) эти части приложения располагаются в единой среде и комбинируются внутри одной исполняемой программы.

     В децентрализованной архитектуре эти  задачи могут быть по-разному распределены между серверным и клиентским процессами. В зависимости от характера распределения можно выделить следующие модели распределений (таблица 1 см. приложение А):

• распределенная презентация (DP — Distribution Presentation);
• удаленная презентация (RP — Remote Presentation);
• распределенная бизнес-логика (RBL — Remote business logic);
• распределенное управление данными (DDM — Distributed data management);
• удаленное управление данными (RDM — Remote data management).

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

1.3. Типы  распределенных СУБД

     В общем случае режимы работы с БД можно классифицировать по следующим  признакам:

• многозадачность — однопользовательский или многопользовательский;
• правило обслуживания запросов — последовательное или параллельное;
• схема размещение данных — централизованная или распределенная БД.

     Распределенные  СУБД подразделяются на однородные и  разнородные. 

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

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

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

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

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

1.4. Размещение  данных в распределенных базах  данных

     Размещение данных в распределенных БД характеризуется следующими понятиями:

     • фрагментация. Любая запись (отношение  в случае реляционных моделей  данных) может быть разделено на некоторое количество частей, называемых фрагментами, которые затем могут  распределяться по различным узлам. Как отмечалось ранее, существуют два основных типа фрагментации: горизонтальная и вертикальная. В первом случае фрагменты представляют собой подмножества строк, а во втором — подмножества столбцов (атрибутов);

     • размещение. Каждый фрагмент сохраняется на узле, выбранном с учетом оптимальной схемы доступа;

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

     Определение и размещение фрагментов должно проводиться  с учетом особенностей использования базы данных (в частности, на основе анализа транзакций).

     Существуют  четыре стратегии размещения данных в системе:

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

1.5. Требования  к распределенной обработке данных

     Прозрачность  сети. Клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечивать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обеспечить прозрачный доступ пользователей и программ к удаленным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно более широкий диапазон сетевых протоколов (TCP/IP, DECnet, SNA, SPX/IPX, NetBIOS, AppleTalk и др.) [5].

     Автоматическое  преобразование форматов данных. Как только несколько компьютеров различных моделей под управлением различных операционных систем соединяются в сеть, сразу возникает вопрос о согласовании форматов представления данных. Действительно, в сети могут быть компьютеры, отличающиеся разрядностью (I6-, 32- и 64-разрядные процессоры), порядком следования байт в слове, представлением чисел с плавающей точкой и т. д. Задача коммуникационного сервера состоит в том, чтобы на уровне обмена данными обеспечить согласование форматов между удаленным и локальным узлами с тем, чтобы данные, извлеченные сервером из базы на удаленном узле и переданные по сети, были правильно истолкованы прикладной программой на локальном узле.