Неявные и явные транзакции. Кафедра информационных систем

• Название: Кафедра информационных систем
• Анкор: Неявные и явные транзакции
• Дата: 24.09.2022
• Размер: 136.2 Kb.
• Имя файла: Неявные и явные транзакции .docx
• Тип: Документы; #693849

Титульный лист рейтинговой работы



Кафедра информационных систем

Рейтинговая работа
по дисциплине	Реплицированные распределенные базы данных
Вариант № 12____
Тема	Неявные и явные транзакции
Выполнена обучающимся группы	л.УЗДтс 23.1/Б1-20
ФИО обучающегося	Никифоров Виктор Владимирович
Преподаватель

Москва – 2022 г.

Оглавление

Введение. 3

1 . База данных и ее составные части 4

1.1Структурная часть реляционной базы данных 5

2. Основные принципы разработки базы данных 8

3.Что такое Транзакция 8

4.Явные транзакции 11

4.1Определение начала транзакции 11

4.2Сохранение состояния транзакции 12

4.3Откат явных транзакций 13

4.4Фиксация явных транзакций 13

5.Неявные транзакции 14

5.1Автоматически фиксируемые транзакции 15

Вывод 16

Список литературы 18

Введение.

Основные идеи современной информационной технологии базируются на концепции баз данных. Согласно этой концепции, основой информационной технологии являются данные, которые должны быть организованы в базах данных с целью адекватного отображения изменяющегося реального мира и удовлетворения информационных потребностей пользователей.

Разработка баз данных и создание программ, использующих базы данных, включает проектирование баз данных, создание самой базы данных и всех необходимых для ее эффективного использования объектов (таблицы, индексы, хранимые процедуры, триггеры, функции), поддержание базы данных в работоспособном состоянии и, в конце концов, создание программ для так называемого "конечного пользователя" (end user), которому было бы комфортно работать с созданными вами базами данных. Специалистов, обслуживающих программные системы (системных администраторов или в более узком смысле администраторов баз данных, АБД).

С проблемой производительности так или иначе сталкиваются все разработчики программного обеспечения. Конечно, хорошо, если выбранная целевая система управления базами данных (СУБД) вместе с аппаратными средствами ее реализации предоставляет существенный запас по критерию производительности для конкретной прикладной задачи, так что над этими вопросами можно особенно не задумываться. Однако очевидным правилом является следующее: чем выше этот запас, тем сама СУБД вместе с ее аппаратной конфигурацией становится все более дорогостоящей. Поэтому работа на предельных нагрузках по различным параметрам производительности вполне возможна, и этими вопросами с неизбежностью приходится заниматься.

1 . База данных и ее составные части

База данных в самом общем смысле — это унифицированная совокупность данных, совместно используемых широким кругом пользователей, динамически изменяющаяся в процессе своего функционирования. Если унифицированным форматом представления данных являются таблицы, то речь идет о реляционной базе данных.

Базы данных используются в тех случаях, когда возникает необходимость манипулировать большими объемами данных. У базы данных есть имя. Она состоит из таблиц, в которых хранятся данные, и из дополнительных элементов, поддерживающих работоспособность базы данных, а также достоверность содержащейся в ней информации (рис. 1).

Рассмотрим более подробно элементы базы данных.

Рис.1



Наиболее распространенная трактовка реляционной модели данных на сегодняшний день принадлежит К. Дейту, согласно которой эта модель состоит из трех частей.

• 
  Структурная часть описывает, какие объекты рассматриваются реляционной моделью. Постулируется, что реляционной базой данных называется база данных, состоящая из набора отношений. Схемой реляционной базы данных называется набор заголовков отношений, входящих в базу данных.
  
• 
  Целостная часть описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах
  

данных. Это целостность сущностей и целостность внешних ключей.

• 
  Манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными — реляционную алгебру и реляционное исчисление. С практической точки зрения, важным является вывод о реляционной полноте структурного языка запросов SQL в том или ином стандарте, который и реализует манипуляционную часть реляционной модели в реальных СУБД.
  

1. Структурная часть реляционной базы данных

Сам термин реляционное представление данных, введенный Коддом, происходит от латинского RELATIO, что означает "отношение" или "таблица". Таблица является наиболее привычным и удобным вместилищем для хранения информации, имеет жестко оговоренное количество поименованных и упорядоченных столбцов (структуру), и может неограниченно расти по количеству строк.

