Студопедия
Случайная страница | ТОМ-1 | ТОМ-2 | ТОМ-3
АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатика
ИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханика
ОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторика
СоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансы
ХимияЧерчениеЭкологияЭкономикаЭлектроника

А.3.2.3.2. Управление посредством триггеров

Читайте также:
  1. V. Права человека, демократия и благое управление
  2. А.3.2.1.2.4. Управление посредством сообщений
  3. АНТИКРИЗИСНОЕ УПРАВЛЕНИЕ
  4. В. Является ли управление нашими эмоциями доступной целью?
  5. Верховное управление в царствование
  6. ГЛОБАЛЬНОЕ УПРАВЛЕНИЕ

Базы данных являются не только средством для пассивного хранения корпоративных данных. К ним также подсоединяются компоненты, реагирующие на определенные события и действия, связанные с приложениями. Эти компоненты инициируют обновление базы данных (активные системы баз данных) и называются триггерами. Понятие «триггер» мы ввели в разделе А.2.3.3.3, когда рассматривали условия целостности при спецификации проекта на уровне модели данных.

Триггеры могут активизировать функции приложений. Например, если в системе планирования складских материалов непрерывно контролируется наличие той или иной детали, то при наступлении события «минимальный уровень запасов не поддерживается» инициируется заказ на закупку.

Говоря кратко, триггеры состоят из описания инициирующих событий, контролируемых условий и действий, инициируемых в случае, если эти условия удовлетворяются. Действия представляют собой операции (т.е. транзакции) обновления данных. Более точно, в соответствии с механизмом событие/триггер (ЕТМ) (Kotz. Triggermechanismus in Datenbanksystemen. 1989, с. 54) триггером называется пара действий, состоящая из результата и собственно действия {Т = (Е,А)}. Таким образом, действие А выполняется, как только происходит событие типа Е.

Например, если в процессе разработки продукта по завершении этапа «фаза проектирования 1» запускается процедура проверки результата, то триггер будет выглядеть следующим образом:

EVENT end_of_design_phase_l (design object: DB_ID);

ACTION verification_procedure_A (verif_obj: DB_ID)

=<Verification of verif_obj>;

TRIGGER Tl =

ON end_of_design_phase_l

DO verification_procedure_A (design_object);

(Kotz. Triggermechanismus in Datenbanksystemen. 1989, c. 64).

Здесь к событиям и действиям привязываются идентификаторы различных обрабатываемых объектов. В данном примере проектируемый объект именуется design_object (с идентификатором базы данных DB_ID), а объект, подлежащий проверке действием, именуется verification_object (с идентификатором базы данных DB_ID).

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

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

Механизм событие/триггер (ЕТМ) можно непосредственно связать с СДП, так как события уже введены, а действия соответствуют функциональным модулям. Триггеры характеризуют контекст между Е и А, совпадая с линиями соединений между событиями и функциями СДП.

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

На рис. 124 концепция триггеров представлена в виде метамодели, где класс СОБЫТИЕ является связующим звеном с уровнем определения требований.

Рис. 124. Структура концепции триггеров

 

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

После инициации того или иного триггера различные состояния базы данных могут проверяться в соответствии с правилами, описанными для триггеров. На это указывает ассоциация УСЛОВИЯ, связывающая ТРИГГЕР с ИНФОРМАЦИОННЫМ ОБЪЕКТОМ.

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


Дата добавления: 2015-08-03; просмотров: 202 | Нарушение авторских прав


Читайте в этой же книге: А.3.2.1.1.1. Объектно-ориентированные диаграммы классов | А.3.2.1.1.3. Поток данных | А.3.2.1.1.4. Ассоциация экранов | А.3.2.1.2.1. Правило СУД | А.3.2.1.2.3. Диаграммы состояний | А.3.2.1.2.4. Управление посредством сообщений | А.3.2.1.2.5. Связывание объектно-ориентированного моделирования и СДП | А.3.2.2. Конфигурирование | А.3.2.3.1.1. Привязка схемы | А.3.2.3.1.2. Выведение структур управления |
<== предыдущая страница | следующая страница ==>
А.3.2.3.1.3. Транзакции баз данных| А.3.2.3.3.1. Общая детализация

mybiblioteka.su - 2015-2024 год. (0.008 сек.)