Реализация распределенной базы данных с удаленным доступом

 

Рис.1.3. Модель сервера баз данных. 

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

      В AS-модели  процесс, выполняющийся  на компьютере-клиенте, отвечает, как обычно, за интерфейс с пользователем (то есть реализует функции первой группы). Обращаясь за выполнением услуг к прикладному компоненту, этот процесс играет роль клиента приложения (Application Client - AC). Прикладной компонент реализован как группа процессов, выполняющих прикладные функции и называется сервером приложения (Application Server - AS). Все операции над информационными ресурсами выполняются соответствующим компонентом, по отношению к которому AS играет роль клиента. Из прикладных компонентов доступны ресурсы различных типов - базы данных, очереди, почтовые службы и др.  

 
 

Рис.1.4. Модель сервера приложений. 

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

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

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

      Проблемы, возникающие в модели "один-к-одному", решаются в архитектуре систем с  выделенным сервером, способным обрабатывать запросы от многих клиентов. Сервер единственный обладает монополией на управление данными и взаимодействует одновременно со многими клиентами. Логически каждый клиент связан с сервером отдельной нитью (thread) или потоком, по которому пересылаются запросы. Такая архитектура получила название многопотоковой (multi-threaded).

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

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

      В некоторых системах эта проблема решается заменой выделенного сервера на диспетчер или виртуальный сервер (virtual server), который теряет право монопольно распоряжаться данными, выполняя только функции диспетчеризации запросов к актуальным серверам. Таким образом, в архитектуру системы добавляется новый слой, который размещается между клиентом и сервером, что увеличивает трату ресурсов на поддержку баланса загрузки (load balancing) и ограничивает возможности управления взаимодействием "клиент-сервер". Во-первых, становится невозможным направить запрос от конкретного клиента конкретному серверу, во-вторых, серверы становятся равноправными - невозможно устанавливать приоритеты для обслуживания запросов.

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

 

1.2.2 Механизмы реализации активного  ядра

 

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

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

      Данные  требования выливаются в решение  следующих задач.  

1. Необходимо, чтобы база данных в любой момент времени правильно отражала состояние  предметной области - данные должны быть взаимно непротиворечивыми.
2. База данных должна отражать некоторые правила предметной области, законы, по которым она функционирует (business rules).
3. Необходим постоянный контроль за состоянием базы данных, отслеживание всех изменений, и адекватная реакция на них.
4. Необходимо, чтобы возникновение некоторой ситуации в базе данных четко и оперативно влияло на ход выполнения прикладной программы. Многие программы требуют оперативного оповещения о всех происходящих в базе данных изменениях.

 

      Важная  проблема СУБД - контроль типов данных. Тип данных определяется при создании таблицы. Каждому столбцу присваивается один из стандартных типов данных, разрешенных в СУБД. Как правило, это данные стандартных типов - числа, целые и вещественные, строки символов, а также данные типа "дата", "время" и "денежная единица".

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

      Такая архитектура является воплощением  концепции активного сервера. Она реализуется четырьмя сущностями: 

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

1.2.3 Хранимые процедуры

 

      В различных СУБД они носят название хранимых (stored), присоединенных, разделяемых и т.д. Ниже будем пользоваться терминологией, принятой в СУБД InterBase.

      Использование процедур базы данных преследует четыре цели: 

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

 

      В современных СУБД процедура хранится непосредственно в базе данных и  контролируется ее администратором. Она  имеет параметры и возвращает значение. Процедура базы данных создается  оператором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) и содержит определения переменных, операторы SQL (например, SELECT, INSERT), операторы проверки условий (IF/THEN/ ELSE) операторы цикла (FOR, WHILE), а также некоторые другие.

1.2.4 Правила (триггеры)

 

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

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

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

Важнейшая цель механизма правил - обеспечение  целостности базы данных. Один из аспектов целостности - целостность по ссылкам (referential integrity) - относится к связи  двух таблиц между собой. Эта связь  поддерживается внешними ключами. Механизм правил позволяет реализовать и более общие ограничения целостности.

1.2.5 Механизм событий

 

      Механизм  событий в базе данных (database events) позволяет прикладным программам и  серверу базы данных уведомлять другие программы о наступлении в  базе данных определенного события и тем самым синхронизировать их работу. Операторы языка SQL, обеспечивающие уведомление, называют сигнализаторами событий в базе данных (database event alerters). Функции управления событиями целиком ложатся на сервер базы данных.

      Механизм  событий используется следующим образом. Вначале в базе данных для каждого события создается флажок, состояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор CREATE DBEVENT - СОЗДАТЬ СОБЫТИЕ). Далее, во все прикладные программы, на ход выполнения которых может повлиять это событие, включается оператор REGISTER DBEVENT (ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ), который оповещает сервер базы данных, что программа заинтересована в получении сообщения о наступлении события. Теперь любая прикладная программа или процедура базы данных может вызвать событие оператором RAISE DBEVENT (ВЫЗВАТЬ СОБЫТИЕ). Как только событие произошло, каждая зарегистрированная программа может получить его, для чего она должна запросить очередное сообщение из очереди событий (оператор GET DBEVENT - ПОЛУЧИТЬ СОБЫТИЕ) и запросить информацию о событии, в частности, его имя (оператор SQL INQUIRE_SQL).