Развитие БД и СУБД

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

Синхронное обновление DDB и DR-технология - в определенном смысле антиподы. Краеугольный камень первой - синхронное завершение транзакций одновременно на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в DDB. Ee "Ахиллесова пята" - жесткие требования к производительности и надежности каналов связи. Если база данных распределена по нескольким территориально удаленным узлам, объединенным медленными и ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных организаций) обработка распределенных данных практически невозможна.

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

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

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

5 Многозвенная архитектура

Архитектура клиент-сервер

 Распределенные системы — это системы клиент-сервер. Существует, по меньшей мере, три модели клиент-сервер:

 * модель доступа  к удаленным данным (RDA-модель);  

* модель сервера базы данных (DBS-модель);  

* модель сервера приложений (AS-модель).

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

 * компонент интерфейса  с пользователем; 

* программное обеспечение промежуточного  слоя (middleware); 

* компонент управления данными.

 Middleware — это главный компонент трехзвенных распределенных систем. Он выполняет функции управления транзакциями и коммуникациями, транспортировки запросов, управления именами и иные функции.

Существует фундаментальное различие между технологией типа «сервер  запросов—клиент запросов» и  трехзвенными технологиями. В первом случае клиент явным образом запрашивает данные, зная структуру базы данных (имеет место так называемая «поставка данных» клиенту). Клиент передает СУБД, например, SQL-запрос, а в ответ получает данные. Осуществляется жесткая связь типов, для реализации которой все СУБД используют закрытый SQL-канал. Он строится двумя процессами: SQL/Net на компьютере-клиенте и SQL/Net на компьютере-сервере и порождается по инициативе клиента оператором connect. Канал называется закрытым в том смысле, что невозможно, например, написать программу, которая будет шифровать SQL-запросы по специальному алгоритму или другим образом будет вмешиваться в процесс передачи данных между клиентским и серверным приложением.

В случае трехзвенной схемы клиент явно запрашивает один из сервисов (предоставляемых прикладным компонентом), например, передавая ему некоторое сообщение, и получает ответ также в виде сообщения. Клиент направляет запрос во внешнюю среду, ничего не зная о месте расположения сервиса. Имеет место так называемая «поставка функций» клиенту.

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

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

Заключение

Сегодня можно считать, что распределенные базы данных - тема достаточно локальная  и далеко не так актуальная, как  архитектура распределенных систем. В DDB-технологии за последние 2-3 года не было каких-либо существенных новаций (за исключением, быть может, технологии тиражирования данных). Можно считать, что в этой сфере информатики все более или менее устоялось и каких-либо революционных шагов не предвидится. Более интересное направление (включающее DDB) - архитектура, проектирование и реализация распределенных информационных систем. "Горячие" темы в этом направлении - системы с трехзвенной архитектурой, продукты класса middleware, объектно-ориентированные средства разработки распределенных приложений в стандарте CORBA. Их активное применение будет доминировать в отечественной информатике в ближайшие 3-5 лет и станет технологической базой реальных интеграционных проектов.

Мне кажется, что революция произойдет в архитектуре корпоративных  информационных систем. Технологический  взрыв в Intertet, создание и супербурное развитие Всемирной паутины, технология Java, неизбежно отразятся на организации инфраструктуры корпораций. На мой взгляд, очевидные преимущества гипертекстовой организации данных (гибкость, открытость, простота развития и расширения) перед жесткими структурами реляционных баз данных, по своей природе плохо приспособленными для расширения, предопределяют использование HTML в качестве одного из основных средств создания информационного пространства компании. Подход, опирающийся на гипертексты, позволяет без особых проблем интегрировать уже существующие информационные массивы, хранящиеся в базах данных. То, что сейчас называют Intranet - это прообраз будущей корпоративной информационной системы.

Список литературы

http://www.citforum.ru