Теоретической основой реляционных баз данных являются такие математические дисциплины, как теория множеств и реляционная алгебра или алгебра отношений. Фундаментальным понятием реляционной модели данных является теоретико-множественное определение понятия отношения, которое формулируется следующим образом.

Пусть даны N множеств D1, D2, ..., DN (не обязательно различных), называемых доменами отношения R. Тогда R есть отношение над этими множествами, если само множество R есть множество упорядоченных n-кортежей вида , где d1 — элемент из D1, d2 — элемент из D2, ..., dn — элемент из DN.

Отношение R, определенное на множестве доменов D1, D2, ..., DN, имеет две части: заголовок и тело.

Заголовок отношения содержит фиксированное количество названий атрибутов (столбцов) отношения. Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами

соответствующих доменов. Заголовок статичен, он не меняется во время работы с базой данных. Если в отношении изменены, добавлены или удалены

атрибуты, то в результате получим уже другое отношение (пусть даже с прежним именем).

Тело отношения представляет собой набор кортежей, т. е. подмножество декартового произведения доменов, что собственно и является отношением в математическом смысле слова. Тело отношения может модифицироваться

во время работы с базой данных — кортежи могут изменяться, добавляться и удаляться.

Понятие отношения фактически лежит в основе теории реляционных баз данных. В практической реализации любой реляционной СУБД отношения являются математическим аналогом таблиц. В таблице 1 приведены термины, которые употребляются как синонимы.

Таблица. 1



Свойства отношений непосредственно следуют из приведенного выше определения. Принципиальными здесь являются следующие моменты.

1. 
   Все элементы отношения есть однотипные кортежи, что позволяет считать их аналогами строк в простой таблице, т. е. в такой таблице, в которой все строки состоят из одинакового числа ячеек и в соответствующих ячейках содержатся одинаковые типы данных.
   
2. 
   За исключением крайнего случая отношение включает в себя не все возможные кортежи из декартового произведения доменов, на которых оно определено. Это значит, что для каждого отношения имеется критерий, позволяющий определить, какие кортежи входят в отношение, а какие нет.
   

Этот критерий определяет смысл, или семантику, отношения. Он является логическим выражением и называется предикатом отношения R.

3. 
   В отношении нет одинаковых кортежей, и кортежи не упорядочены сверху вниз, т. к. само отношение есть множество кортежей, и, следовательно, не упорядочено. Кроме того, как всякое множество отношение не может содержать неразличимые элементы. Поэтому одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке.
   

2. Основные принципы разработки базы данных

Рассмотрим к чему разработчик или проектировщик базы данных должен стремиться в своей работе, это основные правила построения качественной базы данных.

• 
  Доступность. База данных должна быть спроектирована так
  

чтобы данные, хранящиеся в ней, были доступны пользователю в любое время. База данных должна быть защищена от сбоев и непредвиденных ситуаций. Если в работе базы данных все же случился сбой, то он должен быть устранен в минимальные сроки и посредством специалиста или специалистов, обслуживающих данную базу.

• 
  Расширяемость. База данных, как правило, отражает отношения чего-либо (товарно-денежные отношения людей) либо хранит информацию о каких-то объектах (данные по продажам, паспортные данные людей и т. д.). Со временем могут потребоваться изменения в базе данных, либо расширилось количество данных, которые требуется хранить, либо изменились правила отношений между людьми. Можно приводить кучу примеров причин, из-за которых возникает необходимость в изменении структуры базы данных. Принцип расширяемости регламентирует процесс внесения изменений в структуру базы данных. По времени он должен быть минимальным, а качество отраженных изменений — максимально.
  
• 
  Непротиворечивость. База данных должна быть спроектирована таким образом, чтобы была исключена возможность возникновения в ней противоречивой информации.
  

3. Что такое Транзакция

Рассматривался пример, в котором требовалось изменить

Код_продукта=13 на новое значение Код_продукта=20 и для этого пришлось

проводить последовательное изменение в трех таблицах.

UPDATE Продукты SET Код_продукта=20 WHERE Код_продукта=13;

UPDATE Состав SET Код_продукта=20 WHERE Код_продукта=13;

UPDATE Поставки SET Код_продукта=20 WHERE Код_продукта=13;

