Головне меню

EN | RU | UK

На головну

7. Корпоративні обмеження цілісності

Допомога & Консультація
Допомога & Консультація
Пишіть мені в
Наверх сторінки
Лекція
Мета

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

7.1. Класифікація корпоративних обмежень цілісності

Забезпечення цілісності реляційних даних (п. 4.6.2) за рахунок використання первинних і зовнішніх ключів доповнюється корпоративними обмеженнями цілісності [2, 4, 6].

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

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

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

  1. Підтримка унікальності значень потенційних ключів, які не використовуються для зв'язків між відношеннями усередині БД.
  2. Підтримка області припустимих значень в атрибутах відношень.
  3. Підтримка обмежень кількості кортежів у відношеннях, що викликане чинним законодавством і (або) особливостями процесів обліку усередині організації.
  4. Підтримка каскадного оновлення й вилучення інформації у відношеннях БД.

Усі потенційні ключі визначаються на етапі нормалізації відношень. У БД «Бібліотека» необхідно підтримувати унікальність значень таких потенційних ключів, які не використовуються для зв'язків між відношеннями:

ReaderCardNumber (№ квитка читача),

PasportCode (код паспорта) у відношенні Readers (читачі);

ClockNumber (табельний номер),

PasportCode (код паспорта) у Librarians (бібліотекарі);

Name, IssueYear (назва, рік видання) у Books (книжки);

Series, Number (серія, номер) у PasportData (паспортні дані);

ReaderCode, PhoneNumber (код читача, телефонний номер) у Phones (телефони);

InventoryNumber (інвентарний номер) у BookInventoryNumbers (інвентарні номери книжок);

Name (назва книжкового фонду) у BookFunds (книжкові фонди);

Name (назва типу телефона) у PhoneTypes (типи телефонів);

Code (номер операції) у BookGiveOutRecord (облік видачі книжок).

BookCode, AuthorCode (код книжки та автора) у Сoаuthorship (соавтори).

Необхідно визначити область припустимих значень, насамперед, для атрибутів відношень, які входять до складу потенційних ключів і не беруть участь у зв'язках між відношеннями в БД. Наприклад, аналіз наведених вище атрибутів, які входять до складу потенційних ключів і не беруть участь у зв'язках між відношеннями, виявив, що в них не має бути визначника NULL. Є ряд явних додаткових обмежень. В атрибутах типу INTEGERReaderCardNumber (№ квитка читача), ClockNumber (табельний номер), Number (номер паспорта), InventoryNumber (інвентарний номер) – значення мають бути більше 0. В атрибутах типу CHARName (назва книжки), Series (серія паспорта), PhoneNumber (номер телефону читача), Name (назва книжкового фонду), Name (назва типу телефона) не має бути порожніх рядків або рядків, що складаються з одних пробілів.

Для інших не ключових атрибутів відношень визначення області припустимих значень також може бути актуальним. Ця область залежить від вимог користувачів, що обумовлені на етапі логічного проектування БД. Наприклад, якщо обов'язково необхідно вказати основне місце роботи читачів та їх посаду, то в атрибутах Job (місце основної роботи) і Post (посада) не має бути визначника NULL, порожніх рядків або рядків, що складаються з одних пробілів.

Прикладом обмеження числа кортежів у відношенні BookGiveOutRecord (облік видачі книжок) БД «Бібліотека» може служити обмеження кількості книжок, що видається одному читачу. Іншим явним обмеженням може бути заборона на видачу одночасно декількох примірників однієї й тієї ж книжки. Наприклад, якщо є правило, що один читач може взяти не більше п'яти книг, то у відношенні BookGiveOutRecord може бути лише 5 кортежів з однаковими значеннями в атрибуті ReaderCode (код читача), де атрибут FactReturnDate (фактична дата повернення) містить визначник NULL. Додатково необхідно перевірити у відношенні BookGiveOutRecord (облік видачі книжок), щоб значення атрибутів BookGiveOutRecord.InventoryCode (інвентарний номер книжки) для зазначених кортежів відповідали різним значенням BookGiveOutRecord.BookCode (код книжки).

