ЗАСОБИ SQL обмеження

Почнемо з опису підтримки в мові SQL (або, швидше, здебільшого, з констатації відсутності такої підтримки) схеми класифікації обмежень, описаної в розділі 99

■ У мові SQL взагалі не підтримуються обмеження типу, за винятком тих примітивних обмежень, які є прямим наслідком застосування певного фізичного представлення Наприклад, як було показано в розділі 5, допустимо стверджувати, що значення типу WEIGHT повинні бути представлені у вигляді чисел DECIMAL (5,1), але не можна вказати, що ці числа повинні бути більше нуля і менше 5000

■ У мові SQL (безумовно) підтримуються обмеження атрибута

■ У мові SQL не підтримується обмеження змінної відносини як такі

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

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

СКЛАДНІСТЬ

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

У мові SQL відсутній також безпосередня підтримка обмежень переходу, але такі обмеження можуть бути реалізовані процедурно за допомогою тригерів Крім того, в цій мові не представлено явно поняття предиката змінної відносини (або таблиці), а ця особливість мови SQL є дуже важливою, як показано в наступному розділі

Обмеження базової таблиці

Обмеження базової таблиці в мові SQL задаються в операторі CREATE TABLE або ALTER TABLE Кожне таке обмеження представляє собою обмеження потенційного ключа, обмеження зовнішнього ключа або обмеження перевірки Розглянемо кожне з них по черзі

Примітка Перед визначенням будь-якого з цих обмежень може перебувати необовязкова специфікація CONSTRAINT <constraint  name&gt,   яка дозволяє привласнити обмеженню імя Автор не розглядає цю опцію для скорочення викладу (але необхідно зазначити, що на практиці, мабуть, слід присвоювати імена всім обмеженням) Тут також не розглядаються деякі скорочення, наприклад, можливість задавати потенційний ключ (як вбудований у складі визначення шпальти), з тієї ж причини

Потенційні ключі

Будь-яке визначення потенційного ключа SQL приймає одну з наступних двох форм

PRIMARY KEY ( &ltcolumn name commalist&gt

) UNIQUE ( &ltcolumn name commalist&gt )

В обох випадках вираз &ltcolumn name commalist&gt з розділеним комами списком імен стовпців не повинно бути пустим20 Будь конкретна базова таблиця може мати максимум однієї специфікації з визначенням первинного ключа PRIMARY KEY, але будь-яке кількість специфікацій потенційного ключа UNIQUE У разі PRIMARY KEY кожен вказаний стовпець додатково розглядається як відповідний вимогу NOT NULL, тобто що не містить порожніх значень, навіть якщо ключове слово NOT NULL не задано явно (див наведене нижче опис обмежень перевірки)

20 Див вправу 910

Зовнішні ключі

Визначення зовнішнього ключа мови SQL приймає наступну форму

FOREIGN KEY ( &ltcolіmn name commalist> )

REFERENCES &ltbase table name&gt [ ( &ltcolumn name

commalist&gt ) ] [ ON DELETE &ltreferential action&gt ] [ ON

UPDATE &ltreferential action&gt ]

Тут специфікація посилального дії &ltreferential action&gt може приймати значення NO ACTION (ПО замовчуванням), RESTRICT, CASCADE, SET DEFAULT АБО SET NULL21 Відкладемо обговорення конструкцій SET DEFAULT і SET NULL до глави 19 інші опції описані в розділі 910 Друга специфікація&ltcolumn  name  commalist&gt вимагається, якщо зовнішній ключ посилається на потенційний ключ, який не є первинним ключем

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

Обмеження перевірки

Будь-яке обмеження перевірки в мові SQL приймає наступну форму

CHECK  (   )

Припустимо, що СС – обмеження перевірки для базової таблиці т У такому випадку вважається, що в таблиці т обмеження СС порушується тоді і тільки тоді, коли ця таблиця в даний час містить по Щонайменше один рядок (див останній абзац даного підрозділу) та перевірка поточного значення т тягне за собою те, що логічне вираз для СС приймає значення FALSE

Примітка Загалом, слід зазначити, що вирази &ltbool ехр> мови SQL можуть бути як завгодно складними навіть в даному контексті, який розглядається вони явно не обмежуються посиланнями тільки на базову таблицю т, але можуть замість цього посилатися на будь-яку доступну частина бази даних

Нижче наведено приклад оператора CREATE TABLE, В якому ілюструєтьсязастосування обмежень базової таблиці всіх трьох видів

CREATE TABLE SP

