Основи SQL

· Зниження продуктивності

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

6.2 Засоби підтримки цілісності даних

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

Основними типами обмежень підтримки цілісності даних є:

· Обов'язкові дані.

· Обмеження для атрибутів.

· Цілісність сутностей.

· Посилаюча цілісність.

Розглянемо кожен із них

6.2.1 Обов'язкові дані

Для деяких стовпців вимагається наявність у кожному рядку таблиці конкретного і допустимого значення, а не значення NULL. Для задання обмежень такого типу рекомендується використовувати специфікатор NOT NULL у операторах CREATE і ALTER TABLE.

6.2.2 Обмеження для атрибутів

Кожний стовпець має власний атрибут, тобто деякий набір допустимих значень. Стандарт ISO передбачає два різні механізми визначення атрибутів в операторах CREATE і ALTER TABLE. Перший базується на використанні фрази CHECK, яке дозволяє задати потрібні обмеження для окремого стовпця чи таблиці в цілому.

Фраза CHECK має наступний синтаксис:

CHECK (<пошук з перевіркою>)

При заданні обмежень для окремого стовпця у фразі CHECK можна робити посилання тільки на визначений стовпець. Наприклад для вказання того, що стовпець Spesiality у таблиці STUDENTS може містити тільки два допустимих значення 'Інформаатика' чи 'Математика' потрібно описати його таким чином:

Spesiality CHAR NOT NULL CHECK (Spesiality IN ( 'Інформатика', 'Математика' ))

6.2.3 Цілісність сутностей

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

PRIMARY KEY(<ім'я 1-го стовпця >,<ім'я 2-го стовпця >)

Фраза PRIMARY KEY може вказуватись у визначенні таблиці тільки один раз. Проте є можливість гарантії унікальності значення і для довільних альтернативних ключів таблиці, для яких визначено ключове слово UNIQUE. При цьому, у визначенні стовпців альтернативних ключів таблиці, рекомендується використання специфікатора NOT NULL.

6.2.4 Посилаюча цілісність

Зовнішні ключі представляють собою стовпці чи набори стовпців, які призначені для зв'язування

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

Стандарт ISO передбачає механізм визначення зовнішніх ключів з допомогою фрази FOREING KEY, яка вказана в операторі CREATE і ALTER TABLE.

Якщо користувач хоче видалити із основної таблиці рядок, на який посилається один чи більше рядків підпорядкованої таблиці, то мова SQL надає такі чотири варіанти дій:

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

Вказівка SET NUL - виконує видалення рядка із основної таблиці. При цьому у зовнішні ключі усіх рядків, підпорядкованої таблиці, які на неї посилаються, заноситься значення NULL. Це справедливо тільки у тих випадках, якщо у визначенні стовпця зовнішнього ключа відсутнє ключове слово NOT NULL.

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

Вказівка NO ACTION вказує, що видалення рядків із основної таблиці відміняється (заборонено). Дана вказівка використовується у тих випадках, коли у описі зовнішнього ключа вираз ON DELETE упущений.

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

6.3 Додаткові засоби визначення даних

Задання обмежень підтримки цілісності даних в операторі CREATE TABLE

Синтаксис даного оператора є наступним

