
- •1. Классификация бд по доступу к данным
- •2. Особенности рбд
- •3. Преимущества и недостатки рбд
- •4. Сравнение рбд с бд централизованного хранения
- •5. Архитектура рбд с глобальной схемой хранения
- •6. Мультибазовые рбд
- •7. Компонентная архтектура рбд
- •8. Исходная информация для проектирования бд
- •9. Сравнение различных стратегий распределения данных
- •10. Фрагментация и репликация: понятия
- •11. Корректность фрагментации
- •12. Типы фрагментаций
- •13. Прозрачность размещения данных. Виды прозрачности
- •14. Прозрачность фрагментации
- •15. Прозрачность расположения
- •16. Прозрачность локального отображения
- •17. Прозрачность именования
- •18. Прозрачность параллельности и отказов
- •19. Прозрачность выполнения
- •20. Правила Дейта
- •21. Понятие транзакции, проблемы, возникающие при транзакции, свойства транзакции
- •22. Управление параллельностью, проблемы параллельности
- •23. Проблема несогласованной обработки
- •24. Проблема потерянного обновления
- •25. Проблема зависимости от нефиксированных результатов
- •26. Упорядочиваемость и восстанавливаемость
- •Восстанавливаемость
- •27. Упорядочивание по просмотру
- •28. Двухфазная блокировка
- •30. Взаимная блокировка - это
- •31.(????) Управление блокировками
- •32. Уровни детализации блокируемых элементов
- •33. Структура и назначение языка xml
- •34. Узлы, атрибуты и элементы на xml
- •35. Просмотр и обновление базы данных средствами xml
- •36. Обработка представленных на xml данных циклами
- •37. Навигация в данных средствами xml
- •38. Обработка представленных на xml данных операторами языка linq
- •39. Особенности создания интерфейсов на wpf
21. Понятие транзакции, проблемы, возникающие при транзакции, свойства транзакции
Транзакции
Транзакция: Действие или серия действий, выполняемых одним пользователем или прикладной программой, которые осуществляют доступ или изменение содержимого базы данных.
Транзакция является логической единицей работы, выполняемой в базе данных. Она может быть представлена отдельной программой, являться частью алгоритма программы или даже отдельной командой (например, командой INSERT или UPDATE языка SQL) и включать произвольное количество операций, выполняемых в базе данных. С точки зрения базы данных, выполнение программы некоторого приложения может расцениваться как серия транзакций, в промежутках между которыми
выполняется некоторая обработка данных, осуществляемая вне среды базы данных.
Для иллюстрации концепции транзакции рассмотрим два отношения из учебного примера DreamHome:
Staff (Sno, FName, LName, Address, Tel_No, Position, Sex, Salary) Sex, ООВ, Salary, NIN, Впо) -
Property_for_Rent (Рnо, Street, Area, City, Туре, Rooms, Rent,Sno)
Простейшей транзакцией, выполняемой в подобной базе данных, может быть модификация зарплаты определенного работника, указанного его личным номером х. На высшем уровне подобная транзакция может быть записана так, как показано в табл. 1 (вариант А). Будем обозначать операции чтения или записи элемента данных х с помощью выражений read(x) и write(x) соответственно. При необходимости к имени элемента данных могут добавляться дополнительные квалификаторы.
Например, в Вариант А (табл. 1) используется нотация
read(Sno = х, salary), указывающая, что требуется считать элемент данных salary для записи, в которой ключевое значение равно х. В данном примере транзакция состоит из двух операций, выполняемых в базе данных (read и write), и одной операции, выполняемой вне базы данных (salary = salary*l.l).
Таблица 1. Пример выполнения транзакции
Вариант А
read(Sno =х, salary)
salary = salary * 1.1
write(Sno =х, new_salary)
Вариант В
delete(Sno = х)
for all Property_for_Rent records, рnо
begin
read(Pno = рnо, sno)
if (sno = х) then
begin
write(Pno = рnо, вnо)
end
end
Более сложная транзакция (вариант В) предназначена для удаления сведений о работнике, заданном его учетным номером х. В этом случае, помимо удаления соответствующего кортежа из отношения Staff, потребуется найти все кортежи отношения Property_for_Rent, описывающие объекты недвижимости, за которые отвечал данный работник, после чего назначить их некоторому другому работнику, личный номер которого будет иметь значение new_sno.
Если все указанные изменения не будут внесены до конца, база данных окажется в несогласованном состоянии - за объект недвижимости будет отвечать несуществующий работник компании.
Любая транзакция всегда должна переводить базу данных из одного согласованного состояния в другое, хотя допускается, что согласованность состояния базы будет нарушаться в ходе выполнения транзакции. Например, в процессе выполнения транзакции (Вариант В), имеет место ситуация, когда один из кортежей отношения Property_for_Rent содержит новое значение атрибута Sno - nеw_snо, тогда как остальные кортежи все еще содержат прежнее значение х. Однако после завершения выполнения транзакции, во все требуемые кортежи будет помещено новое значение
- new_sno.
Любая транзакция завершается одним из двух возможных способов. В случае успешного завершения результаты транзакции фиксируются (commit) в базе данных, и последняя переходит в новое согласованное состояние. Если выполнение транзакции не увенчалось успехом, она отменяется. В этом случае в базе данных должно быть восстановлено то согласованное состояние, в котором она находилась до начала данной транзакции. Этот процесс называется откатом (гоllback) транзакции. Зафиксированная транзакция не может быть отменена. Если оказывается, что зафиксированная транзакция была ошибочной, потребуется выполнить другую транзакцию, отменяющую действия, выполненные первой транзакцией. В некоторых случаях эту транзакцию называют компенсирующей. Следует отметить, что отмененная транзакция может быть еще раз запущена позже и, в зависимости от причин предыдущего отказа, вполне успешно завершена и зафиксирована в базе данных.
Никакая СУБД не обладает внутренней возможностью установить, какие именно изменения должны быть восприняты как единое целое, образующее одну логическую транзакцию. Следовательно, должен существовать метод, позволяющий указывать границы каждой из транзакций извне, со стороны пользователя. В большинстве языков манипулирования данными для указания границ отдельных транзакций используются операторы BEGIN TRANSACTION, COMMIT и ROLLBACK (или их эквиваленты).
Если эти ограничители не были использованы, вся выполняемая программа расценивается как единая транзакция. СУБД автоматически выполнит команду СОММIТ при нормальном завершении этой программы. Аналогично, в случае ее аварийного завершения в базе данных автоматически будет выполнена команда ROLLBACK.
Свойства транзакций
Существуют некоторые свойства, которыми должна обладать любая из транзакций. Ниже представлены четыре основных свойства (ACID - аббревиатура, составленная из первых букв их английских названий).
• Атомарность. Это свойство типа "все или ничего". Любая транзакция
представляет собой неделимую единицу работы, которая может быть либо
выполнена вся целиком, либо не выполнена вовсе.
• Согласованность. Каждая транзакция должна переводить базу данных из
одного согласованного состояния в другое согласованное состояние.
• Изолированность. Все транзакции выполняются независимо одна от другой. Другими словами, промежуточные результаты незавершенной транзакции не должны быть доступны другим транзакциям.
• Продолжительность. Результаты успешно завершенной (зафиксированной) транзакции должны сохраняться в базе данных постоянно и не должны
быть утеряны в результате последующих сбоев.
На рисунке представлен схема системы управления базой данных, включающий четыре высокоуровневых модуля, отвечающих за обработку транзакций, управление параллельностью и выполнение восстановления
системы. Менеджер транзакций осуществляет координацию работы транзакций, выполняемых прикладными программами. Он взаимодействует с планировщиком, отвечающим за реализацию выбранной стратегии управления параллельностью. В некоторых случаях планировщик называют менеджером блокировки, если используемый протокол управления параллельностью строится на основе системы блокировок. Цель работы планировщика
состоит в достижении максимально возможного уровня параллельности, при условии исключения влияния параллельно выполняющихся транзакций друг на друга, поскольку это может послужить источником нарушения согласованности базы данных.
Если в процессе выполнения транзакции происходит отказ, то база данных может оказаться в несогласованном состоянии. Задачей менеджера восстановления является предоставление гарантий того, что в подобном случае база данных будет автоматически возвращена в то состояние, в котором она находилась до начала данной транзакции, и, следовательно, останется согласованной. Наконец, менеджер буферов отвечает за передачу данных между основной памятью компьютера и вторичной дисковой памятью.