Чотири грані цілісності
Цілісність сутностей реалізується через первинні ключі. Правила забезпечення цілісності сутностей забороняють первинним ключам мати невизначені значення або отримувати їх в результаті будь-яких маніпуляцій з даними. Ці правила гарантують доступність кожного рядка таблиці при пошуку або модифікації даних. Можна знайти будь-який рядок таблиці, якщо задати значення її первинного ключа.
Стандартним способом забезпечення цілісності сутностей в середовищі SQL Server є визначення первинних ключів для кожної таблиці. Для цього в оператори CREATE TABLE або ALTER TABLE вводиться додаткова специфікація, як показано в лістингу 1. При виконанні такої команди SQL Server будує унікальний індекс по первинному ключу. Такий підхід гарантує втілення в життя правила, яке забороняє вводити дублікат значення в стовпець, по якому побудований унікальний індекс.
Цілісність посилань гарантує, що значення в одній таблиці посилається на значення, яке існує в іншій. Правило цілісності посилань свідчить, що значення зовнішнього ключа повинно або лежати в домені пов'язаного з ним первинного ключа, або бути невизначеним. Домен є безліч допустимих значень для заданого стовпчика.
Зовнішні ключі, тобто стовпці, які встановлюють зв'язку посилається таблиці, званої «майстер», з довідковою таблицею, званої «деталь», реалізують відношення один-ко-многим (1: М) між двома таблицями. Зовнішній ключ (стовпець в посилається таблиці) завжди повинен мати відповідний йому первинний ключ (стовпець того ж типу і довжини даних в довідковій таблиці). Домен зовнішнього ключа не може виходити за межі домену відповідного йому первинного ключа. Ці домени повинні збігатися, в іншому випадку зовнішній ключ може мати невизначене значення.
Тригер являє собою особливий вид збережених процедур, який автоматично викликається при виконанні певної дії з таблицею, наприклад, вставки, видалення або оновлення рядка. Перед тим, як буде вироблено дію з рядком (вставка або видалення), код, вбудований в тригер, перевіряє заданий умова. Залежно від результатів перевірки виповнюється та чи інша частина коду тригера. Оскільки тригер є кодом, то в ньому можна ставити дуже складні алгоритми і правила перевірки. Наприклад, можна проводити перевірки посилальної цілісності в масштабах всієї бази даних і виконувати каскадне видалення всіх рядків з посилальної таблиці, пов'язаних з певною записом в посилається таблиці. Тригер спрацьовує тільки після того, як будуть виконані всі перевірки, що входять до ДСЦ. Хоча ДСЦ працює швидше, ніж тригер, але надаються при цьому можливості дещо менше. Використовувати і ДСЦ і тригери для перевірки одного і того ж умови недоцільно, так як ДСЦ виконується до початку запуску тригерів, і в разі, якщо перевірка умови ДСЦ дасть негативний результат, тригер так і не буде запущений. Лістинг 3 ілюструє використання тригерів для перевірки посилальної цілісності. Код проводить перевірку наявності відповідного рядка в довідковій таблиці при введенні нового рядка в посилається таблицю.
Цілісність домену гарантує, що всі значення деякого стовпця належать множині допустимих значень. Кожен стовпець має певне безліч значень, наприклад, для стовпця Pubs..zip таку силу-силенну складають все п'ятизначні числа, а для стовпця Pubs..au_name - символьні рядки, а для стовпця Sales..ord_date - все дати. Якщо ви задаєте обмеження на значення елементів деякого стовпчика, то тим самим ви забезпечуєте цілісність домену. Реалізація цілісності доменів може бути дуже простий - досить правильно вибрати для стовпця тип і довжину даних. У таблиці заголовків бази даних Pubs для стовпця Pubdate зазначений тип даних datetime і введена заборона на невизначені значення. Подібний вибір творця таблиці забезпечує наявність в цьому стовпці значень, які є правильними датами, наприклад, 11/22/99. Таким способом забезпечується цілісність домену.
У стандартах ANSI SQL-89 і SQL-92 введений оператор створення домену CREATE DOMAIN, який в Transact SQL (T-SQL) обробляється як задається користувачем тип даних (UDT) з перевірками і обмеженнями. Домен в ANSI SQL-89/92 виходить з існуючих базових типів даних, як в наступному прикладі псевдокоду:
CREATE DOMAIN wholesale_price AS DECIMAL (5,2) CONSTRAINT whsale_price_not_negative CHECK (value> = 0) NOT DEFERRABLE
В T-SQL можна створити елементарні домени, будуючи UDT на базі типів даних SQL Server. Крім того, можна додати в UDT опції невизначених значень, як це показано в прикладі з електронного посібника з T-SQL:
sp_addtype birthday, datetime, NULL
При використанні цього UDT в операторах CREATE TABLE або ALTER TABLE необхідно доповнити процес забезпечення цілісності доменів перевіркою обмежень. Виконувана під час створення таблиці перевірка обмежень забезпечує цілісність домену шляхом обмеження набору значень, які можуть бути поміщені в стовпець. У лістингу 4 наведено приклад подібного обмеження.
ДСЦ також є однією з форм цілісності домену. При реалізації відносини 1: М домен зовнішнього ключа і домен відповідного первинного ключа повинні збігатися. У прикладі лістингу 4 ніколи не вдасться ввести в стовпець pub_id значення, яке вже не міститься в таблиці Publishers. Таким чином, домен стовпчика title6.pub_id виявляється обмежений посиланням зовнішнього ключа.
За такою логікою, можна створювати таблиці, призначені спеціально для обмеження значень стовпця в іншій таблиці, тобто для забезпечення доменної цілісності. При цьому спеціальна таблиця називається довідкової або посилальної. Вона пов'язана з модифікується таблицею ставленням 1: М, яке завжди виконується. Наприклад, в лістингу 5 стовпець Pubs.type посилається на стовпець в таблиці TypeTable. Лістинг 5 містить опис структури довідкової таблиці TypeTable і приклади значень. Якщо ви спробуєте ввести рядок в таблицю Pubs.title7 і при цьому використовуєте значення, відсутнє в таблиці TypeTable, то така операція закінчиться невдачею. Правила ДСЦ, записані в Pubs.title7, що застосовуються спільно з переліком можливих значень в таблиці TypeTable забезпечують цілісність домену.
Бізнес-цілісність, звана також користувальницької цілісністю, гарантує, що при роботі з базою даних виконуються всі задані користувачем правила бізнесу, інструкції, директиви і процедури. Зазвичай бізнес-цілісність реалізується за допомогою збережених процедур і тригерів. Процедура є запит, який зберігається на сервері баз даних і використовується для обробки рядків і повернення результатів. Тригери підтримують цілісність даних «за сценою», оскільки вони спрацьовують так, що користувач навіть не усвідомлює, що вони були запущені. Лістинг 7 містить приклад коду тригера, що забезпечує бізнес-цілісність.
Цілісність даних життєво важлива для будь-якої бази. Якщо значення даних сумнівні, то яку видобувають із бази інформація буде або повністю марна, або значно знецінена. Розглянуті нами чотири види цілісності являють собою набір правил, які слід виконувати при роботі з базою даних. Належним чином певні і приємним, вони діють як єдина команда, що забезпечує точність і несуперечність даних у вашій базі.