чином, з погляду реляційної теорії, явне формулювання правил цілісності є зайвим - вони автоматично витікають з визначень понять ключа і зовнішнього ключа.
Проте, явне формулювання правил цілісності має певний практичний сенс. В більшості серйозних СУБД за виконанням цих обмежень стежить сама СУБД, якщо, звичайно, користувач явно оголосив потенційні і зовнішні ключі. Але, по-перше, для деяких систем можна допустити, щоб ці обмеження не виконувалися, а по-друге, деякі системи просто не підтримують поняття цілісності, наприклад, деякі "настільні" СУБД типа FoxPro 2.5. В цих випадках за цілісністю даних повинен стежити сам користувач, або програміст, розробляючий додаток для користувача.
Явне формулювання правил цілісності допомагає чітко зрозуміти, які небезпеки несе в собі зневага цими правилами.
Операції, що можуть порушити посилальну цілісність
Посилальна цілісність може порушитися в результаті операцій, що змінюють полягання бази даних. Таких операцій три - вставка, оновлення і видалення кортежів у відносинах. Оскільки у визначенні посилальної цілісності беруть участь два відношення - батьківські і дочірні, а в кожному з них можливі три операції - вставка, оновлення, видалення, то потрібно розглянути шість різних варіантів.
Для батьківського відношення
Вставка кортежу в батьківському відношенні. При вставці кортежу в батьківське відношення виникає нове значення потенційного ключа. Оскільки допустиме існування кортежів в батьківському відношенні, на які немає посилань з дочірнього відношення, то вставка кортежів в батьківське відношення не порушує посилальної цілісності.
Оновлення кортежу в батьківському відношенні. При оновленні кортежу в батьківському відношенні може змінитися значення потенційного ключа. Якщо є кортежі в дочірньому відношенні, що посилаються на кортеж, що обновляється, то значення їх зовнішніх ключів стануть некоректними. Оновлення кортежу в батьківському відношенні може привести до порушення посилальної цілісності, якщо це оновлення зачіпає значення потенційного ключа.
Видалення кортежу в батьківському відношенні. При видаленні кортежу в батьківському відношенні віддаляється значення потенційного ключа. Якщо є кортежі в дочірньому відношенні, що посилаються на кортеж, що видаляється, то значення їх зовнішніх ключів стануть некоректними. Видалення кортежів в батьківському відношенні може привести до порушення посилальної цілісності.
Для дочірнього відношення
Вставка кортежу в дочірнє відношення. Не можна вставити кортеж в дочірнє відношення, якщо значення зовнішнього ключа, що вставляється, некоректне. Вставка кортежу в дочірнє відношення привести до порушення посилальної цілісності.
Оновлення кортежу в дочірньому відношенні. При оновленні кортежу в дочірньому відношенні можна спробувати некоректно змінити значення зовнішнього ключа. Оновлення кортежу в дочірньому відношенні може привести до порушення посилальної цілісності.
Видалення кортежу в дочірньому відношенні. При видаленні кортежу в дочірньому відношенні посилальна цілісність не порушується.
Таким чином, посилальна цілісність у принципі може бути порушена при виконанні однієї з чотирьох операцій:
Оновлення кортежу в батьківському відношенні.
Видалення кортежу в батьківському відношенні.
Вставка кортежу в дочірнє відношення.
Оновлення кортежу в дочірньому відношенні.
Стратегії підтримки посилальної цілісності
Існують дві основні стратегії підтримки посилальної цілісності:
RESTRICT (ОБМЕЖИТИ) - не дозволяти виконання операції, що приводить до порушення посилальної цілісності. Це найпростіша стратегія, що вимагає тільки перевірки, чи є кортежі в дочірньому відношенні, пов'язані з деяким кортежем в батьківському відношенні.
CASCADE (КАСКАДУВАТИ) - дозволити виконання необхідної операції, але внести при цьому необхідні поправки в інших відносинах так, щоб не припуститися порушення посилальної цілісності і ззберігати всі наявні зв'язки. Зміна починається в батьківському відношенні і каскадний виконується в дочірньому відношенні. В реалізації цієї стратегії є одна тонкість, що полягає в тому, що дочірнє відношення саме може бути батьківським для деякого третього відношення. При цьому може бути додатково потрібно виконання якої-небудь стратегії і для цього зв'язку і т.д. Якщо при цьому яка-небудь з каскадних операцій (будь-якого рівня) не може бути виконана, то необхідно відмовитися від первинної операції і повернути базу даних в початкове полягання. Це найскладніша стратегія, але вона хороша тим, що при цьому не порушується зв'язок між кортежами батьківського і дочірнього відносин.
Ці стратегії є стандартними і присутні у всіх СУБД, в яких є підтримка посилальної цілісності.
Можна розглянути додаткові стратегії підтримки посилальної цілісності:
SET NULL (ВСТАНОВИТИ В NULL) - дозволити виконання необхідної операції, але всі виникаючі некоректні значення зовнішніх ключів змінювати на null-значення. Ця стратегія має два недоліки. По-перше, для неї вимагається припуститися використовування null-значень. По-друге, кортежі дочірнього відношення втрачають всякий зв'язок з кортежами батьківського відношення. Встановити, з яким кортежем батьківського відношення були зв'язані змінені кортежі дочірнього відношення, після виконання операції вже не можна.
SET DEFAULT (ВСТАНОВИТИ ПО УМОВЧАННЮ) - дозволити виконання необхідної операції, але всі виникаючі некоректні значення зовнішніх ключів змінювати на деяке значення, прийняте за умовчанням. Гідність цієї стратегії в порівнянні з попередньою в тому, що вона дозволяє не користуватися null-значеними. Недоліки полягають в наступному. По-перше, в батьківському відношенні повинен бути якийсь кортеж, потенційний ключ якого прийнятий як значення за умовчанням для зовнішніх ключів. Як такий "кортеж за умовчанням" звичайно приймають спеціальний кортеж, заповнений нульовими значеннями (не null-значеннями!). Цей кортеж не можна видаляти з батьківського відношення, і в цьому кортежі не можна змінювати значення потенційного ключа. Таким чином, не всі кортежі батьківського відношення стають рівнозначними, тому доводиться докладати додаткові зусилля для відстежування цієї нерівнозначності. Це платня за відмову від використовування null-значень. По-друге, як і у попередньому випадку, кортежі дочірнього відношення втрачають всякий зв'язок з кортежами батьківського відношення. Встановити, з яким кортежем батьківського відношення були зв'язані змінені кортежі дочірнього відношення, після виконання операції вже не можна.
У деяких реалізація СУБД розглядається ще одна стратегія підтримки посилальної цілісності:
IGNORE (ІГНОРУВАТИ) -