SQL Programmin language

1. Мова PSQL

2. 1. Основи розробки модулів
PSQLВ СУБД існує можлдивість створення виконуваних модулів, представлених розробниками у
вигляді вихідних кодів. Такі коди виконуються повністю на сервері, повертаючи при необхідності
клієнтського додатку значення, отримані в результаті виконання. Мова, який надає таку
можливість для сервера СУБД, називається PSQL (процедурний SQL). Це простий, але потужний
набір розширень мови SQL, яких немає в стандарті SQL2, але які включені до стандарту мови
SQL3.
PSQL - це мова програмування, що використовується для написання збережених процедур і
тригерів в СУБД. Вона може включати стандартні запити SQL, а також розширення мови SQL.
Розширення мови PSQL в Firebird включають такі мовні елементи:
•Оголошення та ініціалізація локальних змінних, оператор присвоювання;
•Умовні оператори (оператор розгалуження і оператор циклу);
•Явний і неявний курсори для виконання циклу при перегляді рядків;
•Генератор послідовності цілих значень;
•Генерація повідомлення про виняткову ситуацію і переривання виконання коду тригера або
збереженої процедури;
•Оператор EXECUTE STATEMENT для виконання запитів DML і DDL у модулі.
Існує наступний ряд обмежень мови для кодів в модулях PSQL:
•Запити мови визначення даних (DDL) не дозволені в PSQL (передача DDL-запиту можлива
тільки за допомогою EXECUTE STATEMENT);
•Команди управління транзакціями неприпустимі в PSQL, тому що збережені процедури і
тригери завжди виконуються в контексті існуючої клієнтської транзакції, а не всі СУБД
підтримуєють вкладені транзакції.

3. 1. Основи розробки модулів PSQL. Змінні
У модулях на PSQL може бути використано чотири типи змінних, причому можливість
використання конкретної змінної визначається тим, чи є модуль збереженої процедурою або
тригером. Розрізняють локальні змінні, контекстні змінні, вхідні параметри та вихідні
параметри.
Локальні змінні використовуються для зберігання значень як в ЗП, так і в тригерах.
Оголошення локальної змінної в тілі тригера або збереженої процедури здійснюється за
допомогою наступного оператора:
Для кожної змінної використовується свій оператор DECLARE VARIABLE, який закінчується “;”.
Правило складання імен локальних змінних таке ж, як і для будь-яких інших ідентифікаторів
мови SQL. В якості типу даних можна вказувати один із системних типів , раніше створений домен
або конструкцію TYPE OF <имя_домена>, яка витягує тільки тип з існуючого домену (тобто
обмеження і значення за замовчуванням, визначені для даного домену, не враховуються).
Наприклад, щоб оголосити змінну x цілого типу, необхідно використовувати наступний
оператор: DECLARE VARIABLE x INTEGER;.
Оголосити змінну y на домені BOOLEAN можна наступним чином:
DECLARE VARIABLE y BOOLEAN;.
Всі локальні змінні повинні бути оголошені до першого виконуваного блоку тригера
(процедури).

4. 1. Основи розробки модулів PSQL. Змінні
Оголошеним змінним надалі можуть присвоюватися різні значення за допомогою оператора
присвоєння, що має наступний синтаксис:
імя_локальної_змінної = <вираз>;.
Змінним повинні присвоюватися значення того типу даних, з яким вони були оголошені.
Допускається при оголошенні локальної змінної відразу ж її ініціалізувати, наприклад таким
чином:
DECLARE VARIABLE x INTEGER = 123; або DECLARE VARIABLE x INTEGER DEFAULT 123;.
СУБД робить доступним множину змінних, які підтримуються в контексті поточного з'єднання
клієнта і його діяльності. Ці контекстні змінні доступні для використання у PSQL. Більшість
контекстних змінних процедурної мови використовуються тільки в тригерах. Існує тільки одна
контекстна змінна PSQL, яку можна використовувати як в тригерах, так і в ЗП. Це змінна
ROW_COUNT, що повертає кількість рядків, отриманих виконаним запитом DML або SELECT.
В тригерах для реалізації відстеження цілісності даних використовуються контекстні змінні
OLD.столбец і NEW.столбец. Ці змінні зберігають старі і нові значення зазначеного стовпця
таблиці, коли виконується запит на модифікацію даних. Також в тригерах можуть
використовуватися логічні контекстні змінні UPDATING, INSERTING і DELETING для задання певних
дій в залежності від типу події DML, для якого спрацьовує тригер.
Вхідні параметри недоступні для використання в тригерах. Вони використовуються для
передачі значень збереженим процедурам з клієнтських додатків або інших збережених
процедур.
Вихідні параметри також недоступні для використання в тригерах. Вони використовуються
для повернення значень з ЗП об'єктам, що викликали їх.

