Цілісність даних

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

Насамперед відзначимо, що, неформально висловлюючись, обмеження цілісності – Це логічний вираз, повязане з деякою базою даних, результатом обчислення якого завжди повинно бути значення TRUE Подібне обмеження може розглядатися як формальне вираження деякого бізнес-правила[915], хоча іноді самі бізнес-правила (які в даній главі розглядаються як представлені завжди на природній мові) іноді також називаютьобмеженнями цілісності Але так чи інакше, нижче наведено кілька прикладів бізнес-правил, які засновані на матеріалі бази даних постачальників і деталей

1 Значення статусу кожного постачальника повинно знаходитися в межах від 1 до 100

включно

2 Кожен постачальник з Лондона має статус 20

3 Якщо взагалі є які-небудь деталі, то щонайменше одна з них повинна мати синій колір

4 Різні постачальники не можуть мати однакові номери постачальників

5 Кожна поставка виконується існуючим постачальником

6 Жоден постачальник зі статусом менше 20 не постачає будь-які деталі в кількості стве більше 500

Дані приклади будуть широко використовуватися в цій главі

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

просто до використання відповідних засобів мови бази даних, а дотримання

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

CONSTRAINT SC1

IS_EMPTY ( S WHERE STATUS &lt 1 OR STATUS &gt 100 )

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

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

(Тобто записується в каталог системи) і починаючи з цього моменту дотримується До речі, слід зазначити, що в даному прикладі обмеження присвоєно імя – SCI (suppliers constraint one – обмеження для постачальників номер один) За умови, що це обмеження прийнято СУБД, воно буде зареєстровано в каталозі під цим імям, після чого вказане імя буде зявлятися в діагностичних повідомленнях, вироблюваних системою у відповідь на спроби порушити дане обмеження

Нижче показані ще дві можливі формулювання обмеження з прикладу 1, в яких тепер використовується версія мови Tutorial D на основі реляційного числення (тут SX – мінлива області значень, яка приймає свої значення серед номерів постачальників)

CONSTRAINT SC1

NOT EXISTS SX ( SXSTATUS &lt 1 OR SXSTATUS &gt 100 )

CONSTRAINT SC1

FORALL SX ( SXSTATUS &gt 1 AND SXSTATUS &lt 100 )

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

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

DROP CONSTRAINT &ltconstraint name&gt

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


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

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*