У СКБД архітектури клієнт-сервер механізми підтримки корпоративних обмежень цілісності можна розмістити як на боці клієнта, так і на боці сервера (див. п. 1.3.3). Ми розглянемо тільки механізми, що реалізовані на боці сервера: SQL-оператори, збережувані процедури та тригери. Для кожного конкретного випадку необхідно вибирати найпростіше рішення, що дозволить виконати поставлене завдання з підтримки корпоративних правил обмеження цілісності.

7.2. Використання SQL-операторів для підтримки корпоративних обмежень цілісності

Оператори CREATE DOMAIN, CREATE INDEX та CREATE TABLE можуть використовуватися для підтримки корпоративних обмежень цілісності. Вони дозволяють забезпечувати унікальність значень потенційних ключів, які не використовуються для зв'язків між відношеннями всередині БД, та визначати область припустимих значень атрибутів відношень.

Формат оператора

CREATE DOMAIN Ім'я [AS] <Тип даних>

    [DEFAULT {Константа | NULL | USER}]

    [NOT NULL] [CHECK (<Область визначення>)]

    [COLLATE Набір символів для сортування]

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

<Область визначення> =

 VALUE <оператор> <значення>

VALUE [NOTBETWEEN <значення> AND <значення>

VALUE [NOTLIKE <значення> [ESCAPE <значення>]

VALUE [NOTIN (<значення> [, <значення> ...])

VALUE IS [NOTNULL

VALUE [NOTCONTAINING <значення>

VALUE [NOTSTARTING [WITH] <значення>

| (<Область визначення>)

NOT <Область визначення>

| <Область визначення> OR <Область визначення>

| <Область визначення> AND <Область визначення>

<оператор> = {= | < | > | <= | >= | !< | !> | >< | !=}.

Формат оператора CREATE INDEX дозволяє уникати дублювання значень у ключових атрибутах, указавши фразу UNIQUE:

CREATE [UNIQUE] [ASС[ENDING] | DESC[ENDING]]

    INDEX Ім'я ON Ім’я таблиці (атрибут [, атрибут...]).

Оператор CREATE TABLE дозволяє підтримувати всі можливості корпоративних обмежень цілісності, які закладені в операторах CREATE DOMAIN та CREATE INDEX:

CREATE TABLE Ім'я [EXTERNAL [FILE]'Шлях та ім'я файлу']

    (<Опис атрибуту>[, <Опис атрибуту> | <Обмеження цілісності> …]).

Опис атрибуту дозволяє визначити стовпець на базі раніше створеного домену, встановити область визначення значень потенційного ключа та виключити визначник NULL з неї, зазначив NOT NULL:

<Опис атрибута> Ім'я

{Тип даних | COMPUTED [BY] (<Вираз>) | Домен}

[DEFAULT {Константа | NULL | USER}]

[NOT NULL] [<Обмеження цілісності>]

[COLLATE Набір символів для сортування].

Пропозиція COMPUTED [BY] (<Вираз>) дозволяє обчислювати значення атрибута. <Вираз> повинен повертати скалярне значення. Наприклад, оператор

CREATE TABLE SomeTable

    (Cost FLOAT NOT NULL,

    Number INTEGER NOT NULL,

    TotalCost COMPUTED BY (Cost * Number))

створює три стовпці: Cost (вартість), Number (кількість), TotalCost (загальна вартість). В останньому стовпці величина розраховується як добуток двох попередніх значень.

На рівні опису атрибута обмеження цілісності має такий вигляд:

<Обмеження цілісності> = [CONSTRAINT Ім'я] <Опис обмежень цілісності>, де

<Опис обмежень цілісності> = UNIQUE | PRIMERY KEY

CHECK (<Область визначення>)

REFERENCES Ім'я іншої таблиці [( Ім'я іншого атрибута[, Ім'я іншого атрибута …]]

[ON DELETE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}]

[ON UPDATE {NO ACTION | CASCADE | SET DEFAULT | SET NULL}].

Bи можете в <Описі обмеження цілісності> вказати, що значення в стовпці мають бути унікальними (пропозиція UNIQUE або PRIMERY KEY); встановити область визначення значень стовпця (пропозиція CHECK); організувати каскадне оновлення, вилучення значень та кортежів відношення, указавши зв'язок зі значеннями атрибутів іншої таблиці (пропозиція REFERENCES …).

Опис області визначення значень атрибута відношення відрізняється від опису області значень домену тим, що в ньому можна використовувати оператор SELECT:

<Область визначення> =

VALUE <оператор> {<значення> | <SELECT: скаляр>}

VALUE [NOTBETWEEN <значення> AND <значення>

VALUE [NOTLIKE <значення> [ESCAPE <значення>]

VALUE [NOTIN (<значення> [, <значення> …] | (<SELECT: список>)

VALUE IS [NOTNULL

VALUE {>= | <=} | [NOT] {= | < | >}

{ALL | SOME | ANY} (<SELECT: список>)

EXISTS (<SELECT: вираз>)

SINGULAR (<SELECT: вираз>)

VALUE [NOTCONTAINING <значення>

VALUE [NOTSTARTING [WITH] <значення>

| (<Область визначення>)

NOT <Область визначення>

| <Область визначення> OR <Область визначення>

| <Область визначення> AND <Область визначення>

<оператор> = {= | < | > | <= | >= | !< | !> | >< | !=}.

7.3. Збережувані процедури

7.3.1. Визначення й класифікація збережуваних процедур

Збережувана процедура – це модуль, що написаний процедурною мовою СКБД та зберігається в БД як метадані (тобто як дані про дані).

Збережувану процедуру можна викликати з прикладної програми клієнта. Існує два різновиди збережуваних процедур: процедура вибору та процедура дії [2, 4, 6].

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

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

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

Переваги збережуваних процедур такі:

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

7.3.2. Створення збережуваної процедури

Створення збереженої процедури виконується оператором

CREATE PROCEDURE Ім'я

[(<вхідні параметри> <тип даних>[, <вхідні параметри> <тип даних> …])]

[RETURNS

(<вихідні параметри> <тип даних>[, <вихідні параметри> <тип даних> …])]

AS

<Тіло процедури>

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

Формат тіла процедури такий:

[<оголошення локальних змінних>]

BEGIN

    <оператор>;

    [<оператор>; …]

END

7.3.3. Алгоритмічна мова тригерів і збережуваних процедур

7.3.3.1. Локальні змінні

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

Оголошення локальних змінних має такий формат:

DECLARE VARIABLE <ім'я> <тип>;

Тут можуть використовуватися тільки стандартні типи СКБД Interbase.

7.3.3.2. Оператор присвоювання

Оператор присвоювання служить для внесення значень у змінні. Його формат

Ім'я змінної = вираз

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

XBuyer = 'Покупець не визначений';

Тут змінній з ім’ям XBuyer присвоюється строкова константа.

7.3.3.3. Операторні дужки BEGIN … END

Операторні дужки BEGIN … END, по-перше, обмежують тіло процедури, і, по-друге, можуть використовуватися для вказівки меж складеного оператора. Під простим оператором розуміється одинична дозволена дія (див. приклад вище). Під складеним оператором розуміється група простих або складених операторів, що взята в операторні дужки BEGIN … END.

7.3.3.4. Оператор IF … THEN … ELSE

Оператор IF … THEN … ELSE у загальному вигляді записується так:

IF (<умова>) THEN <оператор> [ELSE <оператор>]

Якщо умова достеменна, то виконується оператор, що вказаний після пропозиції THEN, якщо ні, то оператор, який написаний після пропозиції ELSE.

7.3.3.5. Оператор SELECT

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

INTO змінна[, змінна …]

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

7.3.3.6. Оператор SUSPEND

Оператор SUSPEND припиняє виконання збережуваної процедури, і до прикладної програми, з якої її викликали, повертаються значення параметрів, що перелічені після пропозиції RETURNS. Наприклад, збережувана процедура FindAutorName повертає до вихідного параметра InAutorName ім'я автора, що відповідає його коду – InAuthorCode:

CREATE PROCEDURE FindAuthorName

    (InAuthorCode INTEGER)

RETURNS (InAuthorName CHAR(30)) AS

BEGIN

    SELECT Name

        FROM BookAuthors

        WHERE Code = :InAuthorCode

        INTO :InAuthorName;

    SUSPEND;

END

7.3.3.7. Оператор FOR SELECT … DO

Оператор FOR SELECTDO має такий формат:

FOR

    <оператор SELECT>

DO

    <оператор>

Після пропозиції FOR оператор SELECT повертає набір кортежів. Потім для кожного кортежу виконується оператор або послідовність операторів, яка є наступною за пропозицією DO. Іншими словами, це цикл по рядках таблиці, яка сформована оператором SELECT.

7.3.3.8. Оператор WHILE … DO

Для реалізації оператора WHILEDO використовується конструкція вигляду

WHILE(<умова>)

DO <оператор>

Він організовує циклічне виконання оператора або послідовності операторів після пропозиції DO доти, доки умова після WHILE не буде достеменною.

7.3.3.9. Оператор EXIT

Оператор EXIT припиняє процедуру й повертає керування прикладній програмі, яка її викликала.

7.3.3.10. Оператор EXECUTE PROCEDURE

Оператор EXECUTE PROCEDURE має такий вигляд:

EXECUTE PROCEDURE Ім'я [параметр[, параметр …]];

[RETURNING_VALUES параметр[, параметр …]];

За його допомогою у будь-якому місці тіла процедури можна задіяти іншу збережувану процедуру, яка є у БД. Після оператора EXECUTE PROCEDURE обов'язково вказується її ім'я. Далі, у разі необхідності, наводяться параметри, які передаються процедурі. Пропозиція RETURNING_VALUES дозволяє одержати результати виконання процедури, що викликається, й записати їх у змінні.

7.3.3.11. Оператор POST_EVENT

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

POST_EVENT "  Ім'я події"

7.3.3.12. Оператор CREATE EXCEPTION

Оператор CREATE EXCEPTION визначає виняткову ситуацію із заданим іменем і повідомленням:

CREATE EXCEPTION Ім'я ' повідомлення'

Для генерації виняткової ситуації всередині збережуваної процедури використовується такий синтаксис:

EXCEPTION Ім'я

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

7.3.4. Підтримка корпоративних обмежень цілісності даних

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

Наведемо текст збережуваної процедури, що змінює код автора книжки у відношенні СoАuthorship. Процедура застосовується для перевірки наявності коду автора книжки у БД. Вона містить усі потрібні перевірки допустимості цієї операції для БД «БІБЛІОТЕКА». Якщо операція неприпустима, то після генерації відповідної виняткової ситуації виконання процедури припиняється. Якщо виявиться, що для збереження цілісності даних при зміні коду автора необхідно виконати ще якісь дії або перевірки, то всі вони повинні виконуватися в межах даної збережуваної процедури. У результаті будь-яка прикладна програма клієнта, що її використовує, буде дотримуватися однакових обмежень цілісності даних.

CREATE EXCEPTION AuthorNotFound "  Автор не знайдений."  ;

CREATE PROCEDURE FindAuthor

    (AuthorCode INTEGER, BookCode INTEGER)

AS

DECLARE VARIABLE FindAuthorCode INTEGER;

/* Визначаэмо змінну для розміщення результату пошуку коду автора в таблиці BookAuthors. /*

BEGIN

    SELECT ba.Code

        FROM BookAuthors ba

        WHERE ba.Code = AuthorCode

        INTO :FindAuthorCode;

/* У змінну поміщаємо результат пошуку коду автора в таблиці BookAuthors. /*

    IF (FindAuthorCode IS NULLTHEN

/* У таблиці BookAuthors заданого коду автора книжки не виявлено. /*

        EXCEPTION AuthorNotFound;

    ELSE

/* У таблиці BookAuthors виявлений заданий код автора книжки. /*

        UPDATE СoАuthorship

            SET AuthorCode = FindAuthorCode

            WHERE BookCode = :BookCode

END

7.4. Тригери

Тригер – це процедура, яка автоматично викликається SQL-сервером при оновленні, вилученні або додаванні даних у відношення [10, 14, 15].

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

CREATE TRIGGER Ім'я

    FOR Ім'я таблиці [ACTIVE | INACTIVE]

    {BEFORE | AFTER} {DELETE | INSERT | UPDATE}

    [POSITION номер]

AS

    <тіло тригеру>.

Після пропозиції CREATE TRIGGER обов'язково необхідно вказати унікальне ім'я тригера. Потім у пропозиції FOR визначити ім'я таблиці, для якої створюється тригер. За замовчуванням тригер активний (ACTIVE), але, якщо вказати INACTIVE, то неактивний, тобто не буде обробляти подію. Пропозиції BEFORE і AFTER указують, коли буде виконуватись тригер – до або після події вилучення (DELETE), додавання (INSERT) запису або зміні значень атрибутів у ній (UPDATE). Пропозиція POSITION дозволяє для кожної події задіяти декілька тригерів. Послідовність їх виконання відповідає номеру.

Структура тіла тригера:

[<оголошення локальних змінних>]

BEGIN

    <оператор>

END

Для визначення тіла тригера використовується процедурна мова, що розглянута у розділі, який присвячений збережуваним процедурам. До неї додається можливість доступу до старого (OLD) та нового (NEW) значення, яке змінюється у таблиці. Ще раз підкреслимо, що ця можливість недоступна у збережуваних процедурах. Запис OLD.Ім'я_стовпця дозволяє звернутися до значення, яке мало місце до внесення змін у чарунку таблиці, а значення NEW.Ім'я_стовпця – після внесення змін. У тому разі, якщо значення не змінилося, OLD.Ім'я_стовпця дорівнює NEW.Ім'я_стовпця.

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

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

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

Наприклад, для БД «БІБЛІОТЕКА» на етапі створення відношень був визначений зовнішній ключ, що не дозволяє вводити в атрибут СoAuthorship.AuthorCode (код автора книжки) таке значення, яке відсутнє в атрибуті BookAuthors.Code відношення, де створений довідник авторів книжок:

CREATE TABLE BookAuthors

    (Code INTEGER NOT NULL,

    FamilyName CHAR(30) NOT NULL,

    Name CHAR(30) NOT NULL,

    Patronymic CHAR(30) NOT NULL,

    Birthday DATE NOT NULL,

    Deatheday DATE,

    IssuePlace CHAR(100),

    PRIMARY KEY (Code));

CREATE TABLE CoAuthorship

    (BookCode INTEGER NOT NULL,

    AuthorCode INTEGER NOT NULL,

    FOREIGN KEY (AuthorCode) REFERENCES BookAuthors

        ON DELETE CASCADE

        ON UPDATE CASCADE,

    FOREIGN KEY (BookCode) REFERENCES Books

        ON DELETE CASCADE

        ON UPDATE CASCADE);

Для автоматичного виконання каскадного вилучення запису й зміни коду автора за допомогою тригерів необхідно, по-перше, вилучити визначення зовнішнього ключа з відношення СoАuthorship, а, по-друге, визначити тригери, які будуть виконувати каскадну зміну інформації.

Тригер, що забезпечує каскадне оновлення, має такий вигляд:

CREATE TRIGER UpAuthorCodeBooks FOR BookAuthors

    ACTIVE

    BEFORE UPDATE AS

    BEGIN

        IF (OLD.Code >< NEW.Code) THEN

            UPDATE Сoаuthorship

                SET AuthorCode = NEW.Code

                WHERE AuthorCode = OLD.Code

    END

Тригер, що реалізує каскадне вилучення:

CREATE TRIGER DelAuthorCodeBooks FOR BookAuthors

    ACTIVE

    AFTER DELETE AS

    BEGIN

        DELETE FROM Сoаuthorship

            WHERE AuthorCode = OLD.Code

    END

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

7.5. КОНТРОЛЬНІ ПИТАННЯ

  1. Які складові, що забезпечують цілісність реляційних даних, Вам відомі?
  2. За допомогою яких дій керують корпоративними обмеженнями цілісності?
  3. На які групи можливо поділити корпоративні обмеження цілісності?
  4. Як вибрати «механізм» реалізації корпоративних обмежень цілісності?
  5. Які SQL-оператори реалізують корпоративні обмеження цілісності?
  6. Які види корпоративних обмежень цілісності можливо реалізувати за допомогою SQL-операторів?
  7. Що спільного та відмінного є між різними видами збережуваних процедур?
  8. Які переваги має використання збережуваних процедур для реалізації корпоративних обмежень цілісності?
  9. Які можливості алгоритмічної мови збережуваних процедур Вам відомі?
  10. Коли виправдане використання збережуваних процедур для реалізації корпоративних обмежень цілісності?
  11. Що є спільного та відмінного між збережуваними процедурами та тригерами?
  12. Які події можливо обробити за допомогою тригерів?
  13. Які додаткові можливості має процедурна мова тригерів?
  14. Які особливості використання тригерів для забезпечення каскадних відновлень і змін даних Вам відомі?
Висновок

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

© Куваєв Я.Г., 2005—2023.

Всі права захищені.

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