5. 1. Основи розробки модулів PSQL. Умовні оператори
Оператор розгалуження IF має наступний формат:
де
Для організації циклу з передумовою можна використовувати оператор WHILE,
який має наступний формат:

6. 1. Основи розробки модулів PSQL. Курсори
У більшості випадків запит до РБД повертає кілька записів даних, але додаток за
один раз обробляє лише один запис. При модифікації, видаленні або додаванні даних
за допомогою запитів DML дії виконуються також над окремим записом (рядком)
таблиці. У цій ситуації на перший план виступає концепція курсору.
Під курсором розуміють одержаний при виконанні запиту результуючий набір і
пов'язаний з ним покажчик поточного запису. Зазвичай курсори використовуються для
вибору з БД деякої підмножини збереженої в ній інформації. У кожен момент часу
прикладною програмою може бути оброблений один рядок курсору. Після
позиціонування курсору над цим рядком можна виконувати різні дії.
Курсори часто застосовуються в запитах SQL, вбудованих в прикладні програми,
написані на мовах процедурного типу. PSQL підтримує два типи курсорів: явні і неявні.
Реалізація неявного курсору представлена наступною конструкцією:​​
FOR SELECT ... INTO ... DO ....
Вона повністю реалізує синтаксис циклу і надає можливість послідовної
порядкової обробки набору даних курсору в циклі FOR.
Явний курсор (змінний або іменований курсор), являє собою об'єкт, який
розробник може явно оголошувати, відкривати і закривати (на відміну від неявного
курсору, що не потребує оголошення, відкриття і закриття). Для управління явним
курсором використовуються команди DECLARE CURSOR, OPEN, FETCH і CLOSE.

7. 1. Основи розробки модулів PSQL. Неявні курсори
Запит SELECT повертає таблицю результатів запиту, але додатки не завжди можуть
ефективно працювати з результуючим набором. Виникає проблема доступу до кожного
рядка цієї таблиці, яка може бути вирішена при використанні неявного курсору:
де

8. 1. Основи розробки модулів PSQL. Неявні курсори
Курсори дозволяють забезпечити оновлення або знищення рядка, на якому в даний
момент встановлений курсор, за допомогою конструкції WHERE CURRENT OF в запиті
UPDATE або DELETE.
У цьому випадку <группа_операторов> при оновленні рядка, на якому встановлений
курсор, має виглядати наступним чином:
При знищенні рядка, на якому встановлений курсор, <группа_операторов> повинна
виглядати таким чином:
За одну операцію оновлення можуть бути змінені декілька стовпців поточного рядка
курсору, але всі вони повинні належати одній таблиці. Якщо виконується знищення, то буде
знищений рядок, встановлений поточним в курсорі.​​

9. 1. Основи розробки модулів PSQL. Явні курсори
Робота з явним курсором припускає його визначення, зв'язування з ним запиту SELECT,
відкриття, вибірку даних із курсора і його закриття.
Для визначення явного курсора і зв'язування з ним запиту SELECT використовується
наступний оператор:
Для відкриття курсору використовується наступний оператор:
Для вибірки даних з курсора використовується наступний оператор:
Для закриття курсору використовується наступний оператор:
Команди OPEN, FETCH і CLOSE, які використовуються для роботи з явним курсором, не
можна застосовувати для роботи з неявним курсором.

10. 1. Основи розробки модулів PSQL. Явні курсори
Оголошення курсору повинно поміщатися на початку тригера, ЗП або неіменованого
виконуваного блоку (заданого за допомогою EXECUTE BLOCK), подібно оголошенню звичайних
локальних змінних.
Наприклад, в тілі ЗП оголошення та використання явного курсору може виглядати наступним
чином:
Імена курсорів повинні бути унікальними в контексті того модуля, де курсори
використовуються. Тобто кожен явний і неявний курсор (якщо для нього оголошено ім'я за
допомогою конструкції AS CURSOR имя_курсора) повинні мати різні імена. Однак допускається збіг
імені курсору з ім'ям будь-якої змінної, яка використовується в тому ж самому модулі.
Явний курсор, як і неявний, допускає позиційоване оновлення та знищення.
Спроби відкрити курсор, який вже відкритий, так само як і спроби вибрати інформацію з вже
закритого курсору або закрити його знову, будуть невдалі. Всі курсори, які явно не були закриті,
будуть закриті автоматично при виході з поточного PSQL блоку, процедури або тригера.