Этот пример приведен здесь для иллюстрации того, что единственная, с точки зрения пользователя, операция может потребовать нескольких операций над базой данных. Более того, в ходе выполнения этих операций может нарушаться непротиворечивость базы данных. Например, в ней могут временно содержаться записи поставок, для которых не имеется соответствующих записей поставляемых продуктов. Положение не спасает и перестановка последовательности обновляемых таблиц. Противоречивость исчезнет только после выполнения всех обновлений, т. е. выполнения логической единицы работы — полной замены кода продукта в базе данных (независимо от количества таблиц, в которых встречается код продукта).

Теперь можно дать определение транзакции.

Транзакция, или логическая единица работы, — это в общем случае последовательность ряда таких операций, которые преобразуют некоторое непротиворечивое состояние базы данных в другое непротиворечивое состояние, не гарантируя сохранения непротиворечивости во все промежуточные моменты времени.

В литературе для объяснения транзакции обычно приводится следующий классический пример.

Необходимо перевести с банковского счета номер 5 на счет номер 7 суммув 10 денежных единиц.

Этого можно достичь, например, такой последовательностью действий:

Начать транзакцию

прочесть баланс на счету номер 5

уменьшить баланс на 10 денежных единиц

сохранить новый баланс счета номер 5

прочесть баланс на счету номер 7

увеличить баланс на 10 денежных единиц

сохранить новый баланс счета номер 7

Окончить транзакцию.

Эти действия представляют собой логическую единицу работы "перевод

суммы между счетами", и таким образом, являются транзакцией. Если прервать данную транзакцию, к примеру, в середине, и не аннулировать все изменения, легко оставить владельца счета номер 5 без 10 единиц, тогда как

владелец счета номер 7 их не получит.

Никто кроме пользователя, генерирующего ту или иную последовательность SQL-предложений, не может знать о том, когда может возникнуть противоречивое состояние базы данных и после выполнения каких SQL-предложений оно исчезнет, т. е. база данных вновь станет актуальной. Поэтому в большинстве СУБД создается механизм обработки транзакций, при инициировании которого все изменения данных рассматриваются как предварительные до тех пор, пока пользователь (реже система) не выдаст предложения:

• 
  COMMIT (фиксировать), превращающее все предварительные обновлениябв окончательные ("зафиксированные");
  
• 
  ROLLBACK (откат), аннулирующее все предварительные обновления.
  

Таким образом, транзакцией можно назвать последовательность SQL предложений, расположенных между "точками синхронизации", учреждаемых в начале выполнения программы и издании COMMIT или ROLLBACK, и только в этих случаях. При этом следует иметь в виду, что возможен неявный COMMIT (существует режим AUTOCOMMIT, в котором система издает COMMIT после выполнения каждого SQL-предложения) и ROLLBACK (выполняемый при аварийном завершении программы).

Ясно теперь, что пользователь должен сам решать, включать ли механизм обработки транзакций и если включать, то где издавать COMMIT (ROLLEBACK), т. е. какие последовательности SQL-предложений являются транзакциями.

3. Явные транзакции

Явные транзакции (explicit transaction) предполагают явное указание пользователем начала и конца транзакции при помощи соответствующих операторов Transact-SQL. Поскольку границы транзакции определяются пользователем, этот режим транзакций зачастую называют пользовательским (user-defined transaction). При явном режиме определения транзакций пользователь долженсам заботиться о соблюдении в рамках приложений логической целостности данных и бизнес-правил. Именно пользователь решает, какие операторы должны выполняться в рамках одной транзакции, а какие могут быть представлены несколькими, последовательно выполняемыми транзакциями. Ключевой задачей при планировании транзакций является обеспечение целостности данных. Операции, которые должны выполняться как единое целое (например, списание суммы с одного счета и зачисление на другой), следует объединять в одну транзакцию. И наоборот, если операции между собой логически не связаны и откат одной операции не оказывает влияние на результаты другой, необходимо выполнять их в рамках различных транзакций.

1. Определение начала транзакции

Каждая явная транзакция имеет свое начало и конец. Начало транзакции задается при помощи оператора BEGIN TRANSACTION. Этот оператор задает начало транзакции, но при этом транзакция не регистрируется в журнале до тех пор, пока не будет выполнена первая операция, изменяющая данные. Только в этот момент в журнале создается запись, отражающая начало определенной транзакции. Если в последующем транзакция будет прервана и потребуется выполнить откат, система выполнит откат всех изменений, связанных с этой транзакцией, вплоть до данной записи. Оператор имеет следующий формат:

BEGIN TRAN[SACTION] [<имя_транзакции>] [WITH MARK <имя_отметки>]

Имя транзакции может быть задано как идентификатор, так и при помощи строковой переменной. Использование переменной для указания имени транзакции позволяет нескольким пользователям создавать множество транзакций, используя один и тот же код (например, хранимую процедуру). Имя транзакции должно удовлетворять стандартным правилам именования объектов, но его длина не должна превышать 32 символа. Обычно имена транзакций используются в случае, если имеется несколько транзакций и необходимо внести ясность в работу с ними. Имена транзакций улучшают читаемость кода, однако SQL Server запоминает имя только первой транзакции и игнорирует имена всех вложенных транзакций.

Тем не менее существует возможность зарегистрировать имя транзакции в журнале. Для этого следует использовать предложение WITH MARK, позволяющее создать специальную именованную отметку в журнале.

В качестве имени отметки может выступать любой строковый литерал (в том числе и в формате Unicode). Длина отметки не может превышать 510 символов (255 символов, если литерал представлен в формате Unicode). Если при начале транзакции была сделана отметка в журнале, впоследствии пользователь может выполнить восстановление базы данных вплоть до указанной отметки.

2. Сохранение состояния транзакции

Для продолжительных транзакций, состоящих из нескольких операторов, существует возможность устанавливать точки сохранения (savepoints). Точки сохранения используются для выполнения частичного отката транзакции. Частичный откат транзакции предполагает при выполнении некоторого условия откат всех изменений, произведенных после точки сохранения. Точки сохранения устанавливаются при помощи оператора SAVE TRANSACTION, имеющего следующий формат:

SAVE TRAN[SACTION] [<имя_точки_сохранения >].

Имя точки сохранения должно отвечать тем же правилам, что и имена транзакций (то есть длина имени не должна превышать 32 символа). Оно может быть задано как идентификатор, так и при помощи строковой переменной. В рамках транзакции можно создать несколько точек сохранения с одинаковыми именами, однако откат может быть выполнен только к самой последней из них.

3. Откат явных транзакций

При необходимости пользователь может прервать выполнение транзакции и выполнить ее откат. Откат транзакции может быть вызван, например, при выполнении определенного логического условия. В ходе отката транзакции происходит откат всех произведенных в ее рамках изменений. При этом в журнале создается запись о том, что транзакция была отменена. Оператор отката транзакции имеет следующий формат:

ROLLBACK[TRAN[SACTION][<имя_транзакции>|<имя_точки_сохранения>]

Имя транзакции может быть задано при помощи строкового литерала или строковой переменной. Аналогичным способом может быть задано и имя точки сохранения. Откат может быть произведен как для всей транзакции целиком (параметры оператора либо отсутствуют, либо указывается имя транзакции), так и только для ее части (при этом указывается имя точки сохранения). Приложению или пользователю, инициировавшему транзакцию, в случае ее отката не передается какая-либо информация. Если же для работы приложения необходимо знать причину выполнения отката или сам факт его выполнения, следует использовать оператор RAISERROR.

4. Фиксация явных транзакций

Для обозначения конца транзакции используется оператор COMMIT TRANSACTION. Этот оператор указывает реляционному механизму SQL Server о необходимости выполнить фиксацию транзакции в случае успешного завершения работы всех операторов, являющихся ее частью. В ходе фиксации все изменения, произведенные в рамках данной транзакции, становятся постоянными. При этом в журнале создается запись о том, что изменения зафиксированы и транзакция считается транзакции и управление параллельным доступом завершенной. В дальнейшем откат этих изменений будет выполнить невозможно.

Оператор фиксации транзакции имеет следующий формат:

COMMIT [ TRAN[SACTION] [<имя_транзакции>] ]

Имя транзакции может быть задано как идентификатор либо посредством строковой переменной. В любом случае указание имени транзакции является необязательным. Оно предназначено исключительно для улучшения читаемости кода. Реляционный механизм SQL Server игнорирует при фиксации указанные в операторе имена транзакций.

3. Неявные транзакции

При работе в режиме неявного начала транзакций (implicit transaction) реляционный механизм SQL Server автоматически начинает новую транзакцию, как только завершается предыдущая. В этом режиме явно не задается начало транзакции, но должен быть явно определен момент ее завершения. Транзакция продолжается до тех пор, пока пользователь явно не укажет команду отката (оператор ROLLBACK TRANSACTION) или фиксации (оператор COMMIT TRANSACTION) транзакции, после чего сервер автоматически начинает новую транзакцию. В итоге создается непрерывная цепь транзакций.

Если для соединения устанавливается режим неявных транзакций, сервер автоматически начнет первую транзакцию, как только будет выполнен один из следующих операторов:

• 
  CREATE. Создание некоторого объекта базы данных.
  
• 
  ALTER TABLE. Изменение структуры таблицы.
  
• 
  DELETE. Удаление строк данных из таблицы.
  
• 
  DROP. Удаление некоторого объекта базы данных.
  
• 
  TRUNCATE TABLE. Усечение таблицы.
  
• 
  SELECT. Выборка данных из таблиц.
  
• 
  UPDATE. Изменение данных в таблице.
  
• 
  INSERT. Добавление строк в таблицу.
  
• 
  OPEN. Открытие курсора.
  
• 
  FETCH. Извлечение некоторых значений из курсора.
  
• 
  GRANT. Предоставление доступа к объектам базы данных.
  
• 
  REVOKE. Неявный отзыв доступа к объектам базы данных.
  

Транзакция продолжается до тех пор, пока не встретится оператор фиксации транзакции или оператор, предписывающий выполнить ее откат. После того как транзакция зафиксирована, реляционный механизм SQL Server инициирует начало новой транзакции в случае выполнения одного из перечисленных выше операторов.

Режим неявных транзакций устанавливается на уровне соединения при помощи специальной команды:

SET IMPLICIT_TRANSACTION ON

Для отмены режима неявных транзакций и возвращения к режиму автоматически фиксируемых транзакций следует выполнить команду:

SET IMPLICIT_TRANSACTION OFF.

1. Автоматически фиксируемые транзакции

В режиме автоматически фиксируемых транзакций (autocommit transaction) каждый оператор Transact-SQL рассматривается как отдельная транзакция. Пользователю при этом не требуется явно указывать начало и конец транзакции, поскольку SQL Server автоматически фиксирует или откатывает изменения, производимые каждым оператором. Если выполнение оператора заканчивается успешно, произведенные им изменения будут зафиксированы. Если же при выполнении оператора произошла ошибка, то для всех произведенных им изменений будет инициирован откат. В режиме автоматически фиксируемых транзакций приложение или пользователь всегда имеют возможность использовать режим явного задания транзакций. Для этого следует использовать операторы явного управления транзакциями. Как только встретится оператор BEGIN TRANSACTION, реляционный механизм переходит в режим явной транзакции. Все операторы, следующие за BEGIN TRANSACTION, не будут фиксироваться до тех пор, пока не будет явно предписано выполнить их фиксацию или откат. После того как транзакция будет зафиксирована или для нее будет выполнен откат, сервер вновь перейдет к режиму автоматически фиксируемых транзакций.

По умолчанию SQL Server работает в режиме автоматического начала транзакций. В дальнейшем пользователь может установить на уровне сеанса режим неявных транзакций либо явно указать начало и конец транзакции, переходя в режим явных транзакций.

Вывод

Сервер баз данных, под управлением SQL Server, может одновременно выполнять запросы большого количества пользователей. При этом совершенно не исключается ситуация, когда несколько пользователей пытаются работать с одними и теми же данными. В самом простом случае несколько пользователей одновременно считывают один и тот же набор данных. Разумеется, при этом они никак не мешают друг другу — каждый пользователь считывает одинаковый набор данных. Проблемы начинаются, когда пользователи начинают изменять или удалять данные, с которыми работают другие пользователи. Проблемы возникают как при одновременном изменении данных несколькими пользователями, так и при чтении изменяемых данных. Трудно предсказать, какой набор данных могут получить пользователи из таблицы, если один или более пользователей в это время производит изменение строк. Кроме того, если операция изменения данных оказалась неуспешной, целостность и достоверность данных в таблице может быть нарушена. Для большинства задач подобная неоднозначность является критической.

Список литературы