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

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

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

У реальному проектуванні структури бази даних застосовуються інший метод - так зване семантичне моделювання. Семантичне моделювання являє собою моделювання структури даних, що спирається на зміст цих даних. Як інструмент семантичного моделювання використовуються різні варіанти діаграм "сутність-зв'язок (ERD)" c побудовою концептуальної моделі бази даних.

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

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

Дотримання умов посилальної цілісності в реляційній базі даних.

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

Посилальна цілісність може порушитися в результаті операцій вставки (додавання), оновлення та видалення записів у таблицях. У визначенні посилальної цілісності беруть участь дві таблиці - батьківська і дочірня, для кожної з них можливі ці операції, тому існує шість різних варіантів, які можуть привести або не привести до порушення посилальної цілісності.

Для батьківської таблиці:

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

• Оновлення. Зміна значення первинного ключа в записі може призвести до порушення посилальної цілісності.

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

Для дочірньої таблиці:

• Вставка. Не можна вставити запис в дочірню таблицю, якщо для нового запису значення зовнішнього ключа некоректно. Операція може призвести до порушення посилальної цілісності.

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

• Видалення. При видаленні запису в дочірній таблиці посилальна цілісність не порушується.

Таким чином, посилальна цілісність в принципі може бути порушена при виконанні однієї з чотирьох операцій:

1. Оновлення записів у батьківській таблиці.

2. Видалення записів у батьківській таблиці.

3. Вставка записів у дочірній таблиці.

4. Оновлення записів у дочірній таблиці.

Основні стратегії підтримки посилальної цілісності

Існують дві основні стратегії підтримки посилальної цілісності.

RESTRICT (ОБМЕЖИТИ) - не дозволяти виконання операції, що призводить до порушення посилальної цілісності.

CASCADE (каскадні ЗМІНА) - дозволити виконання необхідної операції, але внести при цьому необхідні зміни в зв'язаних таблицях так, щоб не допустити порушення посилальної цілісності і зберегти всі наявні зв'язки. Зміна починається в батьківській таблиці і каскадно виконується в дочірніх таблицях. У реалізації цієї стратегії є одна тонкість, яка полягає в тому, що дочірні таблиці самі можуть бути батьківськими для деяких третіх таблиць. При цьому може додатково знадобитися виконання будь-якої стратегії і для цього зв'язку і т.д. Якщо при цьому яка-небудь з каскадних операцій (будь-якого рівня) не може бути виконана, то необхідно відмовитися від первинної операції і повернути базу даних в початковий стан. Це складна стратегія, але вона не порушує зв'язків між батьківськими і дочірніми таблицями.

Ці стратегії є стандартними і присутні у всіх СУБД, в яких є підтримка посилальної цілісності.

Додаткові стратегії підтримки посилальної цілісності

IGNORE (ІГНОРУВАТИ) - дозволити виконувати операцію без перевірки посилальної цілісності. У цьому випадку в дочірній таблиці можуть з'являтися некоректні значення зовнішніх ключів, вся відповідальність за цілісність бази даних лягає на програміста або користувача.

SET NULL (ПОСТАВИТИ ЗНАЧЕННЯ NULL) - дозволити виконання необхідної операції, але всі виникаючі некоректні значення зовнішніх ключів змінювати на null-значення. Ця стратегія має два недоліки. По-перше, для неї потрібен дозвіл на використання null-значень. По-друге, записи дочірньої таблиці втрачають зв'язок із записами батьківської таблиці. Встановити, з якою записом батьківської таблиці були пов'язані змінені записи дочірньої таблиці, після виконання операції вже не можна.

SET DEFAULT (ПОСТАВИТИ значення за замовчуванням) - дозволити виконання необхідної операції, але всі виникаючі некоректні значення зовнішніх ключів змінювати на деяке значення, прийняте за умовчанням. Гідність цієї стратегії в порівнянні з попередньої в тому, що вона дозволяє не користуватися null-значеннями. Встановити, з якими записами батьківської таблиці були пов'язані змінені записи дочірньої таблиці, після виконан­ня такої

операції теж не можна.