11. 1. Основи розробки модулів PSQL. Сценарії
SQL сценарій (файл-сценарій, скрипт) - це текстовий файл, що містить запити і оператори SQL і
зазвичай має розширення sql. Всі запити, команди і оператори SQL сценарію виконуються
послідовно в тому порядку, в якому вони слідують у скрипті, і мають бути відокремлені один від
одного роздільником (крапкою з комою або тим, який заданий за допомогою оператора SET TERM).
У файлі SQL сценарію рекомендується використовувати різні розділювачі для поділу внутрішніх
операторів ЗП або тригера від зовнішніх запитів (команд).
Новий зовнішній роздільник визначається оператором SET TERM в наступному форматі:
Після цього крапка з комою буде використовуватися для розділення внутрішніх операторів ЗП
або тригера, а два знаки оклику – для відділення ЗП, тригерів та інших запитів (команд) один від
одного у файлі SQL сценарію. Після використання нового роздільника відновити старий роздільник
можна наступною командою:
У загальному випадку скрипт может містити запити модифікації БД (мова DDL), запити зміни
даних (мова DML) та команди фіксації / скасування транзакцій. Запити вибірки даних в скрипті
використовувати не можна (крім передачі їх у рядку за допомогою оператора EXECUTE STATEMENT
або для задання набору даних курсора).

12. 1. Основи розробки модулів PSQL. Генератори
Генератор послідовності - це спеціальний об'єкт БД для отримання цілочисельних значень з
певним кроком. Кожний генератор має унікальне ім'я і поточне значення. Для створення
генератора використовується наступний запит:
При виконанні такого запиту відбувається два наступні дії:
•На спеціальній сторінці БД відводиться 4 байти для зберігання значення генератора;
•У системній таблиці RDB $ GENERATORS заводиться запис, куди поміщаються
<имя_генератора> (поле RDB $ GENERATOR_NAME), його номер (поле RDB $ GENERATOR_ID) і ознака
того, що генератор створений користувачем (значення в полі RDB $ SYSTEM_FLAG дорівнює нулю).
Типово генератор створюється з поточним значенням нуль. Для установки певного (поточного)
значення генератора <целое_значение> можна використовувати команду наступного формату:
Після створення генератора отримання його чергового (наступного) значення виконується
викликом функції GEN_ID або функції NEXT VALUE FOR.

13. 1. Основи розробки модулів PSQL. Виняткові ситуації
Виняткові ситуації (exception) - це повідомлення, які генеруються, коли з'являється помилка в
тілі процедури, що зберігається або тригера.
У СУБД існують попередньо певні винятки з асоційованими з ними текстами повідомлень. Такі
повідомлення видаються користувачеві, наприклад, при спробі видалити об'єкт, який знаходиться в
використанні, при спробі вставити некоректні дані в стовпець, на який накладено обмеження, і т.д.
Але, крім цього, існує можливість створення користувацьких винятків.
Для визначення нового користувацького винятку використовується запит CREATE EXCEPTON, що
має наступний формат:
Щоб активізувати в тілі тригера або збереженої процедури генерацію повідомлення про
виняткову ситуації і тим самим перервати виконання тригера або збереженої процедури, необхідно
використовувати наступну команду:

14. 2. Збережені процедури
Збережена процедура (ЗП) є набором інструкцій, що зберігаються на стороні СУБД. Набір інструкцій
зазвичай пишеться у вигляді послідовності SQL-команд. ЗП схожі на звичайні процедури мов високого
рівня, у них можуть бути вхідні і вихідні параметри і використовуватися локальні змінні. У них можуть
виконуватися числові обчислення й операції над символьними даними, результати яких можуть
присвоюватися змінним і параметрами. Крім того, в ЗП можуть виконуватися стандартні операції з БД.
Використання ЗП має такі переваги :
Продуктивність. При створенні текст процедури оптимізується і зберігається в БД у
відкомпільованому вигляді. У такому вигляді процедура виконується набагато швидше, ніж у випадку
динамічного компілювання кожного складового її запиту. Виконуються ЗП сервером, а не клієнтом, що
дозволяє скоротити мережевий трафік;
Модульне проектування. Використання ЗП часто дозволяє значно скоротити обсяг коду клієнтського
додатку. Додатки, які отримують доступ до однієї і тієї ж БД, можуть спільно використовувати одні і ті ж
процедури, і не потрібно знову програмувати одні і ті ж дії, завдяки чому зменшується ризик програмних
помилок в клієнтських додатках і економиться час програміста;
Локалізація змін. Якщо процедура модифікується, то всі внесені зміни автоматично відображаються у
всіх додатках, які використовують процедуру, забезпечуючи їх узгодженість;
Захист. У більшості СУБД ЗП вважаються захищеними об'єктами і їм призначаються окремі привілеї.
Користувач, що викликає ЗП, повинен мати право на її виконання;
Простота доступу. У великих БД набір ЗП може стати для прикладних програм основним засобом
доступу до БД. Часто виклик стандартної процедури більш зрозумілий, ніж виконання послідовності SQL-
команд (запитів);
Реалізація ділової логіки. Можливості умовної обробки, надаються ЗП, часто використовуються для
реалізації бізнес-логіки в БД. У збережених процедурах можна реалізовувати складні алгоритми обробки
даних всередині бази, причому в багатьох випадках використання ЗП дозволяє чітко відокремлювати
алгоритми логіки програми від алгоритмів обробки даних.