CREATE TABLE <ім'я таблиці> {(<ім'я поля> <тип поля> NOT NULL [UNICUE] [DEFFAULT <значення за замовчуванням>[CHECK (умови перевірки)] [,…]} [PRIMARY KEY (<список полів>),] { [UNIQUE (список полів),] [,…]} {[FOREING KEY (<список зовнішніх полів>) REFERENCES <ім'я основної таблиці>[(<список полів основної таблиці>)], [MATGH{ PARTIAL | FULL} [ ON UPDATE<посилання на внутрішню функцію>] [ON DELETE <посилання на внутрішню функцію>]] [,…]} {[CHECK (<логічні умови>) [,…]} )

Необов'язкова фраза DEFAULT призначена для задання значення, яке приймається за замовчуванням. Воно буде використовуватись кожен раз, коли в операторі INSERT буде відсутнє значення в даному стовпці.

Використання цієї фрази дозволяє в подальшому задавати те чи інше обмеження з допомогою оператора ALTER TABLE.

У фразі PRIMARY KEY вказується стовпець чи стовпці які визначають первинний ключ таблиці. За замовчуванням для всіх стовпців, які входять у первинний ключ, використовується режим NOT NUL. У визначенні кожної таблиці може бути присутня тільки одна фраза PRIMARY KEY. Система заблокує виконання будь яких операторів INSERT чи UPDATE, в яких робиться спроба створити рядок із дублюючими значеннями у стовпці (чи стовпцях), вказаних у реченні PRIMARY KEY. З допомогою фрази UNICUE можуть визначатись решту потенційних ключів таблиці. При цьому знову для кожного стовпця, вказаного у фразі UNICUE, повинен використовуватись режим NOT NUL, а саме визначення таблиці може містити довільну кількість фраз UNICUE.

Фраза FOREIGN KEY дозволяє визначити зовнішні ключі підпорядкованих таблиць і встановити з їх допомогою зв'язок із основною таблицею. У даній фразі також вказуються необхідні вимоги до підтримки посилаючої цілісності БД.

У загальному випадку дана фраза може включати наступні елементи:

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

· Фразу REFERENCES, яка визначає ім'я основної таблиці. Якщо параметр <ім'я поля> опущено, то вважається, що даний зовнішній ключ від повідає первинному ключу основної таблиці.

· Необов'язкову фразу, що визначає правила оновлення для даного зв'язку (ON UPDATE), і задає дії які система повинна виконати у випадку оновлення значення потенційного ключа основної таблиці, на які є посилання у рядках даної підпорядкованої таблиці. Параметр 'посилання на внутрішню функцію (referential_action)' може приймати одне із значень: ON UPDATE Якщо фраза ON UPDATE опущена, то за замовчуванням передбачається виконання правила NO ACTION.

· Необов'язкову фразу визначення правила видалення для даного зв'язку (ON DELETE), що задає дію, яку система повинна виконати у випадку видалення значення потенційного ключа основної таблиці, на яке є посилання у рядках підпорядкованої таблиці. Параметр функція може приймати одне із значень: CASCADE, SET NUL, SET DEFAULT або NO ACTION. Якщо фраза ON DELETE опущена, то по замовчуванню передбачається виконання правила NO ACTION.

· Визначник MATCH. За замовчуванням посилання вважається правильним, якщо будь який із компонентів зовнішнього ключа має значення NUL, або у основній таблиці міститься рядок із відповідним значенням потенційного ключа. Визначник MATCH дозволяє уточнити спосіб обробки значення NULL у зовнішньому ключі. Якщо для таблиці вказується визначник MATCH FULL, то для правильності посилання всі компоненти зовнішнього ключа повинні мати або значення NULL, або деяке конкретне значення. Якщо вказується специфікатор MATCH PARTIAL, то для правильності посилання або всі компоненти зовнішнього ключа повинні мати значення NULL, або в основній таблиці повинен існувати, по крайній мірі, один рядок, що задовольняє усім не порожнім значенням стовпців зовнішнього ключа.

· При визначенні таблиці фраза FOREIGN KEY може вказуватись довільну кількість раз. Фраза CHECK CONSTRAINT дозволяє задавати додаткові обмеження. Якщо вони використовуються при введенні обмежень для стовпців, то у реченні CHECK можна вказувати ім'я тільки даного стовпця.

6.4 Оператор ALTER TABLE

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

· Добавлення у таблицю нового стовпця.

· Видалення стовпця із таблиці .

· Добавлення у визначення таблиці нового обмеження.

· Видалення із визначення таблиці існуючого обмеження.

· Задання для стовпця значення за замовчуванням.

· Відміна встановленого для стовпця значення за замовчуванням.

Синтаксис оператора:

ALTER TABLE <ім'я таблиці> [ADD [COLUMN]<ім'я стовпця> <тип даних>[NOT NULL] [UNICUE] [DEFAULT<значення за замовчуванням>] [CHECK<умови перевірки>]] | [DROP [COLUMN] <ім'я поля> [RESTRICT | CASCADE]] | [ADD [CONSTRAINT [<ім'я>]] <означення обмежень таблиці>] | [DROP CONSTRAINT <ім'я> [DESTRICT | CASCADE]] | [ALTER [COLUMN] SET DEFAULT <значення за замовчуванням>] | [ALTER [COLUMN] DROP DEFAULT]

Тут параметри мають ті ж значення, що і у визначенні оператора CREATE TABLE. Параметр означення обмежень таблиці може приймати одне із наступних значень: PRIMARY KEY, UNIQUE, FOREIGN KEY або CHECK. Фраза ADD COLUMN представляє собою визначення стовпця, аналогічне як і в операторі CREATE TABLE. У реченні DROP COLUMN вказується ім'я стовпця, який видаляється із визначення таблиці. дане речення включає додатковий кваліфікатор, який вказує потрібно чи ні виконувати каскадне розповсюдження оператора DROP. Даний кваліфікатор може приймати одне із наступних значень:

· DESTRICT - відміняє виконання оператора DROP, якщо якщо на вказаний стовпець посилається деякий інший об'єкт БД.

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

6.5 Використання транзакцій

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

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

Завершення виконання транзакції може бути виконано одним із таких способів:

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

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

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

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

6.5.1 Властивості транзакцій

Атомарність. Це властивість типу “все або нічого”. Це означає, що будь яка транзакція може бути виконана повністю, або не виконана зовсім.

Узгодженість. Кожна транзакція повинна переводити БД із одного узгодженого стану в другий узгоджений стан.

Ізольовааність. Всі транзакції виконуються незалежно одна від другої, аа тому проміжні результати незавершеної транзакції не повинні бути доступні другим транзакціям.

Тривалість Результати успішно завершеної транзакції повинні зберігатись в БД постійно і не повинні бути втрачені у результаті наступних збоїв.

В мові SQL неможна використовувати вкладені транзакції. З допомогою оператора SET TRANSACTION користувач може налаштовувати певні аспекти процедури обробки транзакцій.

Синтаксис:

SET TRANSACTION

[READ ONLY | READ WRITE] |

[IZOLATION LEVEL READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIAL TABLE]

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

6.6 Захист бази даних

Дані, які зберігаються у БД, є цінним ресурсом і доступ до них необхідно строго контролювати і регламентувати.

Під захистом БД розуміють захист даних, обладнання та програмного забезпечення проти будь яких навмисних і ненавмисних загроз з допомогою різних комп'ютерних і не комп'ютерних систем, в тому числі і персоналу.

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

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

· викрадання і фальсифікація даних;

· втрата конфіденційності (порушення таємниці);

· порушення недоторканності особистих даних;

· втрата цілісності;

· втрата доступності.

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

6.7 Викрадання і фальсифікація даних

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

6.8 Втрата конфіденційності і порушення недоторканності особистих даних

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

6.9 Втрата цілісності і втрата доступності даних

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

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

6.10 Типи небезпек

Небезпека - це будь-яка ситуація або дія, що може навмисне або ненавмисне вплинути на систему, а відповідно, і на всю організацію.

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

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

· Чи є в системі резервне устаткування з розгорнутим програмним забезпеченням.

· Коли востаннє виконувалося резервне копіювання системи.

· Час, необхідний на відновлення системи.

· Чи існує можливість відновлення і введення в експлуатацію неправильно змінених даних.

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

6.11 Контрзаходи - комп'ютерні засоби контролю

Відносно небезпек, що загрожують комп'ютерним системам, можуть бути приняті контрзаходи самих різних типів, починаючи від фізичного спостереження і закінчуючи адміністративно-організаційними процедурами. Не дивлячись на широкий діапазон комп'ютерних засобів контролю, загальний рівень захищеності СУБД визначається можливостями використовуваної операційної системи, оскільки робота цих двох компонентів тісно зв'язана между собою. Основними комп'ютерними засобами контролю, доступними в багатокористувацькому середовищі, зокрема для платформи IBM РС, є:

· Авторизація користувачів.

· Представлення.

· Резервне копіювання і відновлення.

· Підтримка цілісності.

· Шифрування.

· Допоміжні процедури.

6.11.1 Авторизація користувачів

Авторизація - це представлення прав (або привілеїв) власниккові мати право законного доступу до системи або до її об'єктів.

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

Аутентифікація - це механізм визначення того, чи є користувач тим, за кого себе видає.

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

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

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

6.11.2 Привілеї, та право володіння ними

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

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

6.12 Представлення (VIEW)

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

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

Ведення журналу

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

6.13 Контрольна точка

Контрольна точка - це момент синхронізації між станом БД і станом журналу виконання транзакцій. У цей момент всі буфери примусово вивантажуються на пристрої вторинної пам'яті.

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

6.14 Підтримка цілісності

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

6.15 Шифрування

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

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

Для організації захисту передачі даних по незахищених мережах повинні використовуватися системи шифрування, що включають наступні компоненти:

· ключ шифрування, призначений для шифрування початкових даних (звичайного тексту);

· алгоритм шифрування, який описує, як за допомогою ключа шифрування перетворити звичайний текст в шифротекст;

· ключ дешифрування, призначений для дешифрування шифротексту;

· алгоритм дешифрування, який описує, як за допомогою ключа дешифрувания перетворити шифротекст в початковий звичайний текст.

Системи шифрування, які використовують один і той же ключ як для шифрування, так і для дешифрування, при цьому передбачається наявність захищених ліній зв'язку, призначених для обміну ключами називаються симетричними. Але оскільки більшість користувачів не мають доступу до захищених ліній зв'язку, то для отримання надійного захисту довжина ключа має бути не менша довжини самого повідомлення. Одна з поширених систем шифрування називається DES (Data Encryption Standard) -- в ній використовується стандартний алгоритм шифрувания, розроблений фірмою IBM. У цій схемі для шифрування і дешифрування використовується один і той же ключ, який повинен зберігатися в секреті, хоча сам алгоритм шифрування не є секретним. Цей алгоритм передбачає перетворення кожного 64-бітового блоку звичайного тексту з використанням 56-бітового ключа шифрування.

Інший тип систем шифрування, який прийнято називати несиметричними, передбачає використання для шифрування і дешифрування повідомлень різні ключі. Прикладом такої системи є система з відкритим ключем, що передбачає використання двох ключів, один з яких є відкритим, а інший зберігається в секреті. Алгоритм шифрування також може бути відкритим, тому будь-який користувач, який хоче направити власникові ключів зашифроване повідомлення, може використовувати його відкритий ключ і відповідний алгоритм шифрувания. Проте дешифрувати дане повідомлення зможе тільки той, хто знає спільний закритий ключ шифрування. Системи шифрування з відкритим ключем можуть також використовуватися для відправки разом з повідомленням "цифрового підпису", який підтверджує, що дане повідомлення було дійсно відправлене власником відкритого. Найбільш популярною несиметричною системою шифрування є RSA (це ініціали трьох розробників даного алгоритму). Як правило, симетричні алгоритми є більш швидкодіючими, ніж несиметричні, проте на практиці обидві схеми часто застосовуються спільно, тобто коли алгоритм з відкритим ключем використовується для шифрування випадковим чином, згенерованого ключа шифрування, а вже цей випадковий ключ потім використовується для шифрування самого повідомлення із застосуванням деякого симетричного алгоритму.

6.16 Допоміжні процедури

Хоча вище вже були описані різні механізми, які можуть використовуватись для захисту даних в середовищі СУБД, самі по собі вони не гарантують необхідного рівня захищеності і можуть виявитися неефективними у разі неправильного застосування або управління. Тому існують різні допоміжні процедури, які повинні використовуватися спільно з описаними вище механізмами захисту.

Такими процедурами, зокрема, є:

6.16.1 Авторизація і аутентифікація

Механізм паролів, є одним із найпоширеніших методом підтвердження особи користувачів. З погляду забезпечення необхідного рівня захисту дуже важливо, щоб всі використовувані пароли трималися користувачами в секреті і регулярно оновлювалися через деякий встановлений інтервал часу. В ході процедури реєстрації в системі пароль не повинен відображатися на екрані, а списки ідентифікаторів користувачів і їх паролі повинні зберігатися в системі в зашифрованому вигляді. Крім того, в організації повинен використовуватися деякий стандарт для вибору допустимих значень паролую -- наприклад, всі паролі мають бути не менше встановленої довжини, обов'язково містити цифри і службові символи, а також підлягати заміні через встановлений інтервал часу (скажімо, п'ять тижнів). Для виявлення слабких паролів (наприклад паролів у яких використовуються реальні імена, адреси користувачів чи застарілі паролі) у системі потрібно використовувати спеціальне програмне забезпечення.

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

