Тригери (triggers)

Всі сучасні СУБД здатні здійснювати контроль за логікою роботи додатків і проходженням даних по таблицях. Саме на цій основі будуються їх можливості ефективного управління інформацією. Тригер (trigger) – це ще один об’єкт бази даних, це особливий тип збереженої процедури, який використовується для підтримання цілісності даних в базі даних.

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

Найбільш поширене застосування тригерів – це перевірка складних критерієв в базі даних. Тригери використовуються, коли стандартних обмежень і декларативних табличних засобів для забезпечення умов цілісності даних (Declarative Referential Integrities – DRI) вже недостатньо.

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

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

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

Тригери не можна створювати для представлень таблиць (view) – лише для базової таблиці чи таблиць, на основі яких визначений вид.

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

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

Роль (role), логін (login), користувач (user)

Деякі СУБД, зокрема MS SQL Server, працюють з двома рівнями доступу користувачів. Перший рівень – це логін (login, обліковий запис користувача). Він призначений для підключення власне до сервера системи СУБД. Область дії логіна поширюється на весь сервер. Всі логіни зберігаються у спеціальній таблиці; в MS SQL Server, наприклад, це таблиця sysxlogins бази даних master.

Другий рівень доступу утворюють користувачі, або юзери (users). Цей рівень використовують для контролю за тим, хто має права на доступ до певних ресурсів сервера. Під ресурсами розуміються таблиці і збережені процедури кожної бази даних. User може бути створений для однієї або кількох баз даних незалежно. Всі юзери зберігаються в спеціальній таблиці, яка існує в кожній базі даних (в MS SQL Server це таблиця sysusers).

СУБД використовує записи з ціллю надання одному й тому ж співробітнику різних прав доступу в різних базах даних. Для підключення до будь-якої бази даних використовується один і той же пароль. Це забезпечується наявністю в кожного співробітника логіна, який дозволяє підключитися до сервера в цілому. Доки не буде встановлено з’єднання з сервером, користувач не зможе отримати доступ до жодної з розташованих на ньому баз даних. Єдине можливе тут виключення – це доступ до віддалених систем, що здійснюється з використанням віддалених збережених процедур.

На рівні сервера визначено кілька різних ролей, які можуть бути назначені певному логіну. Продумане використання ролей може значно полегшити управління роботою кількох СУБД. Крім того, це дозволяє централізувати контроль за певними ресусами організації. Наприклад, в багатьох фірмах функції захисту покладені на окрему людину або на невелику групу спеціалістів. Привласнення цьому робітнику (або групі) ролі адміністратора системи безпеки надасть йому (або їм) право керувати всіма логінами в системі, і звільнить системного адміністратора від цих зобов’язань.

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

Достатньо широкий діапазон ролей створюється безпосередньо під час встановлення СУБД. В MS SQL Server однією з таких стандартних ролей є роль public. Вона автоматично назначається всім створюємим в системі користувачам і забезпечує їм набір прав доступу, який надається за замовчуванням.

Будь-якому користувачу можна назначити стільки ролей, скільки необхідно. Це правило дозволяє зв’язати логіни користувачів з набором надаваємих їм прав доступу. Крім того, слід враховувати, що область дії ролі розповсюджується лише на певну БД. Це означає, що якщо деяка роль визначена лише в одній базі даних, то в усіх інших базах вона буде недоступною. Якщо потрібно, можна визначити відповідну роль в кожній з баз даних окремо.