15. 2. Збережені процедури. Визначення
Збереженою процедурою (stored procedure) називається скомпільована програма довільної
довжини на процедурній мові СУБД, яка зберігається в БД як частина метаданих. Збережені
процедури можуть викликатися незалежно - як у IBExpert, так і при виконанні SQL-сценарію (в тому
числі в тілі тригера та іншої процедури, що зберігається).
У СУБД збережені процедури створюються запитом CREATE PROCEDURE і мають наступний
синтаксис:
Збережена процедура може бути створена за допомогою запиту CREATE PROCEDURE в SQL-
редакторі IBExpert або в тексті SQL сценарію. В якості вхідних параметрів можуть використовуватися
вирази. При оголошенні вхідних параметрів допускається задавати значення по замовчуванню,
наприклад таким чином:
Параметри зі значеннями за замовчуванням повинні бути вказані останніми у списку вхідних
параметрів, тобто не можна оголосити параметр, який не має значення за замовчуванням, після
параметрів, оголошених зі значенням за замовчуванням.
Підстановка значення за замовчуванням відбувається під час виконання процедури.

16. 2. Збережені процедури. Визначення
Пропозиція RETURNS призначена для визначення вихідних параметрів. Вхідні і вихідні
параметри можуть використовуватися в тілі процедури як звичайні локальні змінні, визначені за
допомогою оператора DECLARE VARIABLE. В SQL-запитах локальні змінні, вхідні і вихідні параметри
повинні використовуватися з «:» перед ім'ям змінної, щоб відрізняти їх від імен стовпців таблиць.
Тіло процедури і його складові частини мають наступні синтаксичні конструкції:
де
Для зміни визначення процедури використовується запит, що має наступний формат:
Знищення збережених процедур здійснюється запитом DROP PROCEDURE, який має наступний
формат:

17. 2. Збережені процедури. Визначення
Збережені процедури умовно поділяються на два типи: процедури вибору (select procedure) і
виконувані процедури (executable procedure). Кожна з цих процедур має різне призначення.
Створення ЗП обох типів формально не відрізняється, але відрізняється їх виклик. Також
відрізняються оператори, які впливають на хід виконання ЗП.
У збережених процедурах вибору застосовується оператор SUSPEND. Він призупиняє виконання
процедури для повернення з неї поточних значень вихідних параметрів, після чого виконання
процедури триває. Якщо вихідним параметрами не присвоєні значення, то будуть повернуті NULL
значення. SUSPEND не повинен використовуватися в виконуваних процедурах, так як команди,
наступні за ним, ніколи не будуть виконані.
У виконуваних процедурах для виходу з циклу може використовуватися оператор EXIT.
Оператор EXIT викликає перехід на кінцевий END в процедурі і використовується для того, щоб
перервати виконання ЗП та повернутися в точку її виклику.
Як в ЗП вибору, так і у виконуваних процедурах може використовуватися оператор LEAVE, який
служить для виходу з поточного циклу, а також для переходу на мітку. Він дозволяє призупинити
виконання поточного блоку і перейти в місце, позначене відповідною міткою. У цьому випадку
використовується наступний синтаксис:
де <оператор_цикла> представляє собою оператор WHILE, неявний курсор або оператор EXECUTE
STATEMENT з циклом FOR; <метка> - довільний ідентифікатор, що дозволяє іменувати деякий
оператор модуля і таким чином посилатися на нього.

18. 2. Збережені процедури. Визначення
Оператор LEAVE без явної вказівки мітки означає вихід з поточного циклу, наприклад в тілі ЗП
наступним чином:
Для отримання кількості рядків, що повертаються виконаним запитом DML або запитом SELECT,
призначена контекстна змінна ROW_COUNT типу INTEGER. Вона повинна використовуватися в тому
ж блоці, що і запит, наприклад всередині тіла ЗП наступним чином:

19. 2. Збережені процедури. Процедури вибору
Процедури вибору повертають результуючий набір рядків, що включають стовпці,
вибрані з однієї або декількох таблиць або представлень. Використання процедур
вибору дозволяє об'єднувати дані, одержані декількома запитами, і представляти
отримані дані у вигляді єдиного набору вихідних параметрів процедури вибору.
Наприклад, нехай стоїть завдання отримання якоїсь інформації з таблиць БД і для
цієї мети використовується запит з групованням по якомусь полю зовнішнього ключа, що
представляє собою код, значення якого розшифровується в іншій таблиці. У запиті з
групованням не вдасться включити до списку елементів, які повертаються розшифровку
значення коду зовнішнього ключа з іншої таблиці (наприклад, назва вулиці за зовнішнім
ключем в таблиці абонентів ). Якщо використовувати в збереженій процедурі два
послідовно виконуваних запити - один на групування, інший на розшифровку коду, а
потім повертати отримані результати у вигляді одного набору даних, то, по-перше,
можна спростити отримання деякої аналітичної інформації (в даному прикладі), і, по-
друге, оптимізувати цей процес за рахунок використання збереженої процедури.
Для виконання процедури вибору використовується запит SELECT, в реченні FROM
якого вказується ім'я ЗП. Синтаксис запиту SELECT в цьому випадку має наступний
вигляд:

20. 2. Збережені процедури. Процедури вибору

21. 2. Збережені процедури. Процедури вибору

22. 2. Збережені процедури. Процедури вибору

23. 2. Збережені процедури. Процедури вибору

24. 2. Збережені процедури. Виконувані процедури
Виконувані процедури виконують деякі дії і можуть НЕ повертати результуючий
набір рядків, як це відбувається в процедурах вибору. Синтаксис визначення
виконуваних процедур аналогічний синтаксису визначення процедур вибору з тим
винятком, що виконувані процедури можуть не містити вихідних параметрів, а для
правильної роботи процедури вибору наявність вихідних параметрів обов'язкова.
Запит на виклик виконуваних збережених процедур має наступний формат:
В якості вхідних параметрів, як і при виклику процедури вибору, можуть використовуватися
вирази.
Пропозиція RETURNING_VALUES призначена для присвоєння змінним значень, що
повертаються викликаною процедурою.

25. 2. Збережені процедури. Виконувані процедури
Розглянемо наступний приклад SQL-сценарію, в якому створюється таблиця Ftable і дві
виконувані процедури з іменами Factorial і FactorialSet:

26. 2. Збережені процедури. Виконувані процедури
У збережених процедурах можна використовувати запити модифікації даних INSERT, UPDATE
OR INSERT, UPDATE і DELETE, які містять пропозицію RETURNING для вказівки, що значення певних
стовпців у змінюваних рядках повинні запам'ятовуватися у відповідних змінних, перерахованих в
списку після INTO. Пропозиція RETURNING, що використовується в кінці запитів модифікації DML,
має наступний формат:
Стовпці, зазначені в <список_столбцов>, можуть бути будь-якими стовпцями з цільової
таблиці, в тому числі оновлюваними.
Слід врахувати, що запити модифікації даних, що використовують пропозицію RETURNING,
повинні оперувати не більше ніж з одним рядком набору даних.
Наприклад, визначення виконуваної збереженої процедури, що використовує запит на
видалення даних з пропозицією RETURNING, може виглядати наступним чином:

27. 2. Збережені процедури. Виконувані процедури
Процедурну мову надає можливість виконання запитів DDL і DML в тілі модуля за допомогою
оператора EXECUTE STATEMENT. У такому випадку запит записується як <рядок>, який може бути
сконструйований як локальна змінна в тілі модуля або ж передана зовнішнім додатком або
збереженою процедурою в якості вхідного аргументу для іншої збереженої процедури. Оператор
EXECUTE STATEMENT може використовуватися як в збережених процедурах, так і в тригерах і
виконуваних блоках на PSQL. Синтаксис оператора EXECUTE STATEMENT наступний:
Можна виділити в даному синтаксисі три форми використання оператора EXECUTE
STATEMENT.
Перша форма (найпростіша) представлена наступним синтаксисом:​​
У простій формі оператор EXECUTE STATEMENT виконує запит SQL, записаний як <рядок>, який
виконує деяку дію, але не повертає рядків даних. Такий запит може являти собою наступне:
- Запит DML (INSERT, DELETE, UPDATE);
- EXECUTE PROCEDURE;
- Будь-який запит DDL за винятком CREATE DATABASE і DROP DATABASE.
Наприклад, якщо створити процедуру наступним чином:

28. 2. Збережені процедури. Виконувані процедури
Друга форма оператора EXECUTE STATEMENT має наступний формат:
У цьому випадку <рядок> представляє собою запит, який повертає одиночний рядок даних.
Тільки <скалярний_подзапрос> може бути виконаний при використанні другої форми оператора
EXECUTE STATEMENT (<подзапрос_столбца> і <табличный_подзапрос> не можуть
використовуватися).
Прикладом створення виконуваної процедури, що використовує другу форму синтаксису
оператора EXECUTE STATEMENT, може бути наступний:

29. 2. Збережені процедури. Виконувані процедури
Третя форма оператора EXECUTE STATEMENT підтримує виконання запиту SELECT всередині
циклу FOR для повернення в список змінних за одним рядком за кожен прохід циклу, і
представлена наступним синтаксисом:​​
У даному випадку <рядок> може являти собою запит, який повертає як одиночний рядок
даних, так і множину рядків даних. Таким чином, будь-який запит SELECT може бути використаний
у даній формі EXECUTE STATEMENT.

30. 2. Збережені процедури. Виконувані процедури
Оператор EXECUTE STATEMENT додає гнучкості модулям на PSQL, але з ризиком помилок.
Оператор EXECUTE STATEMENT слід застосовувати тільки у разі неможливості отримати потрібні
результати іншими засобами або (що мало ймовірно) коли це дійсно поліпшує виконання запиту.
При використанні EXECUTE STATEMENT слід врахувати наступні особливості:
•Під час компіляції синтаксичний аналізатор не може перевірити синтаксис запиту в рядку
аргументу;
•Під час компіляції значення, які повертаються не перевіряються на відповідність типів даних
(наприклад, рядок '1234 'може бути перетворений в ціле число, а рядок 'абв' викличе помилку
перетворення), тому вони повинні бути уважно впорядковані розробником, щоб уникнути
непередбачуваних винятків перетворення даних при подальшому виконанні процедури;
•Не перевіряються залежності або існування захисту для запобігання знищення або зміни
таблиць і стовпців;
•Операції EXECUTE STATEMENT виконуються повільно, тому що вбудований оператор повинен
готуватися на сервері щоразу перед виконанням;
•Якщо ЗП має спеціальні привілеї до деяких об'єктів, то динамічний оператор, що видається в
рядку EXECUTE STATEMENT, не успадковує їх. Використовуються ті привілеї, які має користувач, що
виконує процедуру.
Слід врахувати також, що неможливо підрахувати кількість рядків, які повертає виконаний в
операторі EXECUTE STATEMENT запит з допомогою змінної ROW_COUNT. Контекстна змінна
ROW_COUNT, використана після EXECUTE STATEMENT, завжди повертає нуль.

31. 3. Тригери
Тригером називається особливий вид збережених процедур. У більшості СУБД існує два види
тригерів: тригери DML і тригери БД.
Тригери DML виконуються СУБД автоматично при проведенні операцій зміни даних. Тригер
DML фактично є обробником на подію зміни даних в базі. При виникненні такої тригер зв'язується
з деякою однією таблицею БД. Тригери DML надають можливість виконувати деякі обумовлені
користувачем дії при виконанні над даними заданої таблиці трьох операцій: знищення, зміни і
вставки.
Один і той же тригер може відстежувати різні види операцій (наприклад, вставку і зміну),
причому операцію можна відстежувати до і після її виконання.
Тригери БД не зв'язуються з конкретною таблицею бази даних. Вони виконуються при
підключенні до бази даних або відключенні від неї, а також при запуску, успішному завершенні
або відкаті транзакції.
Використання тригерів має такі переваги:
•Можливість автоматичної перевірки тригерами DML коректності даних, певні значення яких
необхідно зберігати у відповідній таблиці;
•Створення більш гнучкої системи підтримки цілісності БД в порівнянні зі стандартними
засобами;
•Скорочення обсягу підтримки додатків, оскільки зміни тригерів автоматично відображаються
у всіх програмах, що використовують пов'язані з тригерами таблиці (без необхідності їх
повторного складання і компіляції);
•Можливість створення системи автоматичної фіксації змін до таблиць БД (ведення журналу
змін).