6.16.2 Копіювання

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

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

6.16.3 Відновлення

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

6.16.4 Аудит

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

· підтримка точності даних, що вводяться;

· підтримка точності процедур обробки даних;

· запобігання появі і своєчасне виявлення помилок в процесі виконання програм;

· коректне тестування, документування і супровід розроблених програмних засобів;

· попередження несанкціонованої зміни програм:

· надання прав доступу і контроль за їх використанням;

· підтримка документації в актуальному стані.

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

6.16.5 Установка або модернізація системного програмного забезпечення

У обов'язки адміністратора АБД входить виконання модернізації програмного забезпечення СУБД при отриманні від розробника чергових пакетів змін. Зміни, що в деяких випадках вносяться, виявляються зовсім незначними і стосуються тільки невеликої частини модулів системи. Як правило, кожен пакет змін супроводжується певною документацією, яка містить повні відомості про суть змін і їх призначення. Ніякі зміни і модернізації не повинні вноситися до системи без попередньої оцінки їх можливого впливу на наявні дані і програмне забезпечення.

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

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

6.16.7 Ідентифікатори користувачів і право володіння

Ідентифікатором користувача називається звичайний ідентифікатор мови, який використовується для ідентифікації кожного користувача БД, який присвоюється адміністратором АБД і який, як правило, пов'язується із певним паролем. Він використовується для визначення того, з якими об'єктами БД може працювати даний користувач і які операції з даними об'єктами він має право виконувати. Кожний створений в SQL об'єкт має свого власника. Власник визначається ідентифікатором користувача заданим у реченні AUTHORiZATION тієї схеми, до якої даний об'єкт належить.

