Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

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

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

  • - Наявність "сміття" в таблицях, що виникає при некоректному або неповному видаленні записів таблиць;
  • - Невідповідність значень первинних і пов'язаних зовнішніх ключів;
  • - Створення фантомних записів, які не пов'язані з батьківськими відомостями, створюючи записи, доступ до яких обмежений або дозволений, але відомості містять некоректні дані або порожнечі;
  • - Неможливість видалення записів.

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

операції, які можуть бути виконані над даними при їх модифікації в режимі додавання, зміни або видалення.

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

Такими операціями, які виконуються при забезпеченні посилальної цілісності є:

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

Зазвичай дію "None" в базах даних представляється рідко,

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

У розглянутому прикладі предметної області електронного магазину досить багато зв'язків між таблицями бази даних і по ним необхідно визначити правила обмеження посилальної цілісності (табл. 5.4), що може бути оформлено у вигляді таблиці, де вказують пов'язані таблиці, розділяючи їх на батьківську і дочірню, операція , ініційовану обмеження посилальної цілісності, вбрання обмежувальне дію і його обгрунтування.

При взаємодії таблиць, асоційованих з сутностями "Замовлення" і "Клієнт", якщо додається нове замовлення, то умовами використання зовнішнього ключа, оскільки для нього встановлено властивість неможливості зберігання порожнього значення, передбачається його обов'язкове заповнення даними. До того ж умова наявності зовнішнього ключа в базах даних визначає автоматичну ненастраіваемую операцію контролю значень із забезпеченням однозначного відповідності значення зовнішнього ключа з існуючими значеннями первинного ключа батьківської таблиці. Ця особливість і відсутність необхідності виконання будь-яких операцій, крім контролю значення зовнішнього ключа, призводять до вирішення встановити варіант обмеження посилальної цілісності "None".

Таблиця 5.4

Обгрунтування правил посилальної цілісності

п / п

асоційована

таблиця

операція

ограни

чительное

дія

обгрунтування

роди

тельские

дочок

няя

1

замовлення

клієнт

додаванням

ня

None

Додавання нового замовлення дол ж I ю забезпе печі тися до 11 трол їм суп 1ест у ва 11 і я клієнта, враховуючи наявність зовнішнього ключа, що посилається на клієнта, що забезпечується стандартною операцією контролю зв'язків між таблицями

зраді

ня

No action

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

видалення

те ж

Дочірня сутність не є функціонально залежною від батьківської таблиці, що не вимагає визначення огран ІЧЕНЬ ссилоч Iюй цілісності

2

клієнт

замовлення

додаванням

ня

"•

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

зраді

ня

Cascade

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

видалення

Restrict

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



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

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

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

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

image355

Мал. 5.42. Алгоритм реалізації операцій посилальної цілісності


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

 
<<   ЗМІСТ   >>