32. 3. Тригери. Визначення тригера
З будь-якою подією, що викликає зміну вмісту таблиці (представлення), можна пов'язати певні
дії, які СУБД буде автоматично виконувати при кожному виникненні події.
Тригер DML - це визначена дія або послідовність дій, які автоматично виконуються при
виконанні запитів оновлення, додавання або знищення даних до певної таблиці (представлення)
БД. Тригер створюється для заданої таблиці (представлення) і зберігається в БД як частина
метаданих.
Тригер є потужним інструментом контролю змін даних в БД, а також допомагає
автоматизувати операції, які повинні виконуватися в цьому випадку. Тригер виконується після
перевірки правил поновлення даних. Тригер включає в себе дві компоненти:
•Обмеження, для реалізації яких він створюється;
•Подія, яке характеризує виникнення ситуації, що вимагає перевірки обмежень.
Передбачена дія проводиться за рахунок виконання певної операції або послідовності
операцій, за допомогою яких реалізується логіка, необхідна для задоволення обмежень.
Події виникають при зміні вмісту таблиці. Дія, що викликається подією, задається
послідовністю запитів SQL і операторів процедурної мови.
Тригери є частиною роботи транзакції, в якій подія DML змінює стан рядка. Якщо транзакція
успішно підтверджується, то всі дії тригерів приймаються. Якщо буде виконаний відкат транзакції,
то всі дії тригера будуть скасовані.

33. 3. Тригери. Визначення тригера
Тригер визначається запитом CREATE TRIGGER, який має наступний формат:
Визначення тригера складається з заголовка і тіла. Заголовок містить:
Ім'я створюваного тригера;
Ім'я таблиці або представлення, які модифікуються, і для яких створюється тригер;
Стан тригера (активний або неактивний);
Опис зв'язку з подіями, при настанні яких тригер повинен спрацювати;
Пріоритет виконання тригера над іншими тригерами, якщо ті пов'язані з тією ж таблицею
(представленням).
У заголовку тригера його активність визначається зазначенням ключового слова ACTIVE.
Тригер можна "відключити", якщо використовувати в заголовку тригера ключове слово INACTIVE.
Типово будь-який тригер створюється активним, тобто не обов'язково вказувати ключове слово
ACTIVE при визначенні нового тригера. Явна вказівка ​​ACTIVE може знадобитися при "включенні"
неактивного тригера.

34. 3. Тригери. Визначення тригера
Тригер може виконуватися в одній з двох фаз: BEFORE або AFTER. BEFORE вказує на те, що
тригер повинен спрацювати до зазначених подій, а AFTER активізує роботу тригера після настання
зазначених подій.
DELETE, INSERT і UPDATE задають три типи подій, на які тригер «реагує" відповідно при
знищенні, вставці або оновленні записів таблиці, для якої створений тригер.
Можливе об'єднання дій для двох або трьох подій DML в одному тригері. У той же час в базі
даних може бути створено кілька тригерів, які асоційовані з однією і тією ж таблицею, однією і
тією ж подією і які мають одну і ту ж фазу. При цьому для однієї таблиці (представлення) можна
створити не більше 32768 тригерів. Порядок виконання таких тригерів встановлюється за
допомогою параметра пропозиції POSITION.
Значення приоритет_тригера може змінюватися від 0 до 32767. Тригери з меншими
номерами виконуються першими. Якщо ж кілька тригерів мають один і той же пріоритет, то вони
виконуються в алфавітному порядку їх імен.
Тіло тригера задає послідовність дій, яка буде реалізована СУБД при настанні контрольованих
подій над заданою таблицею або представленням.
Тіло тригера, як і тіло ЗП, складається зі списку оголошення використовуваних локальних
змінних і блоку виконуваних операторів:

35. 3. Тригери. Визначення тригера

36. 3. Тригери. Визначення тригера

37. 3. Тригери.
Визначення
тригера

38. 3. Тригери.
Збереження
посилальної
цілісності

39. 3. Тригери. Збереження посилальної цілісності

40. 3. Тригери. Модифікація і видалення тригера
Тригер являє собою досить корисний засіб, але в той же час тригери необхідно дуже ретельно
налагоджувати, так як неправильно написані тригери можуть призвести до серйозних проблем.
При неправильній логіці роботи тригерів можна легко знищити потрібні дані і навіть цілу базу
даних.
Часто виникає необхідність модифікувати раніше створений тригер DML. Причинами цього
можуть бути:
•Виправлення помилок, допущених у процесі розробки тригера і порушують правильну логіку
роботи системи;
•Зміна функціональності вже створеного тригера;
•Тимчасове відключення тригера, корисне при розробці та налагодженні.
Виробляти модифікацію тригера можна в тексті SQL сценарію або шляхом виконання
окремого запиту на модифікацію в SQL-редакторі IBExpert.
Для зміни визначення створеного тригера DML необхідно використовувати запити ALTER
TRIGGER, CREATE OR ALTER TRIGGER або RECREATE TRIGGER, які мають наступний формат:

41. 3. Тригери. Модифікація і видалення тригера
Зміни тригера можуть бути трьох видів:
•Тільки заголовка;
•Тільки тіла;
•Заголовка і тіла.
Якщо потрібно змінити тільки заголовок тригера, то можна використовувати запит ALTER
TRIGGER. Даний запит вимагає хоча б одного змінюваного атрибута після імені тригера. Будь-який
атрибут заголовка, опущений в цьому запиті, залишається незмінним. Якщо змінюється індикатор
фази, то подія також має бути вказано.
Як випливає з синтаксису, запит ALTER TRIGGER не може зв'язати тригер з іншою таблицею,
відмінною від заданої раніше при створенні тригера.
Зміна заголовка тригера може бути використано, наприклад, для відключення тригера в
наступному вигляді:
Зміна тіла тригера використовується, як правило, для перетворення його функціональності.
Наприклад, створений раніше тригер Request_INSERT можна змінити, прибравши генерацію
значення первинного ключа наступним чином:

42. 3. Тригери. Модифікація і видалення тригера
Зміна (точніше, заміщення) всього тригера (як заголовка, так і тіла) слід реалізовувати в тексті
SQL сценарію. При цьому можна використовувати запит ALTER TRIGGER (застосування запиту
CREATE TRIGGER викличе помилку, оскільки до моменту зміни тригер вже існує).
Часто зручніше використовувати запит CREATE OR ALTER TRIGGER, який створює тригер, якщо
він ще не існує, або змінює тригер із зазначеним ім'ям і перекомпільовує його. При цьому наявні
залежності та привілеї зберігаються.
Якщо потрібно заново створити тригер зі старим ім'ям, то використовується запит RECREATE
TRIGGER. Синтаксис цього запиту такий же, як і запиту CREATE TRIGGER. Якщо тригер з вказаним
ім'ям вже існує, то запит RECREATE TRIGGER намагається видалити його і створити повністю новий
об'єкт (що не буде виконано, якщо тригер знаходиться у використанні).
Для видалення тригера використовується запит DROP TRIGGER, який має наступний формат:

43. 3. Тригери. Тригери бази даних
Як було зазначено раніше, крім тригерів DML існують тригери БД. Вони надають можливість
виконувати визначені користувачем дії при виконанні підключення до БД і відключенні від неї, а
також при запуску, успішному завершенні або відкаті транзакції.
Синтаксис запиту на створення або зміну тригера БД має наступний вигляд:
Події CONNECT і DISCONNECT виникають при виконанні команд підключення до БД і від'єднання
від БД. Подія TRANSACTION START виникає при запуску нової транзакції, тобто автоматично разом з
першим SQL-запитом або безпосередньо після закінчення попередньої транзакції. Події
TRANSACTION COMMIT і TRANSACTION ROLLBACK виникають при виконанні команд COMMIT або
ROLLBACK відповідно, які означають завершення транзакції (фіксацію або відкат).
Якщо порівняти даний синтаксис з синтаксисом визначення тригерів DML, то можна виділити
наступні особливості:
•Не вказується конкретна таблиця (подання), для якої створюється тригер;
•В якості подій використовуються підключення до БД, відключення від БД, старт, успішне
завершення і відкат транзакцій;
•Відсутня вказівка фази​​ BEFORE або AFTER для подій.
Слід зазначити, що тільки власник БД або SYSDBA можуть створювати тригери БД, у той час як
тригер DML може бути визначений будь-яким іншим користувачем, якщо він є власником таблиці,
для якої створюється тригер.

44. 3. Тригери. Тригери бази даних
В результаті виконання даного скрипта при кожному підключенні до навчальної БД в
таблицю Users_Connect будуть занесені ім'я користувача і дата / час на момент підключення.
Може бути виконано зміну активності або зміну тіла раніше створеного тригера БД. Проте
слід врахувати, що подія, з яким асоційований тригер БД, не може бути змінена.

45. 4. Тригери. Виконувані блоки
Існує можливість виконання коду на PSQL без оформлення іменованих ЗП або тригерів. Таку
можливість надає запит EXECUTE BLOCK, який має наступний синтаксис:
Даний оператор може використовуватися в клієнтських додатках для реалізації необхідної
логіки роботи системи, коли в базі даних немає необхідної іменованої ЗП або тригера. Вхідні
параметри в такому випадку передаються в оператор EXECUTE BLOCK з програми, а вихідні -
повертаються до клієнтського додатку.
У IBExpert даний оператор можна виконати в SQL-редакторі як звичайний запит.
У операторі EXECUTE BLOCK <тело_блока> може включати в себе всі ті ж конструкції
(оператори, запити), що і тіло процедури, що зберігається або тригера.