«Табель або перегляд може мати тільки один необхідний ключ.»
Oracle9i SQL Reference про обмеження використання обмежень унікальності

Твердження, подане як епіграф, взято з документації Oracle, але вся практика до прочитання документації вказувала на протилежне. Перевірка шляхом створення пари Unique Constraint підтвердила це. Наявна помилка в документації.

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

Почнемо самопочатку - Oracle9i Database Concepts Release 2 (9.2).У документації виділяється поняття «Цілісність даних» (Data Integrity), яке пов'язується з виконанням бізнес-правил, пов'язаних із БД. Data Integrity ділиться п'ять типів правил, частина з яких забезпечується «Обмеженнями цілісності» (Integrity Constraints ) СУБД Oracle :

1. NULL -правило - NOT NULL обмеження;

2. унікальні значення – обмеження унікального ключа;

3. значення первинного ключа – обмеження первинного ключа;

4. правила цілісності посилання - обмеження зовнішнього ключа (або «обмеження посилальної цілісності» - в документації Oracle зустрічаються обидві назви);

5. перевірка комплексного обмеження - Check-обмеження.

(Тут ліворуч від тире представлено правило «Цілісності даних», а праворуч – тип «Обмежень цілісності», що реалізує це правило)

Четвертий тип правил «Цілісності даних» є складовим, і забезпечується «Обмеженнями цілісності» лише частково:

1. виставлення у NULL залежних даних при видаленні довідкових даних;

2. каскадне видалення залежних даних під час видалення довідкових даних;

3. а також відсутність будь-якої дії над залежними даними при зміні або видаленні довідкових даних. (Тут для мене залишилася неясність у плані відмінності Restrict від No Action. Може, хтось із читачів допоможе виявити відмінність…)

Існуючі підтипи четвертого пункту «Цілісності даних», що залишилися:

oвиставлення в NULL залежних даних за зміни довідкових даних;

oкаскадна зміна залежних даних при зміні довідкових даних;

oвиставлення значення за замовчуванням залежних даних при зміні або видаленні довідкових даних;

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

Далі для стислості і звички використовуватиму назви «Обмеження цілісності» в англійському варіанті (співвіднесення з вищезгаданими російськими назвами, на мій погляд, очевидно), а замість «Обмеження цілісності» писати просто Обмеження.

Отже, UNIQUEKeyConstraint. Це Обмеження вимагає, щоб кожне значення у полі ключа було унікальним. Під поняттям "значення" тут мається на увазі певна величина, а NULL-значення під дане визначенняне підпадає, так що одне, два, і навіть усі поля в ключі UNIQUE Key Constraint можуть дорівнювати NULL. На відміну від ключа PRIMARY Key Constraint , в якому значення NULL не допускається зовсім.

При створенні UNIQUE Key Constraints або PRIMARY Key Constraints неявно створюється унікальний індекс за полями таблиці, на які накладається дане Обмеження. Однак, якщо якийсь (неважливо - унікальний чи неунікальний) індекс по полях ключа вже використовується, то використовуватиметься саме він замість неявного створеннянового. При видаленні цих обмежень будуть видалятись і індекси. Унікальні Обмеження, створені з атрибутом DEFERRABLE (див. нижче), завжди використовують неунікальні індекси. При видаленні таких обмежень унікальні індекси залишаються.

Referential Integrity Constraint вимагає існування в батьківській (довідковій) таблиці UNIQUE Key Constraintабо PRIMARY Key Constraint.За відсутності Обмеження NOT NULL на якомусь полі, що входить до Referential Integrity Constraint , у цьому полі

допускається значення NULL, і такий Referential Integrity Constraint буде вважатися правильним.

• Якщо на зовнішньому ключі немає індексу. Тоді при видаленні або зміні первинного ключа батьківської таблиці Oracle буде виставляти блокування дочірньої таблиці на рівні таблиці, звільняючи це блокування відразу після її отримання. Якщо зовнішній ключ визначений як ON DELETE CASCADE , видалення записів з батьківської таблиці буде приводити до share-subexclusive блокувань на дочірній таблиці. Блокування всієї дочірньої таблиці, що розділяється, також знадобиться при зміні тих полів у батьківській таблиці, на які посилаються поля дочірньої таблиці. Блокування, що розділяється, дозволяє тільки читання даних, так що ні вставка, ні видалення, ні зміна даних у дочірній таблиці не будуть доступні до тих пір, поки не завершиться транзакція на батьківській таблиці.
• Якщо на зовнішньому ключі є індекс, то ніяких блокувань на рівні таблиці вже не буде, і при будь-якому видаленні або зміні даних у батьківській таблиці, в дочірній таблиці будуть блоковані до завершення транзакції лише окремі відповідні записи (ексклюзивне блокування на рівні рядків).