6.17 Привілеї

Привілеями називаються дії, які користувач має право виконувати у відношенні даної таблиці БД чи представленні.

У стандарті ISO визначений наступний набір привілеїв:

· SELECT - право вибирати дані із таблиці;

· INSERT - право вставляти у таблицю нові рядки;

· UPDATE - право змінювати дані у таблиці;

· DELETE - право видаляти рядки із таблиці;

· REFERENSES - право посилатись на стовпці вказаної таблиці в описах вимог підтримки цілісності БД;

· USAGE - правило виконувати домени, перевірки, набори символів і трансляції.

Привілеї INSERT і UPDATE можуть обмежуватись тільки окремими стовпцями таблиці. При цьому користувач може модифікувати значення вказаних стовпців, але не може змінювати значення окремих стовпців таблиці. Аналогічно привілея REFERENSES може бути задіяна по відношенню тільки окремих стовпців таблиці, що дозволяє використовувати їх імена упри формулюванні вимог захисту цілісності даних - наприклад у фразах CHECK і FOREIGN KEY, які входять у визначення других таблиць. При цьому примінення для подібних цілей решти стовпців буде заборонено.

Коли користувач з допомогою оператора CREATE TABLE створює нову таблицю, то він автоматично стає її власником і отримує по відношенню до неї повний набір привілеїв.

