2.3.3. Концепция активного сервера бд

Концепция активного сервера направлена на решение следующих проблем:

• поддержка целостности данных и логики предметной области;

• мониторинг и контроль данных.

Концепция активного сервера опирается на следующие приницпы:

• процедуры базы данных;

• правила (триггеры);

• события в базе данных.

Процедуры БД (storedprocedures– хранимые процедуры, также присоединенные, разделяемые процедуры). Цели использования хранимых процедур:

• концентрация бизнес-логики;

• повторное использование кода процедур;

• снижение трафика сети;

• поддержка целостности БД.

Механизм правил позволяет однотипно обрабатывать определенные стандартные ситуации в БД (добавление, удаление, изменение записи).

Механизм событий БД (databaseevents) позволяет серверу БД уведомлять другие программы о наступлении в БД определенных ситуаций. ОператорыSQL, обеспечивающие уведомление, называют сигнализаторами событий БД (databaseeventalerters). Каждая программа, зарегистрировавшаяся вSQL-сервере как слушатель событий, может опрашивать состояние событий и узнавать об их фиксации. Наступление события может быть установлено в результате некоторой операции с данными, например, в результате вставки в таблицу записи с определенным значением наблюдаемой величины.

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

2.3.4. Схемы размещения и доступа к данным в распределенных бд

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

1. Фрагментация – возможность разделения любой записи на некотрое количество частей, называемых фрпагментами, котопрые затем могут быть распределены по различным узлам. Два основных типа фрагментации: горизонтальная и вертикальная. В первом случае фрагменты представляют соборй подмножесво строк, во втором – столбцов (атрибутов).

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

3. Репликация – возможность поддержки актуальной копии некоторого фрагмента на нескольких различных узлах.

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

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

1. Централизованное размещение. Стратегия предусматривает создание на одном из узлов единственной БД, длоступ к которой будует иметь все пользователи сети.

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

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

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

2.3.4.1. Технологии и средства удаленного доступа

При необходимости организации удаленного доступа используют так называемое ПО промежуточного уровня (middleware), которое можно разделить на две категории:

• ПО доступа к БД (например, ODBC-интерфейсы иSQL-шлюзы);

• ПО межмодульного взаимодействия (системы вызова удаленных процедур – RPC–RemoteProcedureCall, мониторы обработки транзакций –TPM–TransactionProcessingMonitor).

2.3.4.2. ODBC

Чтобы практически реализовать унифицированный доступ к разным СУБД посредством разных сетевых протоколов, в ОDВС каждой паре СУБД/протокол соответствует свой DLL-драйвер.

Рисунок 5. Архитектура ODBC

ODBC-архитектура включает в себя:

Приложение. Обрабатывает данные, вызывает ODBC-функции для выполнения SQL-инструкций, получает результаты.

Менеджер драйверов. Загружает драйверы по запросу приложений.

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

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

ODBC опирается на спецификацию SQL CLI (Call Level Interface), входящую в стандарт SQL. Интерфейс ODBC API реализован как набор DLL-библиотек под Windows. Библиотека ODBC.dll содержит функции вызовов специализированных драйверов для различных БД.

2.3.4.3. RPC

Основные идеи, реализованные в RPC:

• взаимодействие во многих случаях имеет асимметричный (клиент-серверный) характер, что на логическом уровне описывается как вызов процедуры;

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

Интерфейс взаимодействия между клиентской и серверной частями описывается на языке IDL(Interface Definition Language). Компилятор транслирует описание интерфейса в заглушку (суррогат) клиента (client stub). Формируемый при этом заголовок интерфейса включается в приложение клиента. Заглушка клиента, к которой обращается приложение клиента, оформляет вызов удаленной процедуры. Функции библиотекиRPCформирует из параметров вызова пакет, который доставляется через протоколыRPCфункции приема аналогичной библиотеки на стороне сервера. БиблиотекаRPCна серверной стороне распаковывает параметры и передает их заглушке сервера (server stub). Заглушка сервера формирует локальный вызов сервера (см. рис. 4). Заглушка сервера и заголовок интерфейса, используемый серверным приложением, компилируются для платформы сервера.

Рисунок 4. Архитектура RPC