Корпоративні обмеження цілісності
Обмеження для доменів полів
Деякі поля завжди повинні містити одне з допустимих значень, іншими словами, ці поля не можуть мати порожнього значення.
Кожне поле має свій домен, який представляє собою набір його допустимих значень.
Існує поняття "корпоративні обмеження цілісності" як додаткові правила підтримки цілісності даних. визначаються користувачами, прийняті на підприємстві або адміністраторами баз даних. Обмеження підприємства називаються бізнес-правилами.
Це обмеження цілісності стосується первинних ключів базових таблиць. За визначенням, первинний ключ - мінімальний ідентифікатор (одне або кілька полів), який використовується для унікальної ідентифікації записів в таблиці. Таким чином, ніяке підмножина первинного ключа не може бути достатнім для унікальної ідентифікації записів.
Цілісність сутностей визначає, що в базовій таблиці жодне поле первинного ключа не може містити відсутніх значень, позначених NULL.
Якщо допустити присутність визначника NULL в будь-якій частині первинного ключа. це рівносильно твердженням, що не всі його поля необхідні для унікальної ідентифікації записів, і суперечить визначенню первинного ключа.
Зазначене обмеження цілісності стосується зовнішніх ключів. Зовнішній ключ - це поле (або безліч полів) однієї таблиці, що є ключем іншої (або тієї ж самої) таблиці. Зовнішні ключі використовуються для встановлення логічних зв'язків між таблицями. Зв'язок встановлюється шляхом присвоєння значень зовнішнього ключа однієї таблиці значень ключа інший.
Між двома або більше таблицями бази даних можуть існувати відносини підлеглості, які визначають, що для кожного запису головної таблиці (її називають іще батьківської) може існувати одна або кілька записів у підпорядкованій таблиці (званої також дочірньої).
Існує три різновиди зв'язку між таблицями бази даних:
- "Один-ко-многим";
- "один до одного";
- "Багато-до-багатьох".
Ставлення "один-ко-многим" має місце, коли одному запису батьківської таблиці може відповідати кілька записів дочірньої. Зв'язок "один-ко-многим" іноді називають зв'язком "багато-до-одного". І в тому, і в іншому випадку сутність зв'язку між таблицями залишається незмінною.
Зв'язок "один-ко-многим" найбільш поширена для реляційних баз даних. Вона дозволяє моделювати також ієрархічні структури даних.
Ставлення "один-до-одного" має місце, коли одному запису в батьківській таблиці відповідає один запис у дочірньої. Це ставлення зустрічається набагато рідше, ніж ставлення "один-ко-многим". Його використовують, якщо не хочуть, щоб таблиця БД "розпухала" від другорядної інформації. Використання зв'язку "один-до-одного" призводить до того, що для читання пов'язаної інформації в декількох таблицях доводиться робити кілька операцій читання замість однієї, коли дані зберігаються в одній таблиці.
Ставлення "багато-до-багатьох" має місце в наступних випадках:
- запису в батьківській таблиці відповідає більше одного запису в дочірній таблиці;
- запису в дочірній таблиці відповідає більше одного запису в батьківській таблиці.
Вважається, що будь-який зв'язок "багато-до-багатьох" може бути замінена на зв'язок "один-ко-многим" (одну або кілька).
Часто зв'язок між таблицями встановлюється по первинному ключу. тобто значенням зовнішнього ключа однієї таблиці присвоюються значення первинного ключа іншої. Однак це не є обов'язковим - в загальному випадку зв'язок може встановлюватися і за допомогою вторинних ключів. Крім того, при встановленні зв'язків між таблицями не потрібно неодмінна унікальність ключа, що забезпечує встановлення зв'язку. Поля зовнішнього ключа не зобов'язані мати ті ж імена, що й імена ключів, яким вони відповідають. Зовнішній ключ може посилатися на свою власну таблицю - в такому випадку зовнішній ключ називається рекурсивним.
Посилальна цілісність визначає: якщо в таблиці існує зовнішній ключ. то його значення має або відповідати значенням первинного ключа деякої записи в базовій таблиці, або задаватися визначником NULL.
Існує кілька важливих моментів, пов'язаних із зовнішніми ключами. По-перше, слід проаналізувати, чи припустимо використання в зовнішніх ключах порожніх значень. У загальному випадку, якщо участь дочірньої таблиці в зв'язку є обов'язковим, то рекомендується забороняти застосування порожніх значень в соответствующемвнешнем ключі. У той же час, якщо має місце часткова участь дочірньої таблиці в зв'язку, то приміщення порожніх значень в поле зовнішнього ключа повинно бути дозволено. Наприклад, якщо в операції фіксації угод деякої торгової фірми необхідно вказати покупця, то поле КодКліента повинно мати атрибут NOT NULL. Якщо допускається продаж або купівля товару без вказівки клієнта, то для поля КодКліента можна вказати атрибут NULL.
Наступна проблема пов'язана з організацією підтримки посилальної цілісності при виконанні операцій модифікації даних в базі. Тут можливі наступні ситуації:
Існує й інший вид цілісності - смислова (семантична) цілісність бази даних. Вимога смислової цілісності визначає, що дані в базі даних повинні змінюватися таким чином, щоб не порушувалася склалася між ними смислова зв'язок.
Рівень підтримки цілісності даних в різних системах істотно варіюється.
Ідеологія архітектури клієнт-сервер вимагає перенесення максимально можливого числа правил цілісності даних на сервер. До переваг такого підходу відносяться:
- гарантія цілісності бази даних, оскільки всі правила зосереджені в одному місці (в базі даних);
- автоматичне застосування певних на сервері обмежень цілісності для будь-яких додатків;
- відсутність різних реалізацій обмежень в різних клієнтських додатках, що працюють з базою даних;
- швидке спрацьовування обмежень, оскільки вони реалізовані на сервері і, отже, немає необхідності надсилати дані клієнта, збільшуючи при цьому мережевий трафік;
- доступність внесених в обмеження на сервері змін для всіх клієнтських додатків, що працюють з базою даних, і відсутність необхідності повторного поширення змінених додатків клієнтів серед користувачів.
До недоліків зберігання обмежень цілісності на сервері можна віднести:
- відсутність у клієнтського додатка можливості реагувати на деякі помилкові ситуації, що виникають на сервері при реалізації тих чи інших правил (наприклад, помилок при виконанні процедур на сервері);
- обмеженість можливостей мови SQL і мови збережених процедур і тригерів для реалізації всіх виникаючих потреб визначення цілісності даних.
На практиці в клієнтських додатках реалізують лише такі правила, які важко або неможливо реалізувати із застосуванням засобів сервера. Все остальниеограніченія цілісності даних переносяться на сервер.
Лекція 9: Визначення обмежень цілісності
Дається визначення понять цілісності даних в стандарті мови SQL. Розглядаються питання визначення декларативною і каскадної посилальної цілісності. Наводяться приклади створення обмежень первинного та зовнішнього ключа, обмежень на значення і за замовчуванням, а також приклади створення і використання правил і замовчувань.