CHECKIntegrityConstraints.Допускаються на одному або кількох полях таблиці і вимагає як результат виконання певної умови TRUE або UNKNOWN для кожного рядка таблиці. Показово, що під UNKNOWN мається на увазі… NULL! Іншими словами, якщо скрізь (принаймні, дотримуючись тієї ж документації Oracle) NULL-значення не дорівнює нічому, в тому числі і самому собі, то воно «працює» як TRUE. Смішно, чи не так?

особливості:

• може використовуватися тільки Булеве вираз;
• не можна використовувати підзапити, SQL-функції чи послідовності (цікаво, чому?);
• не можна використовувати SYSDATE, UID, USE R, USERENV, LEVEL, ROWNUM.

Кількість CHECK Integrity Constraints необмежена, але порядок їх спрацьовування непередбачуваний. Ну, і при використанні малих літералів або таких SQL-функцій, як TO_CHAR, TO_DATE, TO_NUMBER з параметрами підтримки глобалізації як аргументи, Oracle використовує значення цих параметрів за умовчанням на рівні бази. Ці значення можна переписати у створюваному CHECK Integrity Constraint.

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

Режим SET CONSTRAINTS.

Оператор SET CONSTRAINTS робить Обмеження або DEFERRED , або IMMEDIATE (DEFERRED і IMMEDIATE відносяться до атрибутів Обмежень, про що далі) для частини транзакції. Цей операторможна використовувати для встановлення режиму або списку Обмежень, або для всіх (ALL ) Обмежень. Дія цього оператора закінчується разом із завершенням поточної транзакції, або з початком дії ще одного такого оператора. Цей оператор недоступний у тригерах.

SET CONSTRAINTS … IMMEDIATE спочатку викликає перевірку наявності відкладених раніше спрацьовувань Обмежень, а потім уже спрацьовують Обмеження, викликані операторами, що виконуються в поточній транзакції. Будь-яке порушення Обмеження при такому процесі буде просигналізовано помилкою, а при досягненні COMMIT'у буде викликано повний відкатпоточної транзакції. Оператор ALTER SESSION також може мати вираз SET CONSTRAINTS, але тільки для всіх обмежень (не можна їх перерахувати списком). Це еквівалентно виконання оператора SET CONSTRAINTS на самому початку кожної транзакції.

Виконання оператора SET CONSTRAINTS … IMMEDIATE перед завершенням транзакції дозволяє визначити успішність майбутнього COMMIT'у і уникнути зайвих відкатів.

Стан обмежень.

За допомогою операторів CREATE TABLE або ALTER TABLE можна задавати стан кожного Обмеження на рівні таблиці, використовуючи такі вирази:

• ENABLE гарантує задоволення всіх вхідних даних Обмеження;
• DISABLE дозволяє вхідним даним не відповідати Обмеженню;
• VALIDATE гарантує, що всі дані, що вже є в таблиці, відповідають Обмеженню;
• NOVALIDATE дозволяє вже наявним у таблиці даним не відповідати Обмеженню;

…та їх комбінації:

• ENABLE VALIDATE аналогічно ENABLE і гарантує, що абсолютно всі (і вже вставлені, і вставлені) записи задовольняють Обмеження;
• ENABLE NOVALIDATE гарантує задоволення Обмеження всіх вхідних даних, проте дані, що вже є в таблиці, можуть не відповідати Обмеженню;
• DISABLE NOVALIDATE аналогічно DISABLE. Не гарантується задоволення Обмеження як вхідних даних, так і наявних у таблиці;
• DISABLE VALIDATE відключає Обмеження, видаляє індекс, на якому воно будувалося, та забороняє будь-які зміни на полях, що входять до Обмеження.

… і трохи про особливості застосування:

· вираз ENABLE має на увазі ENABLE VALIDATE;

· вираз DISABLE має на увазі DISABLE NOVALIDATE;

· VALIDATE і NOVALIDATE нічого не мають на увазі щодо ENABLE і DISABLE (скажімо так, вони є залежною частиною висловлювання при ENABLE і DISABLE );

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

· при зміні стану з NOVALIDATE в VALIDATE виконується перевірка всіх даних, що є в таблиці, що може зайняти дуже багато часу. Навпаки, при наведенні стану Обмеження з VALIDATE в NOVALIDATE просто «забувається», що дані колись відповідали Обмеженню;

