Как эти проблемы решить в обычных ИС без активного сервера

(технология пассивного сервера или традиционная)

Знание или прикладная информация о предметной области реализуется с помощью обычных языков программирования высокого уровня. То есть прикладная часть фактически для предметной области пишется на обычных процедурных языках. Есть недостатки:

1. Реализация этих алгоритмов и правил перегружает прикладную часть программного обеспечения.

2. При изменении законов предметной области необходимо дорабатывать или изменять разработанное ранее.

 

Задача контроля за создание БД. В традиционной технологии контроль осуществляется с помощью механизмов прямого опроса. То есть фактически разработчик программных средств заранее предусматривает опросы данных через определенный промежуток времени. Недостаток: если интервалы будут слишком короткие – перегрузка ИС. Если интервалы большие – возникает опасность пропустить какие-либо изменения данных и тем самым выдать реакцию на изменения не вовремя.

 

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

 

Преобразование типов данных. Зависит от того языка, на котором всё написано. Может возникать некорректное преобразование и прочее.

 

Итог:

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

Чтобы устранить недостатки, разработана концепция активного сервера.

 

Основные положения концепции активного сервера.

Концепция АС образует третье поколение серверов БД.

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

Концепция АС включает в себя 4 основных положения или момента:

1. Специальные процедуры БД

2. В отдельную часть выносится понятие «событие в БД»

3. Правила (триггеры), которые исполняются почти всегда по определенному событию.

4. Типы данных, которые задаются пользователем (определяются на этапе эксплуатации ИС).

 

Процедуры в составе активного сервера.

Название разное в разных источниках информации – хранимые, перемещаемые. Реализованы на диалекте SQL и являются частью сервера БД.

Включение этих процедур преследует несколько базовых целей:

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

2. Каждая процедура может быть неоднократно использована различными пользователями. При этом (поскольку процедура входит в состав БД) скрипт SQL программы инициализируется, компилируется и прочее только один раз (в момент записи процедуры в программу).

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

4. Хранимые процедуры совместно с другими элементами активного сервера позволяют увеличить вероятность сохранения целостности БД.

 

Как правило, состав и синтаксис языка SQL, на котором реализованы процедуры, отличаются от стандартного языка SQL-запросов (язык описательный становится языком процедур).

 

Правила в составе БД

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

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

На всю таблицу: в этом случае правила программируются на определение ситуации в случае изменения информации в таблицы (добавление новой строчки, удаление и так далее).

К отдельным элементам: с помощью правил определяется реакция на изменение значения определенного реквизита таблицы.

 

Примеры: стандартная ситуация – разработка БД для производственного предприятия. В реальном производстве может возникнуть ситуация: в БД храниться кол-во элементов на складе. Если реальное количество превышает минимального запаса – то всё нормально. А если стало меньше или нуль – при изменении значения срабатывает правило – предупреждение или самостоятельный заказ.

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

 

Правила разрабатываются и программируются на том же диалекте SQL, что и переносимые процедуры.

Исторически первые появились.

 

Понятие «событие» в БД

Механизм событий в БД позволяет прикладным программам и серверу БД уведомлять другие программы о наступлении некоторого события. Данный механизм позволяет синхронизировать работы БД и прикладных программ. Механизм событий предполагает использование двух элементов: во-первых, определение (описание) возможного события – заданно, как и в ПП, так и в процедуре сервера; во-вторых, каждое событие регистрируется для определенных прикладных программ.

При наступлении ситуации, заданной описанием события, сервер автоматически передаёт уведомление всем прикладным программам, в которых это событие зарегистрировано. Каждая прикладная программа реагирует на событие определенным образом, заданным при разработке программного средства.

 

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