АГЕНСТВО ДО ОСВІТИ
Федеральне державне освітня установа вищої професійної освіти
В«Чуваська державний університет імені І.Н.Ульянова В»
Алатирський філія
Кафедра Вищої математики та інформаційних технологій
Курсова робота
з дисципліни В«Бази даних та СУБДВ»
на тему: В«Моделі транзакційВ»
Виконав: студент
групи АФТ 61-05
Краснов Д.П.
Керівник:
ст. преп. Алякіна Л.А.
2010
ЗМІСТ
Введення
ГЛАВА 1. Загальні відомості про транзакції
1.1 Підтримка транзакцій
1.2 Властивості транзакцій
ГЛАВА 2.Модель транзакцій
2.1 Плоскі транзакції
2.2 Модель вкладених транзакцій
2.3 Хроніки
2.4 Модель багаторівневих транзакцій
2.5 Модель робочих потоків
2.6 Класифікація систем обробки транзакцій
Висновок
Література
ВСТУП
У цій курсовій роботі обговорюються тенденції та перспективи обробки транзакцій в застосуванні до систем інформаційного управління в цілому. Розглядаються, зокрема, такі питання:
. підтримка транзакцій;
. властивості транзакцій;
. моделі транзакцій;
. риси систем обробки транзакцій наступного покоління.
РОЗДІЛ 1 Загальні відомості про транзакції
1.1 Підтримка транзакцій
Транзакція - дія або ряд дій, виконуваних одним користувачем або прикладною програмою, які здійснюють читання або зміна вмісту бази даних.
Транзакція є логічною одиницею роботи, виконуваної в базі даних. Вона може бути представлена ​​окремою програмою, частиною програми або навіть окремою командою (наприклад, командою INSERT або UPDATE мови SQL) і включати довільну кількість операцій, які виконуються в базі даних. З точки зору адміністратора бази даних експлуатація будь-якого додатку може розцінюватися як ряд транзакцій, в проміжках між якими виконується обробка даних, здійснювана поза середовища бази даних.
Найпростішою транзакцією, виконуваної в подібній базі даних, може бути коригування зарплати певного працівника, зазначеного його табельною номером х. Узагальнено подібна транзакція може бути записана, як показано на (Рис. 1).
(рис. 1)
модель транзакція хроніка
На (рис. 1) використовується позначення read (staffNo = x, salary), вказує, що потрібно вважати елемент даних salary для запису, в якій ключове значення дорівнює х. У даному прикладі транзакція складається з двох операцій, які виконуються в базі даних (read і write), і однієї операції, виконуваної поза базою даних (salary = salary * 1.1).
Будь транзакція завершується одним з двох можливих способів. В разі успішного завершення результати транзакції фіксуються (commit) в базі даних, і остання переходить у новий узгоджений стан. Якщо виконання транзакції не увінчалося успіхом, вона відміняється. У цьому випадку в базі даних має бути відновлено то узгоджений стан, в якому вона перебувала до початку даної транзакції. Цей процес називається відкатом (roll back), або скасуванням транзакції. Зафіксована транзакція не може бути відмінена. Якщо виявиться, що зафіксована транзакція була помилковою, буде потрібно виконати іншу транзакцію, що скасовує дії, виконані перші транзакції
Така транзакція називається компенсує. Але аварійно завершилася транзакція, для якої виконаний відкіт, може бути викликана на виконання пізніше і, в залежності від причин попередньої відмови, цілком успішно завершена і зафіксована в базі даних. Ні в одній СУБД не може бути передбачений апріорний спосіб визначення того, які саме операції поновлення можуть бути згруповані для формування єдиної логічної транзакції. Тому повинен застосовуватися метод, що дозволяє вказувати кордону кожної з транзакцій ззовні, з боку користувача. У більшості мов маніпулювання даними для вказівки кордонів окремих транзакцій використовуються оператори BEGIN TRANSACTION, COMMIT і ROLLBACK (або їх еквіваленти). Якщо ці обмежувачі не були використані, як єдина транзакція зазвичай розглядається вся виконувана програма. СУБД автоматично виконає команду COMMIT при нормальному завершенні цієї програми. Аналогічно, у разі аварійного завершення програми в базі даних автоматично буде виконана команда ROLLBACK.
Порядок виконання операцій транзакції прийнято позначати з допомогою діаграми переходів. Приклад такої діаграми наведено на (рис. 2). Слід зазначити, що на цій діаграмі, крім очевидних станів ACTIVE, COMMITTED і ABORTED маються ще два стани, описані нижче.
(рис. 2.)
PARTIALLY COMMITTED. Цей стан виникає після виконання останнього оператора. У цей момент може бути виявлено, що в результаті виконання транзакції порушені правила впорядкування або обмеження цілісності, тому транзакцію необхідно завершити аварійно. Ще один варіант розвитку подій полягає в тому, що в системі відбувається відмова і всі дані, оновлені в транзакції, неможливо успішно записати у зовнішню пам'ять. В подібних випадках транзакція повинна перейти в стан FAILED і завершитися аварійно. А якщо транзакція виконана успішно, то всі результати поновлення можуть бути надійно записані у зовнішній пам'яті і транзакція може перейти в стан COMMITTED.
FAILED. Такий стан виникає, якщо транзакція не може бути зафіксована чи відбулося її аварійне завершення, коли вона перебувала в стані ACTIVE, Це аварійне завершення могло виникнути через скасування транзакції користувачем або в результаті дії протоколу керування паралельним доступом викликав аварійне завершення транзакції для забезпечення упорядочіваемості операцій бази даних.
1.2 Властивості транзакцій
Існують певні властивості, якими має володіти будь-яка з транзакцій. Нижче представлені чотири основні властивості транзакцій, які прийнято позначати абревіатурою ACID (Atomicity, Consistency, Isolation, Durability - нерозривність, узгодженість, ізольованість, стійкість), складається з перших літер назв цих властивостей.
Нерозривність. Це властивість, для опису якого застосовне вираз "все або нічого". Будь-яка транзакція являє собою неподільну одиницю роботи, яка може бути або виконана вся цілком, або не виконана взагалі. За забезпечення нерозривності відповідає підсистема відновлення СУБД.
Узгодженість. Кожна транзакція повинна перекладати базу даних з одного узгодженого стану в інший. Відповідальність за забезпечення узгодженості покладається і на СУБД, і на розробників додатків. В СУБД узгодженість може забезпечуватися шляхом виконання всіх обмежень, заданих в схемі бази даних, таких як обмеження цілісності та обмеження предметної області. Але подібне умова є недостатнім для забезпечення узгодженості. Наприклад, припустимо, що деяка транзакція призначена для переказу коштів з одного банківського рахунку на інший, але програміст допустив помилку в логіці транзакції і передбачив зняття грошей з правильного рахунку, а зарахування - на неправильний рахунок. У цьому випадку база даних переходить в неузгоджене стан, незважаючи на наявність правильно заданих обмежень. Тим не менш відповідальність за усунення такої неузгодженості не може бути покладено на СУБД, оскільки в ній відсутні будь засоби виявлення подібних логічних помилок.
Ізольованість. Всі транзакції виконуються незалежно один від одного. Іншими словами, проміжні результати незавершеної транзакції не повинні бути доступні для інших транзакцій. За забезпечення ізольованості відповідає підсистема управління паралельним виконанням.
Стійкість. Результати успішно завершеної (зафіксованої) транзакції повинні зберігатися в базі ...
