Обмеження посилальної цілісності в батьківській таблиці

Припустимо, що але таблицями, асоційованим з сутностями "Замовлення" і "Товари замовлення", є деякі раніше сформовані відомості, які дозволяють побачити можливі дії і можливі проблеми, що виникають при додаванні, видаленні і змінюються дані в батьківській таблиці "Замовлення" (рис. 5.43).

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

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

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

Припустимо, що змінили значення первинного ключа замовлення з "2" на "4". З огляду на, що в дочірній таблиці на замовлення зі значенням ключа "2" є позиція товару, то безконтрольне зміна призведе до втрати цієї позиції товару в замовлення, що неприпустимо.

Мал. 5.44. Зміна значення первинного ключа
батьківської таблиці

Вирішення цієї ситуації може виконуватися різними варіантами:

першим, найбільш коректним, є вказівка ​​дії "Cascade", оскільки тоді значення зовнішнього ключа в дочірній таблиці по зв'язаних записів автоматично буде змінено на правильне значення і порушення цілісності не буде,

• - Другим варіантом є присвоєння порожнього значення "NULL" через операцію "Set NULL", якщо така допустима в СУБД, що, звичайно, призведе до втрати позиції товару в замовленні, але обробка позицій товарів замовлень з порожнім значенням в зовнішньому ключі дозволить отримати до них доступ і вирішити виниклі порушення цілісності в ручному режимі самим користувачем;
• - Третім варіантом може бути використання дії "Set default", який встановлює в зовнішній ключ значення за замовчуванням, що для даного прикладу неприйнятно, але при зв'язках між іншими таблицями цілком можливо.

Таким чином, для розглянутого прикладу можливі два прийнятні варіанти обмеження посилальної цілісності: заборонити зміну значень первинного ключа дією "Restrict" або дозволити зміну з подальшим автоматичним зміною значення в зовнішньому ключі дочірньої таблиці через дію "Cascade".

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

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

• • Restrict - заборонити видалення запису батьківської таблиці, якщо в дочірній таблиці є пов'язані записи, що для прикладі припустимо, але нелогічно, припускаючи, що видалення замовлення обумовлено необхідністю виключити його в подальшій обробці, але за умови збереження всіх замовлень, які роблять клієнти, таке дію буде цілком обгрунтованим;
• • Cascade - найбільш часто застосовується дія, яка передбачає послідовне видалення пов'язаних записів в дочірній таблиці, очищаючи, таким чином, для розглянутого прикладу всі товари, які були закріплені за зазначеним замовленням;
• • Set NULL - дія, яка може дозволити зберегти позиції в дочірній таблиці для подальшої обробки при використанні процедур обробки порожніх значень, без втрати цілісності даних, але для даного прикладу неприйнятне, оскільки не має сенсу зберігати замовлені товари, якщо вони не закріплені за певним замовленням ;
• • Set default - також допустимий дію, аналогічне попередньому, але встановлює значення за замовчуванням в полі зовнішнього ключа по записах дочірньої таблиці, пов'язаним з видаляється записом батьківської таблиці, що також неприйнятно для розглянутого прикладу.

Таким чином, з огляду на, що товари не можуть зберігатися в таблиці бази даних "Товари замовлення" без вказівки замовлення, за яким вони закріплені, допустимими варіантами можуть бути "Restrict" і "Cascade". При розгляді можливості видалення замовлення разом із замовленням, що але предметної області допустимо, варіант дії "Cascade" є найбільш коректним і правильним.