Правила збереження цілісності посилань та їх використання

Транзакції – зміни в базі даних (редагування даних, доповнення новими записами, вилучення записів) повинні переводити базу даних з одного цілісного стану до іншого, тобто не рушити логічні зв'язки між даними, не приводити до втрат даних. Для забезпечення цілісності посилань в ERwin передбачені спеціальні процедури, які генеруються автоматично при встановлені, так званих, RI-тригерів.

RI-тригери – логічні конструкції, що відображують бізнес правила використання даних і являють собою правила доповнення, оновлення та вилучення (команди INSERT, UPDATE, DELETE мови запитів SQL).

При наявності ідентифікованого зв’язку існують випадки, коли доцільно заборонити вилучення екземпляра батьківської сутності, якщо є хоча б один екземпляр, пов‘язаний з ним, в дочірній сутності. В цьому випадку слід вилучити всі відповідні екземпляри з дочірньої сутності, а тільки потім з батьківської. Таке правило називається "обмеженням" (Parent Delete RESTRICT). Обмеження з боку дочірньої сутності встановлюється правилом Child Delete RESTRICT.

Наприклад, існує батьківська сутність Замовник та дочірня сутність Замовлення, до якої заносяться всі виконані замовлення. При припиненні відносин між Замовником та Підприємством природно виникає необхідність у вилученні даних про замовника з бази. Але не можна знищувати дані про замовника, коли існують дані відносно виконаних замовлень. У цьому випадку з боку батьківської сутності слід встановити правило Parent Delete RESTRICT.

Правило, коли при вилученні екземпляру батьківської сутності вилучаються всі, пов’язані з ним, екземпляри дочірньої сутності – називається "каскад" (Parent Delete CASCADE). Якщо екземпляри дочірньої сутності за ім’ям ролі пов’язані з підлеглими екземплярами нижчого рівня, то вилучаються і вони. У нашому прикладі про Замовника та Замовлення, якщо це продиктовано бізнес правилами, доцільно використати правило Parent Delete CASCADE. Тоді при вилученні Замовник а вилучаються всі пов’язані з ним Замовлення.

За наявності неідентифікованого зв’язку, коли жодного екземпляра у дочірньої сутності з відповідним ключем не знайдено, можна використати правило SET NULL. Інший випадок, коли атрибуту зовнішнього ключа встановлюєть значення за замовчуванням - SET DEFAULT.

Існує вид неідентифікованого зв‘язку, який не дозволяє встановлення значення NULL, тоді правило SET NULL не використовують.

Для обох випадків ідентифікованого і неідентифікованого зв’язку можна задати правило, коли зміни в кожній сутності відбуваються незалежно від інших – NONE.

Аналогічно правилам вилучення запису встановлюються правила доповнення або редагування запису.