Транзакції і цілісність баз даних

Транзакції  і цілісність баз даних

Поняття транзакції має  безпосередній зв'язок з поняттям цілісності БД. Дуже часто БД може володіти такими обмеженнями цілісності, які  просто неможливо не порушити, виконуючи  лише один оператор зміни БД. Наприклад, в базі даних СПІВРОБІТНИКИ-ВІДДІЛИ природним обмеженням цілісності є збігу значення ознаки ОТД_РАЗМЕР в кортежі відносини ВІДДІЛИ, що описує даний відділ (наприклад, відділ 320), з числом кортежів відносини СПІВРОБІТНИКИ таких, що значення атрибута СОТР_ОТД_НОМЕР одно 320. Як у цьому випадку прийняти на роботу у відділ 320 нового співробітника? Незалежно від того, яка операція буде виконана перше, вставка нового кортежу у відношення СПІВРОБІТНИКИ або модифікація існуючого кортежу відносно ВІДДІЛИ, після виконання операції база даних виявиться в нецелостном стані.

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

Якщо бути трохи точнішим, розрізняються два види обмежень цілісності: негайно перевіряються й відкладаємо. До негайно перевіряється обмежень цілісності ставляться такі обмеження, перевірку яких безглуздо або навіть неможливо відкладати. Прикладом обмеження, перевірку якого відкладати безглуздо, є обмеження домену (вік співробітника не може перевищувати 150 років). Більш складним обмеженням, перевірку якого неможливо відкласти, є наступне: зарплата співробітника не може бути збільшена за одну операцію більш, ніж на 100,000 рублів. Негайно перевіряються обмеження цілісності відповідають рівню окремих операторів мовного рівня СУБД. При їх порушення не проводиться відкат транзакції, а лише відкидається відповідний оператор.

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

І ще одне зауваження. З точки зору зовнішнього подання в момент завершення транзакції перевіряються все відкладається обмеження цілісності, певні в цій базі даних. Однак при реалізації прагнуть при виконанні транзакції динамічно виділити ті обмеження цілісності, які дійсно могли б бути порушені. Наприклад, якщо під час виконання транзакції над базою даних СПІВРОБІТНИКИ-ВІДДІЛИ в ній не виконувалися оператори вставки або видалення кортежів з відношення СПІВРОБІТНИКИ, то перевіряти згадуване вище обмеження цілісності не потрібно (а перевірка подібних обмежень викликає досить жваву роботу).