( S# S# NOT NULL, P# P# NOT NULL, QTY QTY NOT NULL,

PRIMARY KEY ( S#, P# ),

FOREIGN KEY ( S# ) REFERENCES S

ON DELETE CASCADE ON UPDATE

CASCADE, FOREIGN KEY ( P# )

REFERENCES P

ON DELETE CASCADE

ON UPDATE CASCADE, CHECK ( QTY

&gt QTY ( 0 ) AND QTY &lt QTY { 5000 ) ) )

21 До речі, слід зазначити, що для підтримки деяких дій типу (Зокрема CASCADE) потрібно, щоб система (хоча б неявно) підтримувала деякі види операцій множинного реляційного присвоювання Причому це вимога існує незважаючи на те, що подібні операції не підтримуються мовою SQL як такі

Тут передбачається, що атрибути s # і Р # були явно визначені як призначені для використання, відповідно, в якості первинних ключів для таблиць S і Р Крім того, в цьому операторі використовується скорочення, згідно з яким обмеження перевірки у вказаній нижче формою може бути замінене простий специфікацією NOT NULL у визначенні розглянутого стовпця &ltcolumn name&gt.

CHECK ( &ltcolumn name&gt IS NOT NULL )

Тому в даному прикладі три обмеження перевірки, які могли виявитися досить складними, замінені трьома специфікаціями NOT NULL

На закінчення цього підрозділу ще раз повторимо зауваження, що обмеження базової таблиці SQL завжди вважається задоволеним, якщо розглянута базова таблиця виявилася порожньою, навіть якщо це обмеження має форму (скажімо) 1 = 2 (Або навіть, якщо на те пішло, воно по суті має таку форму, що ця таблиця не повинна бути порожньою!)

Твердження

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

CREATE ASSERTION &ltconstraint

паті> CHECK ( &ltbool exp&gt )

;

А нижче показаний синтаксис оператора DROP ASSERTION

DROP ASSERTION &ltconstraint name&gt

Зверніть увагу на те, що на відміну від більшості інших форм оператора DROP мови SQL (наприклад, DROP TYPE, DROP TABLE, DROP VIEW), У операторі DROP ASSERTION не передбачені дві протилежні опції RESTRICT і CASCADE

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

1&nbsp&nbsp&nbsp Значення статусу кожного постачальника повинно знаходитися в межах від 1 до 100

включно

CREATE ASSERTION SC1 CHECK

( NOT EXISTS ( SELECT * FROM S

WHERE SSTATUS &lt 0    OR

SSTATUS &gt 100 ) )

2&nbsp&nbsp&nbsp Кожен постачальник з Лондона має статус 20

CREATE ASSERTION SC2 CHECK

( NOT EXISTS ( SELECT * FROM S

WHERE SCITY = London AND    SSTATUS ≠ 20 ) )

;

3&nbsp&nbsp&nbsp&nbsp Якщо взагалі є які-небудь деталі, то щонайменше одна з них повинна бути синього кольору

CREATE ASSERTION РСЗ CHECK (NOT EXISTS (SELECT * FROM P)

OR EXISTS ( SELECT * FROM P

WHERE PCOLOR = COLOR (Blue) ) )

4&nbsp Різні постачальники не можуть мати однакові номери постачальників

CREATE ASSERTION SC4 CHECK

( UNIQUE ( SELECT SS# FROM S ) )

У цьому операторі UNIQUE являє собою операцію SQL, яка приймає як фактичного параметра таблицю і повертає значення TRUE, якщо ця таблиця не містить дублікатів рядків, а в іншому випадку повертає значення FALSE

5&nbsp Кожна поставка виконується існуючим постачальником

CREATE ASSERTION SSP5 CHECK

. ( NOT EXISTS

( SELECT * FROM SP

WHERE NOT EXISTS

( SELECT * FROM S

WHERE SS# = SPS# ) ) )

Жоден постачальник зі статусом менше 20 не постачає будь-які деталі в кількості більше 500

CREATE ASSERTION SSP6 CHECK

( NOT EXISTS ( SELECT * FROM S, SP

WHERE SSTATUS &lt 20 AND   SS#

= SPS# AND   SPQTY &gt QTY ( 500

) ) ) .

Коротко розглянемо ще один приклад Для цього звернемося до наведеного нижче визначенню подання з попереднього розділу

CREATE VIEW LONDON_SUPPLIER AS SELECT S#, SNAME,

STATUS FROM  S WHERE CITY = London

Як вже було сказано, в це визначення подання не можна включати специфікацію в такій формі

UNIQUE   (   S#   )   

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

CREATE ASSERTION LSK CHECK

( UNIQUE ( SELECT S# FROM LONDON_SUPPLIER ) )

Відкладена перевірка

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

мові SQL ограніченія22 можуть бути визначені як допускають відкладену перевірку (DEFERRABLE) або що не допускають таку перевірку (NOT DEFERRABLE) якщо ліміт оголошено як DEFERRABLE, воно може бути додатково визначено як відкладене спочатку (INITIALLY DEFERRED) або негайно виконується з самого початку (INITIALLY IMMEDIATE) ці ключові слова визначають стан обмеження на початку кожної транзакції Обмеження NOT DEFERRABLE завжди перевіряються негайно, а перевірку обмежень DEFERRABLE можна динамічно включати і вимикати за допомогою наступного оператора

SET  CONSTRAINTS  &ltconstraint name commalist&gt &ltoption&gt   

Тут опція &ltoption&gt приймає значення IMMEDIATE або DEFERRED Приклад застосування такої опції наведено нижче

SET CONSTRAINTS SSP5, SSP6 DEFERRED

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

Тригери

Оператор CREATE TRIGGER мови SQL виглядає наступним чином

CREATE TRIGGER &lt trigger name&gt

&ltbefore or after&gt &ltevent&gt ON &ltbase table

name&gt [ REFERENCING &ltnaming commalist&gt } [

FOR EACH &ltrow or statement&gt ] [ WHEN (

&ltbool exp&gt ) ] &ltaction&gt

Пояснення до цього оператора наведені нижче

1 Специфікація із зазначенням часу перевірки до або після активізації тригера,

&ltbefore  or after&gt, приймає значення BEFORE або AFTER (у стандарті SQL не підтримує ключове слово INSTEAD OF, але в деяких програмних продуктах така підтримка передбачена)

2 Подія &ltevent&gt може приймати значення INSERT, DELETE або UPDATE Зна чення UPDATE може додатково уточнюватися за допомогою специфікації OF

&ltcolumn  name    commalist&gt.

3 Кожне визначення іменування &ltnaming&gt може приймати одну з наступних форм

22 Але деякі обмеження мають бути обовязково вказані як відносяться до типу NOT DEFERRABLE Наприклад, якщо FK – зовнішній ключ, то обмеження потенційного ключа для відповідного потенційного ключа має бути задане як NOT DEFERRABLE

OLD    ROW    AS

&ltname&gt  NEW  ROW

AS  &ltname&gt  OLD

TABLE AS &ltname&gt

NEW   TABLE   AS

&ltname&gt

4 Специфікація з визначенням рядка або оператора &ltrow   or    statement&gt

приймає значення ROW або STATEMENT (STATEMENT застосовується по умолча нию) Ключове слово ROW означає, що тригер активізується для кожної від слушною рядки, на яку поширюється дія триггерного оператора, а STATEMENT означає, що тригер активізується тільки один раз для даного оператора, що розглядається як єдине ціле

5 Якщо визначена конструкція WHEN, вона означає, що дія &ltaction&gt повинно виконуватися, тільки якщо логічний вираз приймає значен ня TRUE

6 Специфікація &ltaction&gt задає окремий оператор SQL (але цей окремий оператор може бути досить складним, тобто складовим, а це неформально оз начає, що такий оператор може складатися з послідовності операторів, позначених розмежувачами BEGIN і END)

Нарешті, нижче показаний синтаксис оператора DROP TRIGGER

DROP TRIGGER &lttrigger name&gt

Як і в операторі DROP ASSERTION, в операторі DROP TRIGGER не передбачено використання пари протилежних опцій RESTRICT І CASCADE

98 РЕЗЮМЕ

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

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

Якщо (IF) деякі кортежі присутні в деяких змінних відносини, то

(THEN) ці кортежі задовольняють деякій умові

(Обмеження типу характеризуються певними відмінностями, як показано в наведеному нижче описі) У цій главі розглядається синтаксис визначення таких обмежень, заснований на тій версії мови Tutorial D, в якій застосовується числення предикатів, і зазначено, що в цьому синтаксисі не передбачено будь-яких способів, за допомогою яких користувач міг би повідомити СУБД, коли повинна бути виконана перевірка таких обмежень, оскільки бажано, щоб час цієї перевірки визначала сама СУБД Крім того, в цьому розділі стверджується (але поки ще без обгрунтування такої позиції), що вся перевірка обмежень повинна виконуватися негайно

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

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

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

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

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

■ Обмеження типу визначають допустимі значення для конкретного типу (або домена) і перевіряються під час виклику відповідного селектора

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

■ Обмеження змінної відносини задають допустимі значення для конкретної змінної відносини і перевіряються при оновленні розглянутої змінної відносини

Обмеження бази даних задають допустимі значення для конкретної бази даних і перевіряються при оновленні розглянутої бази даних

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

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

У завершення даної глави були описані відповідні засоби мови SQL Обмеження типу в мові SQL розвинені дуже слабо по суті, вони зводяться до визначення того, що розглянутий тип повинен мати певне фізичне уявлення Обмеження базової таблиці SQL (які забезпечують в якості окремого випадку підтримку для ключів) і загальні обмеження (твердження), являють собою аналоги обмежень змінної відносини і бази даних (крім обмежень переходу), але їх класифікація визначена набагато менш чітко в порівнянні з мовою Tutorial D (фактично вони є майже взаємозамінними і не зовсім зрозуміло, чому в мові SQL передбачені й обмеження базової таблиці, і загальні обмеження) Крім того, мова SQL підтримує відкладену перевірку обмежень Нарешті, в цьому розділі коротко показано, як у мові SQL здійснюється підтримка тригерів

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*