
Текст триггера
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 ;/
Логика представления.
Под логикой представления подразумевается часть приложения, обеспечивающая связь с инструментами конечного пользователя. Таким в нашем случае является клиентское приложение, которое управляет непосредственно вводом/выводом информации.
Логика базы данных.
Под логикой базы данных подразумевается часть приложения, манипулирующая данными приложения. В реляционной базе данных подобные действия обеспечиваются с помощью языка SQL (Structured Query Language, язык структурированных запросов).
Механизм обращения к базе данных.
Непосредственная работа с базой данных, выполняемая СУБД. К механизмам обращения относятся средства СУБД, которые размещаются на сервере БД, такие как - хранимые процедуры и функции, триггеры, обработчики исключительных ситуаций.
Для того чтобы выяснить какие нам потребуются механизмы обращения к БД рассмотрим возможные сценарии работы данной системы. Сначала перечислим ряд основных режимов использования:
Клиент создаёт новую экономическую модель.
Клиент добавляет новую версию расчетов в БД.
Клиент удаляет одну из версий расчетов из БД.
Клиент создает новый экономический параметр.
Клиент удаляет один из параметров.
Каждый из основных сценариев может включать в себя ряд вторичных:
Не существует версии, которую требуется удалить
Версия расчетов, которую надо добавить, уже существует.
Экономический параметр уже существует.
Экономический параметр не существует.
Для системы подобной сложности, наверное, будут выявлены еще десятки основных и вторичных сценариев, но для конкретного случая вышеперечисленных режимов достаточно.
Рассмотрим некоторые из них более подробно:
Д
обавление новой версии расчетов.
Создание нового экономического параметра:
Создание
нового параметра происходит в три этапа:
Добавление нового имени параметра таблицу Экономические параметры (PARAMS).
Создание связи параметра с индексами в таблице Взаимосвязи индексов и параметров (INTER).
Создание связи параметра со значениями в таблице Взаимосвязи параметров со значениями (PARAM).
Текст процедуры создания нового параметра приведен в приложении.
Удаление экономического параметра.
Принцип работы этого сценария похож на предыдущий, но его этапы выполняются в обратном порядке. Это обусловлено тем, что имя параметра в таблице PARAM является первичным ключом для таблиц PARAMS, INTER и VAR_VALUE.
Текст процедуры удаления параметра приведен в приложении.
Механизм транзакций.
Архитектура клиент/сервер построена на взаимодействии клиентской и серверной частей приложения, для реализации которого необходим определенный механизм. Существует три базовых вида взаимодействия между процессами:
Конвейеры (pipes)
Удаленный вызов процедур (RPC)
Взаимодействие клиент/сервер через SQL
В нашем случае мы воспользовались только третьим способом.
Необходимо определить, что такое транзакция. Транзакция – это единица обмена и обработки информации между локальной и уделенной программами, которая отражает логически законченную операцию или результат. Объект-транзакция является агентом, ответственным за выполнение некоторого удаленного действия, а, следовательно, отчетливо отделяет само действие от его реализации.
Действительно, транзакция является основным высокоуровневым видом взаимодействия сервера и клиента, а также между клиентами. На основе этого понятия можно выполнить конкретный анализ вариантов использования. Принципиально можно рассматривать все основные функции в нашей системе как транзакции. Например, создание нового экономического параметра является системной транзакцией.
Для каждой транзакции полный перечень операций, которые она должна выполнить, более того, если в некоторой транзакции операция выполняется над несколькими строками таблицы, то либо все действия должны быть выполнены, либо содержимое таблицы должно быть оставлено без изменений. Следовательно, когда мы посылаем транзакцию, мы имеем в виду выполнение группы операций как одного целого.
При благополучном завершении транзакции мы должны зафиксировать ее результаты (commit). Невыполнение транзакции может произойти в силу ряда причин, в том числе из-за отказов сети или блокировке информации другими клиентами. В таких случаях выполняется откат в исходное состояние (rollback).
Принятое архитектурное решение позволяет сложному пользовательскому приложению выполнять наборы SQL-операторов. Все детали реализации механизма управления транзакциями оказываются скрытыми от простых клиентов, которым достаточно выполнять некоторые общие типы транзакций.