Тригерна обробка

Тригерні процедури виконуються в разі настання події по модифікації даних, яке виражається в додаванні, зміну або видалення даних з таблиці. За своєю суттю триггерная процедура абсолютно ідентична збереженій процедурі, але не може бути запущена користувачем, не може приймати вихідні дані і повертати результат обробки.

Таким чином, моделювання тригера зводиться до обробки даних, отриманих при виконанні операції додавання, зміни або видалення даних. Відповідно структура вхідних даних представляється структурою таблиці, модифікація даних якої ініціювала виконання критичної процедури. При цьому якщо виконується дію зміни даних в таблиці, то вхідних потоків може бути два: один потік відображає відомості, які були внесені в таблиці, а другий потік дані, які були в таблиці до внесення нових відомостей. Обробці ж в тригері підлягають тільки записи, які були задіяні в операції модифікації даних, а всі інші записи змінною ініціює таблиці залишаються невидимими для тригера і можуть бути отримані тільки в вигляді результату запиту до цієї таблиці.

приклад

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

Як і для збереженої процедури, в моделі критичної операції визначаються вихідні дані і початкові і кінцеві операції (рис. 5.75).

image381

Мал. 5.75. Підготовка процесу для моделювання тригера


Оскільки тригер не може ні приймати, ні повертати дані, то початковим і кінцевим елементами даних є структура таблиці, яка ініціювала його виконання. В даному випадку вхідні дані відображають нові дані, які були додані в таблицю надходження товарів. Це відбивається назвою першого завдання "Отримання доданої записи". Саме ці дані і будуть оброблятися в процедурі. Варто зауважити, що початкова операція може бути представлена ​​у вигляді перевірки доцільності виконання критичної обробки.


Подальша робота процедури зводиться до перевірки існування запису в таблиці сховища загальної кількості товарів на складах і у відповідності з отриманим результатом додаванню нового запису або зміни наявного значення.

Для початку необхідно визначити вибірку для перевірки наявності запису (рис. 5.76), що в цей раз буде описано безпосередньо в процедурі, а не в глобальному процесі.

image382

Мал. 5.76. Додавання перевірки існування запису в сховище


Результатом операції є повернення ознаки успішності пошуку. Якщо запис нс знайдена, то генерується комбінація значень для додавання даних і виконується операція додавання (рис. 5.77).

У разі, коли запис в сховище існує, необхідно внести зміни, що виконується іншим завданням (рис. 5.78).

Рятувальна операція зміни даних в сховищі пов'язане з необхідністю не тільки виконати привласнення даних, але і вибрати потрібний запис. Оскільки в даному випадку немає необхідності використовувати інші таблиці, крім сховища, то вибірка представляється простий і описується тільки правилами обмежень. У разі, коли потрібно використовувати додаткові таблиці, рекомендується сформувати спеціальний процес але обмеження записів в змінною таблиці, а потім використовувати результат в якості умов обмеження.

У моделі для вказівки правил зміни і обмеження вводиться коментар до операції зміни, де вказуються операції присвоєння та через розмежувальну лінію - операції обмеження.

В результаті виходить повна модель триггерного дії, яка може бути реалізована в СУБД.


image383

Мал. 5.77. Додавання операції внесення нових даних в сховищі


image384

Мал. 5.78. Додавання операції зміни сховища



 
< Попер   ЗМІСТ   Наст >