· Использование процедур баз данных позволяет значительно снизить трафик сети в системах с архитектурой "клиент-сервер". Прикладная программа, вызывающая процедуру, передает серверу лишь ее имя и параметры. В процедуре, как правило, концентрируются повторяющиеся фрагменты из нескольких прикладных программ. Если бы эти фрагменты остались частью программы, они загружали бы сеть посылкой полных SQL-запросов.
· Процедуры базы данных в сочетании с правилами, предоставляют администратору мощные средства поддержки целостности базы данных.
В современных СУБД процедура хранится непосредственно в базе данных и контролируется ее администратором. Она имеет параметры и возвращает значение. Процедура базы данных создается оператором CREATE PROCEDURE (СОЗДАТЬ ПРОЦЕДУРУ) и содержит определения переменных, операторы SQL (например, SELECT, INSERT), операторы проверки условий (IF/THEN/ ELSE) операторы цикла (FOR, WHILE), а также некоторые другие.
Механизм правил (триггеров) позволяет программировать обработку ситуаций, возникающих при любых изменениях в базе данных. Правило придается таблице базы данных и применяется при выполнении над таблицей операций включения, удаления или обновления строк.
Применение правила заключается в проверке сформулированных в нем условий, при выполнении которых происходит вызов специфицированной внутри правила процедуры базы данных. Важно, что правило может быть применено как до, так и после выполнения обновления, следовательно, возможна отмена операции.
Таким образом, правило позволяет определить реакцию сервера на любое изменение состояния базы данных. Правила (так же, как и процедуры) хранятся непосредственно в базе данных независимо от прикладных программ. Одна из целей механизма правил - отражение некоторых внешних правил деятельности организации.
Важнейшая цель механизма правил - обеспечение целостности базы данных. Один из аспектов целостности - целостность по ссылкам (referential integrity) - относится к связи двух таблиц между собой. Эта связь поддерживается внешними ключами. Механизм правил позволяет реализовать и более общие ограничения целостности.
Механизм событий в базе данных (database events) позволяет прикладным программам и серверу базы данных уведомлять другие программы о наступлении в базе данных определенного события и тем самым синхронизировать их работу. Операторы языка SQL, обеспечивающие уведомление, называют сигнализаторами событий в базе данных (database event alerters). Функции управления событиями целиком ложатся на сервер базы данных.
Механизм событий используется следующим образом. Вначале в базе данных для каждого события создается флажок, состояние которого будет оповещать прикладные программы о том, что некоторое событие имело место (оператор CREATE DBEVENT - СОЗДАТЬ СОБЫТИЕ). Далее, во все прикладные программы, на ход выполнения которых может повлиять это событие, включается оператор REGISTER DBEVENT (ЗАРЕГИСТРИРОВАТЬ СОБЫТИЕ), который оповещает сервер базы данных, что программа заинтересована в получении сообщения о наступлении события. Теперь любая прикладная программа или процедура базы данных может вызвать событие оператором RAISE DBEVENT (ВЫЗВАТЬ СОБЫТИЕ). Как только событие произошло, каждая зарегистрированная программа может получить его, для чего она должна запросить очередное сообщение из очереди событий (оператор GET DBEVENT - ПОЛУЧИТЬ СОБЫТИЕ) и запросить информацию о событии, в частности, его имя (оператор SQL INQUIRE_SQL).
Одна из главных особенностей современных информационных систем - распределенный характер. Возрастает их масштаб, они охватывают все больше число точек по всему миру. Современный уровень принятия решений, оперативное управление информационными ресурсами требует все большей их децентрализации. Информационные системы находятся в постоянном развитии - в них добавляются новые сегменты, расширяется диапазон функций уже действующих.
Главная проблема таких систем - организация обработки распределенных данных. Данные находятся на компьютерах различных моделей и производителей, функционирующих под управлением различных операционных систем, а доступ к данным осуществляется разнородным программным обеспечением. Сами компьютеры территориально удалены друг от друга и находятся в различных географических точках планеты.
Ответом на задачи реальной жизни стали две технологии: технология распределенных баз данных (Distributed Database) и технология тиражирования данных (Data Replication).
Под распределенной базой данных подразумевают базу, включающую фрагменты из нескольких баз данных, которые располагаются на различных узлах сети компьютеров, и, возможно, управляются различными СУБД. Распределенная база данных выглядит с точки зрения пользователей и прикладных программ как обычная локальная база. В этом смысле слово "распределенная" отражает способ организации базы данных, но не внешнюю ее характеристику ("распределенность" базы не должна быть видна извне).
В отличие от распределенных баз, тиражирование данных предполагает отказ от их физического распределения и опирается на идею дублирования данных в различных узлах сети компьютеров.
Ранее были рассмотрены четыре модели технологии "клиент-сервер". Традиционной и наиболее популярной является модель доступа к удаленным данным (RDA-модель). В соответствии с этой моделью, имеется компьютер, на котором запускаются программы переднего плана (в которых реализованы как функции интерфейса с пользователем, так и прикладные функции) - клиент (называемый обычно локальным узлом - local node), соединенный в сети с компьютером, на котором выполняется сервер базы данных и находится сама база данных (обычно его называют удаленным узлом - remote node). Все проблемы, возникающие при взаимодействии клиента и сервера, должен решать специальный компонент СУБД, называемый коммуникационным сервером (Communication Server, DBMS Server Net). Для поддержки взаимодействия клиента и сервера он должен функционировать на удаленном узле; в то же время на локальном узле должна выполняться программа связи, взаимодействующая с коммуникационным сервером (DBMS Client Net).
В основу взаимодействия прикладных программ - клиентов и сервера базы данных, положен ряд фундаментальных принципов, определяющих функциональные возможности современных СУБД в части, касающейся сетевого взаимодействия и распределенной обработки данных, среди которых:
· Прозрачность расположения;
· Прозрачность сети;
· Автоматическое преобразование форматов данных;
· Автоматическая трансляция кодов;
· Межоперабельность;
· Прозрачность расположения.
Прозрачный (для пользователя) доступ к удаленным данным предполагает использование в прикладных программах такого интерфейса с сервером БД, который позволяет переносить данные в сети с одного узла на другой, не требуя при этом модификации текста программы. Иными словами, доступ к информационным ресурсам должен быть полностью прозрачен относительно расположения данных.
Любой пользователь или любая прикладная программа оперирует с одной или несколькими базами данных. В том случае, когда прикладная программа и сервер БД выполняются на одном и том же узле, проблемы расположения не возникает. Для получения доступа к базе данных, пользователю или программе достаточно указать имя базы.
Однако в том случае, когда прикладная программа запускается на локальном узле, а база данных находится на удаленном, возникает проблема идентификации удаленного узла. Для того, чтобы получить доступ к базе данных на удаленном узле, необходимо указать имя удаленного узла и имя базы данных. Если использовать жестко фиксированное имя узла в паре "имя_узла, имя_БД", то прикладная программа становится зависимой от расположения БД. Например, обращение к БД "host::stock", где первый компонент есть имя узла, будет зависимым от расположения.
Одно из возможных решений этой проблемы состоит в использовании виртуальных имен узлов. Управление ими обеспечивается специальным программным компонентом СУБД - сервером имен (Name Server), который адресует запросы клиентов к серверам.
При установке компонентов DBMS Client Net на локальных узлах выполняется процедура идентификации узлов, когда реальному имени удаленного узла ставится в соответствие виртуальное имя, которое затем используется при обращении к базе данных. Если база данных перенесена на другой узел, то никаких изменений в прикладную программу вносить не нужно - достаточно лишь поставить в соответствие виртуальному имени имя нового узла.
Клиент и сервер взаимодействуют по сети с конкретной топологией; для поддержки взаимодействия всегда используется определенный протокол. Следовательно, оно должно быть организовано таким образом, чтобы обеспечивать независимость как от используемого сетевого аппаратного обеспечения, так и от протоколов сетевого обмена. Чтобы обеспечить прозрачный доступ пользователей и программ к удаленным данным в сети, объединяющей разнородные компьютеры, коммуникационный сервер должен поддерживать как можно более широкий диапазон сетевых протоколов (TCP/IP, DECnet, SNA, SPX/IPX, NetBIOS, AppleTalk, и др.).
Как только несколько компьютеров различных моделей под управлением различных операционных систем соединяются в сеть, сразу возникает вопрос о согласовании форматов представления данных. Действительно, в сети могут быть компьютеры, отличающиеся разрядностью (16-ти, 32-х и 64-х разрядные процессоры), порядком следования байт в слове, представлением чисел с плавающей точкой и т.д. Задача коммуникационного сервера состоит в том, чтобы на уровне обмена данными обеспечить согласование форматов между удаленным и локальным узлами с тем, чтобы данные, извлеченные сервером из базы на удаленном узле и переданные по сети, были правильно истолкованы прикладной программой на локальном узле.