· Переведення одиночного обмеження зі стану ENABLE NOVALIDATE в стан ENABLE VALIDATE не блокує читання, запису або інших DDL операцій, вони можуть бути виконані паралельно.

І останні важливі зауваження.

• Під час створення Обмеження можна вказати як атрибут, чи можливо в подальшому в ході транзакції встановити оператором SET CONSTRAINTS (див. вище) відкладену (DEFERRED ) перевірку даного Обмеження. За замовчуванням виставляється NOT DEFERRABLE (що воно означає, гадаю, зрозуміло). Після створення Обмеження змінити значення виставленого атрибуту не можна, крім перестворивши Обмеження, так що «сім разів подумай»!
• INIT IALLY є додатковим атрибутом до DEFERRABLE, який може бути переписаний оператором SET CONSTRAINT (знов див. вище), і який визначає стандартну поведінку при спрацьовуванні Обмеження з встановленим атрибутом DEFERRABLE. При створенні Обмеження за замовчуванням виставляється INIT IALLY IMMEDIATE , тоді спрацьовування Обмеження відбуватиметься щоразу під час виконання окремого оператора, при виставленні INIT IALLY DEFERRED спрацьовування Обмеження буде відкладено до закінчення кожної транзакції. Для NOT DEFERRABLE такого додаткового атрибуту не потрібно, оскільки він є INIT IALLY IMMEDIATE за визначенням.
• Вираз RELY. За умовчанням при зміні Обмеження (за допомогою ALTER TABLE або MODIFY constraint) виставляється NORELY. А означає воно наступне: чи варто Oracle приймати в розрахунок Обмеження, що знаходиться в стані NOVALIDATE, для перезапису запиту? RELY активує існуюче Обмеження в режимі (тут у документації SQL Reference використовується слово «mode», хоча я вже звик до слова «state» з Concepts , - мабуть, писали різні люди, забувши домовитися про терміни) NOVALIDATE, що дозволить переписати запит, який інакше міг бути переписаним лише з Обмеженням у режимі VALIDATE. Приблизно так. Докладніше - наступного разу.
• EXCEPTIONS INTO визначає схему та таблицю, в яку будуть внесені ROWID, що порушують Обмеження при зміні його (Обмеження) стану. Якщо ім'я схеми та таблиці не вказати, то передбачатиметься, що потрібно використовувати таблицю з ім'ям EXCEPTIONS у поточній схемі.

От і все. На сьогодні.

Цілісність даних – це механізм підтримки відповідності бази даних предметної галузі. У реляційної моделіданих визначено дві базові вимоги забезпечення цілісності:

цілісність посилань

цілісність відносин.

Цілісність відносин.

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

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

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

при додаванні записів до таблиці перевіряється унікальність їх первинних ключів

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

Цілісність посилань

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

Зв'язки між цими відносинами описуються термінах функціональних залежностей.

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

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

Нехай, наприклад, дано відносини ВІДДІЛ ( N_ВІДДІЛУ, ІМ'Я_ВІДДІЛУ) та СПІВРОБІТНИК ( N_СПІВРОБІТНИКА, N_ВІДДІЛУ, ІМ'Я_СПІВРОБІТНИКА), в яких зберігаються відомості про працівників підприємства та підрозділи, де вони працюють. Відношення ВІДДІЛ у цій парі є батьківським, тому його первинний ключ "N_відділу"є у дочірньому відношенні СПІВРОБІТНИК. Вимога цілісності за посиланнями означає тут, що у таблиці СПІВРОБІТНИК неспроможна бути кортеж зі значенням атрибута "N_відділу", що не зустрічається у таблиці ВІДДІЛ. Якщо таке значення щодо ВІДДІЛ відсутнє, значення зовнішнього ключа щодо СПІВРОБІТНИК вважається невизначеним.

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

Існують дві основні стратегії підтримки цілісності посилань :

RESTRICT (ОБМЕЖИТИ) - не дозволяти виконання операції, що призводить до порушення цілісності посилань. Це сама проста стратегія, що вимагає лише перевірки, чи є кортежі у дочірньому відношенні, пов'язані з деяким кортежем у батьківському відношенні.

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

Первинний та зовнішній ключі

Оскільки відношення - це безліч, а безлічі за визначенням не містять збігаються елементів, то ніякі два кортежі відносини не можуть бути дублікатами один одного в будь-якій довільно Наразічасу. Нехай R - Відношення з атрибутами A1, A2, ..., An. Кажуть, що безліч атрибутів K = (Ai, Aj, ..., Ak) відносини R є можливим ключем R тоді і тільки тоді, коли задовольняються дві незалежні від часу умови:

