Текст триггера

drop exception sdp_icpe; create exception sdp_icpe "Parent does not exist. Cannot create child."; /* Вставка триггера ti_insert для таблицы INTER*/ set term /; create trigger ti_inter for INTER before insert as declare variable numrows integer; begin /* запись в PARAMS должна уже существовать когда вставляется запись в INTER */ if (new.ID is not null) then begin select count(*) from PARAMS where PARAMS.ID = new.ID into :numrows; if (numrows = 0) then begin exception sdp_icpe; end end /* запись в INDEXES должна уже существовать когда вставляется запись в INTER */ if (new.IID is not null) then begin select count(*) from INDEXES where INDEXES.IID = new.IID into :numrows; if (numrows = 0) then begin exception sdp_icpe; end end end;/ set term ;/ триггер ti_param

имя таблицы: Связи параметров со значениями кодовое имя: PARAM триггер: ti_param тип: InsertTrigger , Default Trigger

Текст триггера

drop exception sdp_icpe; create exception sdp_icpe "Parent does not exist. Cannot create child."; /* Вставка триггера ti_param для таблицы PARAM*/ set term /; create trigger ti_param for PARAM before insert as declare variable numrows integer; begin /* запись в PARAMS должна уже существовать когда вставляется запись в PARAM */ if (new.ID is not null) then begin select count(*) from PARAMS where PARAMS.ID = new.ID into :numrows; if (numrows = 0) then begin exception sdp_icpe; end end /* запись в INDEXES должна уже существовать когда вставляется запись в PARAM */ if (new.IID is not null) then begin select count(*) from INDEXES where INDEXES.IID = new.IID into :numrows; if (numrows = 0) then begin exception sdp_icpe; end end end;/ set term ;/

триггер ti_var_value

имя таблицы: Значения переменных кодовое имя: VAR_VALUE триггер: ti_var_value тип: InsertTrigger , Default Trigger

Текст триггера

drop exception sdp_icpe; create exception sdp_icpe "Parent does not exist. Cannot create child."; /* Вставка триггера ti_var_value для таблицы VAR_VALUE*/ set term /; create trigger ti_var_value for VAR_VALUE before insert as declare variable numrows integer; begin /*запись в PARAMS должна уже существовать когда вставляется запись в VAR_VALUE */ if (new.ID is not null) then begin select count(*) from PARAMS where PARAMS.ID = new.ID into :numrows; if (numrows = 0) then begin exception sdp_icpe; end end /*запись в VERSOIN должна уже существовать когда вставляется запись в VAR_VALUE */ if (new.VER is not null) then begin select count(*) from VERSION where VERSION.NUM = new.VER into :numrows; if (numrows = 0) then begin exception sdp_icpe; end end /* запись в PARAM должна уже существовать когда вставляется запись в VAR_VALUE */ if (new.NUM is not null) then begin select count(*) from PARAM where PARAM.NUM = new.NUM into :numrows; if (numrows = 0) then begin exception sdp_icpe; end end end;/ set term ;/

3. Логика представления.

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

4. Логика базы данных.

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

5. Механизм обращения к базе данных.

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

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

• Клиент создаёт новую экономическую модель.

• Клиент добавляет новую версию расчетов в БД.

• Клиент удаляет одну из версий расчетов из БД.

• Клиент создает новый экономический параметр.

• Клиент удаляет один из параметров.

Каждый из основных сценариев может включать в себя ряд вторичных:

• Не существует версии, которую требуется удалить

• Версия расчетов, которую надо добавить, уже существует.

• Экономический параметр уже существует.

• Экономический параметр не существует.

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

Рассмотрим некоторые из них более подробно:

1. Добавление новой версии расчетов.

2. Создание нового экономического параметра:

Создание нового параметра происходит в три этапа:

1. Добавление нового имени параметра таблицу Экономические параметры (PARAMS).

2. Создание связи параметра с индексами в таблице Взаимосвязи индексов и параметров (INTER).

3. Создание связи параметра со значениями в таблице Взаимосвязи параметров со значениями (PARAM).

Текст процедуры создания нового параметра приведен в приложении.

3. Удаление экономического параметра.

Принцип работы этого сценария похож на предыдущий, но его этапы выполняются в обратном порядке. Это обусловлено тем, что имя параметра в таблице PARAM является первичным ключом для таблиц PARAMS, INTER и VAR_VALUE.

Текст процедуры удаления параметра приведен в приложении.

6. Механизм транзакций.

Архитектура клиент/сервер построена на взаимодействии клиентской и серверной частей приложения, для реализации которого необходим определенный механизм. Существует три базовых вида взаимодействия между процессами:

• Конвейеры (pipes)

• Удаленный вызов процедур (RPC)

• Взаимодействие клиент/сервер через SQL

В нашем случае мы воспользовались только третьим способом.

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

Действительно, транзакция является основным высокоуровневым видом взаимодействия сервера и клиента, а также между клиентами. На основе этого понятия можно выполнить конкретный анализ вариантов использования. Принципиально можно рассматривать все основные функции в нашей системе как транзакции. Например, создание нового экономического параметра является системной транзакцией.

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

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

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