Освітній веб-сайт, лекції з різних

Під цілісністю бази даних розуміється узгодженість (несуперечність) даних. Звичайно, СУБД не може контролювати правильність кожного окремого значення, що вводиться в базу даних. Наприклад, не можна виявити, що вводиться значення 33, що представляє число відпрацьованих годин на тиждень, в дійсності має дорівнювати 35. Але значення, більше ніж 168 = 7 · 24, явно буде помилковим і система повинна його відкинути.

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

Цілісність забезпечується шляхом завдання обмежень. Залежно від джерела можна виділити інструментальні обмеження, структурні обмеження і бізнес-правила.

До інструментальних обмежень відносять перевірку правильності даних при введенні. Наприклад, поле числа не може містити текстові символи, а поле дати повинно містити допустиме значення дати. Засоби реалізації інструментальних обмежень вбудовані в СУБД.

Структурні обмеження базуються на смислових залежностях між атрибутами відносин. Часто в одному відношенні використовується атрибут, за своєю суттю збігається з атрибутом іншого ставлення, хоча за назвою він може і відрізнятися. Наприклад, у відносинах МАГАЗИН і КУПІВЛІ може використовуватися один і той же атрибут ФІРМА.

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

У термінах таблиць мова йде про те, що всі значення з одного стовпчика таблиці зустрічаються в стовпці іншої таблиці; кажуть, що перший стовпець посилається на другий. Той стовпець в таблиці, який посилається на інший, називається зовнішнім ключем (foreign key). а стовпець, на який він посилається, називається батьківським ключем (parent key).

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

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

Блокування введення планується за допомогою зовнішнього ключа (foreign key). Атрибут відносини позначається як зовнішній ключ (foreign key) із зазначенням батьківського відносини. А так як зовнішній ключ (foreign key) - це атрибут, значення якого можуть бути тільки з значень атрибута батьківського відносини, то при введенні даних слід спочатку ввести значення в батьківську таблицю і тільки потім в стовпець, позначений як зовнішній ключ.

До структурних обмежень відносять також унікальність первинного ключа і унікальність можливих ключів. Відносно будь-які два кортежу не можуть мати одне і те ж значення атрибута (або агрегату атрибутів), оголошеного в якості первинного або можливого ключа. Крім того в первинному або в можливому ключі не може бути компонентів з нульовим значенням. Система управління повинна відхилити будь-яку спробу (при введенні або оновленні) помістити в базу даних кортеж, ключ якого або порожній (нуль), або має значення, вже введене в базу даних.

Бізнес-правила є умови того, що дані відповідають предметної області. Бізнес-правила можна розділити на елементарні і розширені. Елементарні правила обмежують значення конкретного атрибута або агрегату атрибутів через обмеження домену. Розширені правила виражаються у вигляді деякої залежності між атрибутами.

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

Обмеження можуть знайти своє вираження:

- при описі атрибутів відносин в концептуальній схемі;

- в запиті до бази даних;

- в процедурі бази даних;

- в правилі (в тригері).

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

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

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

Приклад. Нехай в базі даних СКЛАД міститься таблиця ДЕТАЛЬ, що зберігає відомості про наявність деталей на складі заводу. Одне з правил діяльності заводу полягає в тому, що неприпустимою є ситуація, коли на складі кількість деталей будь-якого типу стає менше, припустимо, 100. Це вимога описується правилом «Проверіть_деталь». Воно застосовується в разі поновлення стовпця КІЛЬКІСТЬ таблиці ДЕТАЛЬ: якщо нове значення в стовпці менше 100, то виконується процедура «Заказать_деталь». Як параметри їй передаються номер деталі і кількість деталей на складі.

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