Унікальність: у довільний заданий момент часу жодні два різні кортежі R не мають одного і того ж значення для Ai, Aj, ..., Ak.

Мінімальність: жоден із атрибутів Ai, Aj, ..., Ak не може бути виключений з K без порушення унікальності.

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

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

p align="justify"> Різні об'єкти предметної області, інформація про які зберігається в базі даних, завжди взаємопов'язані один з одним. Такі взаємозв'язки відбиваються в реляційних базахданих за допомогою зовнішніх ключів , які пов'язують кілька відносин.

Формальне визначення.

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

Зауваження. Зовнішній ключ, як і можливий, може бути простим і складним.

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

Зауваження. Зовнішній ключ, як правило, не має властивості унікальності. Так має бути, т.к. у дочірньому відношенні може бути кілька кортежів, що посилаються на той самий кортеж батьківського відношення. Це, власне, і дає тип відносини "один-багатьом".

Зауваження. Для зовнішнього ключа не потрібно, щоб він був компонентом певного можливого ключа.

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

Ставлення – Таблиця (іноді Файл), Кортеж – Рядок (іноді Запис), Атрибут – Стовпець, Поле.

7. Обмеження цілісності

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

7.1 Що таке обмеження цілісності

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

Спочатку – трохи теорії.

Усі обмеження цілісності можна розділити на три великі категорії:

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

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

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

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

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

Властивість (С) – узгодженість транзакцій визначається наявністю поняття узгодженості бази даних.

Визначення 2. Обмеження цілісності - це деяке твердження, яке може бути істинним чи хибним залежно стану бази даних.

Визначення 3. База даних знаходиться в узгодженому (цілісному) стані якщо виконані (задоволені) всі обмеження цілісності, визначені для бази даних.

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

- Відмовавиконати "незаконну" операцію.

Виконання компенсуючихдій.

17.3. Класифікація обмежень цілісності.

Обмеження цілісності можна класифікувати кількома способами:

• За способами реалізації.
• За часом перевірки.
• По області дії.

17.3.1. Класифікація обмежень цілісності за способами реалізації

Кожна система має свої засоби підтримки обмежень цілісності. Розрізняють два способи реалізації:

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

Визначення 4. Декларативна підтримка обмежень цілісності полягає у визначенні обмежень засобами мови визначення даних (DDL – Data Definition Language). Зазвичай засоби декларативної підтримки цілісності (якщо вони є в СУБД) визначають обмеження на значення доменів та атрибутів, цілісність сутностей (потенційні ключі відносин) та цілісність посилань (цілісність зовнішніх ключів). Декларативні обмеження цілісності можна використовувати при створенні та модифікації таблиць засобами мови DDL або у вигляді окремих тверджень (ASSERTION).

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

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

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

За часом перевірки обмеження діляться на:

• Негайно перевірені обмеження.
• Обмеження із відкладеною перевіркою.

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

Визначення 7. Обмеження з відкладеною перевіркою перевіряється у момент фіксації транзакції оператором COMMIT WORK. Усередині транзакції обмеження може виконуватися. Якщо на момент фіксації транзакції виявляється порушення обмеження з відкладеною перевіркою, то транзакція відкочується.

17.3.3. Класифікація обмежень цілісності у сфері дії.

По області дії обмеження поділяються на:

• Обмеження домену
• Обмеження атрибуту
• Обмеження кортежу
• Обмеження відносин
• Обмеження бази даних

17.3.3.1. Обмеження домену.

Визначення 8. Обмеження цілісності домену є обмеження, що накладаються тільки на допустимі значення домену. Власне, обмеження домену мають бути частиною визначення домену.

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

17.3.3.2. Обмеження атрибуту.

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

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

17.3.3.3. Обмеження кортежу.

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

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

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

17.3.3.4. Обмеження відносин.

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

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

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

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

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

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

17.3.3.5. Обмеження баз даних.

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

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

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

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

Обмеження цілісності данихдозволяють додати їм вимоги, додаткові до дотримання типу. Заявлені (схемні, формальні, "декларативні") обмеження цілісності записуються ("проголошуються") у вигляді умов, які повинні дотримуватися явно як такі, на рівні схеми даних і цим відрізняються від правил цілісності, сформульованих у вигляді запрограмованих перевірок (див. нижче). Тому інакше такі обмеження можна називати "явними". Оригінальний термін має повну назву " integrity data constraints" - "обмеження на значення даних, що накладаються для більш точного облікуобставин предметної області " , але часто скорочується до " integrity constraints " і навіть просто " constraints " . Слово " integrity " навряд чи добре зрозуміло масам розробників.

