ПЕРЕВІРКА ОБМЕЖЕНЬ

У даному розділі розглядаються дві теми Одна з них відноситься до реалізації, а інша – до моделі, і обидві ці теми стосуються питання про те, як фактично повинні перевірятися оголошені обмеження Спочатку розглянемо проблему реалізації Ще раз повернемося до прикладу 1, в якому, як відомо, фактично стверджується, що якщо деякий кортеж присутній у змінній відносини S, то цей кортеж повинен задовольняти певній умові (в даному випадку умові статус повинен знаходитися в межах від 1 до 100) Зокрема, слід зазначити, що в цьому обмеженні мова йде про кортежі у змінній відносини Тому очевидно, що при здійсненні спроби вставити новий кортеж з даними про постачальника зі статусом (скажімо) 200, повинна відбуватися описана нижче послідовність подій

1 Вставка нового кортежу

2 Перевірка обмеження

3 Скасування оновлення (оскільки перевірка закінчилася невдачею)

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

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

IF { S# s#, SNAME sn, STATUS st, CITY sc } €  S THEN ..

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

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

Тепер перейдемо до проблеми моделі (яка, безумовно, є більш фундаментальною) Знову розглянемо наведене вище золоте правило

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

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

Отже, читач міг уже виявити, що виражена тут позиція, згідно з якою всі перевірки повинні виконуватися негайно, є досить нетрадиційної в літературі (включаючи попередні видання цієї книги) найчастіше стверджується або просто передбачається, що одиницею контролю цілісності є транзакція і що, щонайменше, частина перевірок слід відкладати до кінця транзакції (тобто до часу виконання операції COMMIT) Але існують серйозні причини, за якими транзакції є непридатними в якості одиниці контролю цілісності, і такий одиницею замість них повинні служити оператори На жаль, ці причини неможливо дохідливо пояснити, не давши спочатку більш докладного опису всього, що взагалі повязане з поняттям транзакції Тому відкладемо докладне обговорення цієї теми до глави 16 до цієї глави ми просто припускаємо, що вимога негайної перевірки є логічно виправданим, не намагаючись додатково обгрунтувати нашу позицію (Але один важливий аргумент на користь позиції автора можна знайти в анотації до [916] в кінці цієї глави)

Джерело: Дейт К Дж, Введення в системи баз даних, 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>

*

*