Коли користувач створює представлення з допомогою оператора CREATE VIEW, то він автоматично стає власником даного представлення, хоча не обов'язково отримає по відношенню до нього повний набір прав. Це означає, що привілеї INSERT, UPDATE і DELETE по відношенню до створеного відношення користувач отримає тільки тоді, коли він має відповідні привілеї по відношенню до всіх таблиць які використовуються у представленні таблиць.

6.17.1 Надання привілеїв іншим користувачам

За допомогою оператора GRANT можна надавати вказаним користувачам привілеї по відношенню до поіменованих об'єктів БД. Він, як правило, використовується власником таблиці з метою надання доступу до неї другим користувачам.

Синтаксис:

GRANT {<привілея> | ALL PRIVILEGES}

ON <ім'я об'єкта>

TO {<ідентифікатор користувача>} | PUBLIC}

[WITH GRANT OPTION]

Параметр привілея являє собою список, який складається із однієї чи більше привілей, що розділяються комами:

SELECT

DELETE

INSERT [ (<ім'я стовпця> [,…] ) ]

UPDATE [ (<ім'я стовпця> [,…] ) ]

REFERENCES [ (<ім'я стовпця> [,…] ) ]

USAGE

Крім цього, з метою спрощення, в операторі GRANT можна вказувати ключове слово ALL PRIVILEGES, що дозволяє надати вказаному користувачу всі шість існуючих привілеїв без їх перечислення. Крім того, у даному операторі може вказуватись ключове слово PUBLIC, який означає право надання доступу вказаного типу не тільки всім існуючим користувачам, але також і всім тим, які будуть визначені у БД в подальшому. Параметр <ім'я об'єкта> може бути іменем таблиці БД, представленням, доменом, набором символів, перевірки чи трансляції.

Фраза WITH GRANT OPTION дозволяє всім вказаним у списку параметра <ідентифікатор користувача> передавати другим користувачам усі представлені їм у відношеннях вказаного об'єкта привілеї. Якщо ці користувачі також передадуть власні повноваження другим користувачам із вказанням фрази WITH GRANT OPTION, то останні, в свою чергу, також отримають право передавати свої повноваження другим користувачам. Якщо дана фраза не буде вказана, то отримувач привілеїв не зможе передавати свої права другим користувачам. Таким чином, власник об'єкта може чітко контролювати, хто отримав право доступу до об'єкта і які повноваження йому представлені.

Приклади.

Приклад 1. Представлення всіх привілеїв.

Постановка задачі.

Надати користувачеві з ідентифікатором Teacher усі привілеї доступу до таблиці STUDENTS.

Реалізація:

GRANT ALL PRIVILEGES

ON STUDENTS

TO Teacher WITH GRANT OPTION;

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

Приклад 2. Надання тільки деяких привілеїв.

Постановка задачі.

Надати користувачу з ідентифікатором Admin привілеї SELECT і UPDATE для стовпця Age таблиці STUDENTS.

Реалізація:

GRANT SELECT, UPDATE (Age)

ON STUDENTS TO Admin;

Оскільки в операторі фраза WITH GRANT OPTION опущена, користувач Admin не може передати їм привілею другим користувачам.

Приклад 3. Надання певних привілеїв декільком користувачам.

Постановка задачі.

Надати користувачам з ідентифікаторами Persona і Deputy привілеї SELECT для таблиці STUDENTS.

GRANT SELECT

ON STUDENTS

TO Persona, Deputy;

Приклад 4. Надання певних привілеїв усім користувачам.

Надати всім користувачам БД привілею SELECT для таблиці STUDENTS.

Реалізація:

GRANT SELECT

ON STUDENTS

TO PUBLIC;

В даному операторі ключове слово PUBLIC означає, що всі користувачі ( як існуючі так і потенційні) отримають право вибирати всі дані, які є в таблиці STUDENTS.

6.17.2 Відміна наданих користувачам привілей

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

Синтаксис

REVOKE [GRANT OPTION FOR] {<список привілеїв> | ALL PRIVILEGES }

ON <ім'я об'єкта>

FROM {<список користувачів> | PUBLIC} [RESTPICT | CASCADE]

Ключове слово ALL PRIVILEGES означає, що для вказаного користувача відміняються всі привілеї, які надані йому раніше тим користувачем, який задав даний оператор. Необов'язкова фраза GRANT OPTION FOR дозволяє для всіх привілей, вказаних в операторі GRANT фрази WITH GRANT OPTION, відміняти можливість їх передачі незалежно від самих даних привілей. Призначення ключових слів RESTRICT і CASCADE аналогічне як у операторі DROP TABLE.

Оскільки наявність привілей потрібна для створення певних об'єктів, видалення привілеї може відмінити право, за рахунок якого був створений той чи інший об'єкт (які називають кинутими). Виконання оператора REVOKE буде відмінено, якщо в результаті його виконання появляться кинуті об'єкти (наприклад представлення), якщо при цьому у ньому не вказувалось ключове слово CASCADE. Якщо дане слово в операторі присутнє, то для будь яких кинутих об'єктів, що появляються при виконанні вихідного оператора REVOKE, будуть автоматично видалені оператори DROP.

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

Пр.№5. Відміна певних привілей, представлених усім користувачам.

Постановка задачі.

Відмінити привілею SELECT, яка була надана всім користувачам для таблиці STUDENTS.

REVOKE SELECT

ON STUDENTS

FROM PUBLIC;

Пр.№6. Відміна певних привілей, наданих заданим користувачам.

Відмінити всі привілеї, які були надані користувачеві з ідентифікатором Deputy для таблиці STUDENTS.

REVOKE ALL PRIVILEGES

ON STUDENTS

FROM Deputy;

Висновки

1. Представленням називається віртуальна таблиця, яка включає деяку підмножину стовпців і / або рядків, і / або обчислювальних стовпців, вибраних із однієї чи більше таблиць БД або других представлень. Представлення створюється за допомогою оператора CREATE VIEW шляхом задання визначаючого запиту. Представлення не є таблицею, яка зберігається, а створюється заново при обробці кожного чергового посилання на нього.

2. Представлення можуть використовуватись з метою спрощення структури БД з точки зору користувача і формування запитів до БД. Крім цього представлення можуть використовуватись для захисту певних стовпців і / або рядків таблиці від несанкціонованого доступу.

3. Не всі види представлень дозволяють оновлення даних які у них містяться.

4. Стандарт ISO мови SQL передбачає використання в операторах CREATE і ALTER TABLE спеціальних речень призначених для визначення вимог підтримки цілісності даних, а саме:

· умова обов'язковості даних;

· обмеження для доменів атрибутів;

· вимоги підтримки цілісності сутностей;

· вимоги підтримки посилюючої цілісності даних.

Обов'язковість наявності даних вказується за допомогою ключового слова NOT NULL. Первинні ключі визначаються з допомогою фрази PRIMARY KEY, а альтернативні ключі описуються з допомогою комбінації ключових слів NOT NULL і описів UNIQUE. Зовнішні ключі описуються за допомогою речення FOREIGN KEY, а також задання правил видалення і оновлення з допомогою фраз ON UPDATE і ON DELETE.

5. Оператор COMMIT вказує на успішне завершення трансакції і необхідність фіксації в БД всіх змін , внесених при її виконанні, які можуть надаватись, відносяться: USAGE, SELECT, DELETE, INSERT, UPDATE і REFERENCES, причому три останні можуть бути обмежені окремими стовпцями таблиці чи представленнями. Користувачу може бути надано право передавати другим користувачам надані йому привілеї на його власний розсуд. Для цього використовується ключова фраза WITH GRANT OPTION. Даний режим може бути відмінений з допомогою фрази GRANT OPTION FOR оператора REVOKE.

Функції користувача та процедурні мови

Крім стандартних функцій для обробки різних типів даних, більшість СУБД дозволяють користувачам описувати власні функції.

Стандартними мовами для написання функцій користувача є SQL та C.

PostgreSQL дозволяє користувачам задавати функції на інших мовах ніж SQL і C. Ці інші мови називають процедурними мовами. Для функції, написаних на даних мовах, сервер БД не має готових інтерпритаторів. Проте вони можуть бити добавлені користувачами (команда CREATE LANGUAGE).

Для СУБД PostgreSQL найчастіше використовують наступні процедурні мови PL/pgSQL, PL/Tcl, PL/Perl, PL/Python.

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

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

Тригери

Можна дат такі визначення тригерів:

Тригером називається дія, яка пов'язана з подією, що викликає зміни у вмістимому таблиці.

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

Тригери використовуються для досягнення наступних цілей:

– перевірки коректності введених даних;

– перевірки виконання складних операцій обмеження цілісності, які важко або взагалі неможливо описати стандартними правилами обмеження цілісності встановленої для таблиць;

– генерації повідомлень, що нагадують про виконання деяких дій

– накопичення аудит-інформації за допомогою фіксації даних про здійснені зміни та користувачів, які їх здійснили

– підтримка реплікацій тобто можливість організації одних і тих же даних на різних серверах.

При умові правильного використання тригери можуть стати потужним механізмом.

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

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

– Прихована функціональність. Перенесення окремих функції в середину БД приховує їх від користувача. Хоча це спрощує роботу коростивуча, але позбавляє користувача контролю за окремими процесами.

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

Тригери можуть бути означені для виконання ПЕРЕД (before) чи ПІСЛЯ (after) будь-якої операції INSERT, UPDATE, або DELETE на кожен рядок таблиці або на цілу команду загалом.

Тригерна функція повинна бути описана перед створенням тригера. Дана функція задається без аргументів і повертає тип trigger.

Тригер створюється командою CREATE TRIGGER. Одна й та ж тригерна функція може застосовуватись в різних тригерах. Наприклад

CREATE TRIGGER name { BEFORE | AFTER } { event [ OR ... ] }

ON table [ FOR [ EACH ] { ROW | STATEMENT } ]

EXECUTE PROCEDURE funcname ( [arguments] )

Опис даної команди.

Name -- унікальне імя нового тригера

BEFORE чи AFTER -- задає порядок виконання функції

event -- одна з INSERT, UPDATE, чи DELETE команд

table -- імя таблиці для якої створюється тригер .

FOR EACH ROW або FOR EACH STATEMENT -- задає рядковий чи командний типи тригера

funcname -- імя функції яка виконується у тригері

arguments -- додаткові параметри що передають в тригерну функцію (необовязковий параментр).

PostgreSQL підтримує per-row тригери (на рядок) і per-statement тригери (на команду). Рядкові тригери виконуються для кожного рядка таблиці а командні тригери на всю команду не залежно від кількості оброблюваних даних.

Командні тригери завжди повертають NULL. Рядкові тригери повертають, як правило, рядок таблиці

Рядкові тригери, що спрацьовують перед операціями зміни даних, завжди повертають той рядок таблиці що передається їм (це NEW - рядок для INSERT і UPDATE тригерів, OLD - рядок для DELETE тригерів).

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

Для знищенн тригера існує команда DROP TRIGGER

Формаат

DROP TRIGGER [ IF EXISTS ] name ON table [ CASCADE | RESTRICT ],

де name -- імя тригера, що знищується, а table -- імя таблиці для якої він заданий.

Приклад застосування тригера.

Дано таблицю Students що містить поле прізвище (Surname). Для даної таблиці створити тригер, який буде корегувати можливі помилки вводу користувача, такі як -- зайві пропуски на початку та в кінці даних, невірний регістр літер (власні імена завжди пишуться з великої літера ).

...