Саме поняття обмежень цілісності, що заявляється, в SQL було успадковано від реляційної моделі і ускладнювалося разом з розвитком стандарту. У Oracle номенклатура обмежень цілісності загалом відповідає SQL -92 (якщо обсяг реалізації не витриманий), але з доведено рівня SQL :1999. Так, Oracle не дозволяє завести обмеження цілісностіна рівні БД (за допомогою службового слова ASSERTION ) і дуже обмежений у формулюванні умови перевірки значень конструкцією CHECK тим, що не допускає звернення до даних бази.

Слово ASSERTION із стандарту SQL підказує ще один переклад (і розуміння) integrity constraints, як "ствердні обмеження цілісності".

Заявлені обмеження цілісності в Oracle можна ставити на рівнях:

• окремого поля рядка у таблиці;
• окремого рядка;
• пари таблиць.

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

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

• ALTER TABLE … MODIFY - додавання обмежень всіх видів та зняття обмеження NOT NULL;
• ALTER TABLE … ADD/DROP - додавання та зняття обмежень усіх видів, крім NOT NULL.

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

ALTER TABLE projx RENAME CONSTRAINT sys_c0011509 TO name_is_needed;

Різновиди обмежень, що заявляються, цілісності

Обмеження NOT NULL

Обмеження NOT NULL зобов'язує стовпець або групу стовпців завжди мати значення (якщо група - хоча б в одному полі). Вимога непустоти стовпця вкрай бажана, тому що позбавляє програміста численних турбот, пов'язаних з особливостями обробки NULL . На жаль, вимоги предметної області та деякі дії SQL (наприклад, GROUP BY ROLLUP … ) неможливо зовсім відмовитися від стовпців з властивістю NULL .

Це єдине з обмежень цілісності, інформація про яке зберігається у таблиці USER_CONSTRAINTS , а й у таблиці USER_TAB_COLUMNS як властивості стовпця. (Колись ознака NULL/NOT NULL формально вважався властивістю стовпця, а чи не обмеженням цілісності). З цієї причини додавання та скасування цього обмеження оформляється за правилами зміни властивості стовпця, тільки через ключове слово MODIFY:

ALTER TABLE proj MODIFY (budget NOT NULL); -- створення обмеження з системним ім'ям; дужки необов'язкові ALTER TABLE proj MODIFY (budget NULL); - скасування обмеження; дужки необов'язкові ALTER TABLE proj MODIFY (budget CONSTRAINT is_mandatory NOT NULL); - Створення обмеження з ім'ям, заданим програмістом

У сучасних версіях Oracle самостійне обмеження NOT NULL буде оформлено технічно як обмеження виду CHECK з умовою перевірки: budget IS NOT NULL і одночасно буде зафіксовано в USER_CONSTRAINTS значенням NULLABLE = "Y" . Властивість NOT NULL , що з правила первинного ключа, буде відбито лише USER_CONSTRAINTS .

Первинні ключі

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

ALTER TABLE proj ADD PRIMARY KEY (projno, pname); -- створення обмеження (первинний ключ на основі двох стовпців) із системним ім'ям ALTER TABLE proj DROP PRIMARY KEY; - скасування обмеження ALTER TABLE proj ADD CONSTRAINT pk_proj PRIMARY KEY (projno); - Створення обмеження з ім'ям, заданим програмістом

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

Деякі типи стовпців не допускаються до формування первинного ключа (наприклад, LOB або TIMESTAMP WITH TIME ZONE).

Унікальність значень у стовпцях

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

Приклад створення:

ALTER TABLE proj ADD UNIQUE (pname);

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

ALTER TABLE proj MODIFY (pname NOT NULL);

він зможе грати роль ключа в реляційній моделі та бути оголошений первинним (шляхом заміни двох обмежень: UNIQUE та NOT NULL на одне PRIMARY KEY). Якщо ж унікальною оголошується група шпальт, повідомити їй властивості ключа засобами SQLскладніше (обов'язковість хоча б одного значення в унікальній групі можна вимагати обмеженням виду CHECK).

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

ALTER TABLE t ADD CONSTRAINT xx UNIQUE (a, b); - Помилка!

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

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

ALTER TABLE proj ADD (ldept NUMBER (2)); ALTER TABLE proj ADD FOREIGN KEY (ldept) REFERENCES dept (deptno) ;

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

Зовнішніх ключів у таблиці можна визначити кілька. Наприклад, при більш ретельному моделюванні прикладу "співробітники - відділи" на додаток до наявного зовнішнього ключа DEPTNO таблиці EMP можна було б оголосити зовнішнім ключем стовпець JOB, змусивши його посилатися на окрему таблицю з описами штатних посад.