2. Особенности разработки правил контроля ссылочной целостности
и работы с транзакциями в СУБД MySQL 5
При работе с транзакциями и средствами контроля целостности данных, необходимо помнить, что в MySQL 5 поддерживаются только таблицами типа InnoDB (в пятой версии это тип таблицы по умолчанию).
2.1 Ссылочная целостность
Правила по контролю ссылочной целостностью задаются при создании внешнего ключа (при выполнении команд CREATE TABLE и ALTER TABLE) следующим образом (приведена лишь часть запроса):
KEY
название ключа в дочерней таблице (поле в дочерней таблице)
CONSTRAINT
Название внешнего ключа
FOREIGN KEY (поле в дочерней таблице)
REFERENCES имя родительской таблицы (поле в родительской таблице)
[ON DELETE reference_option]
[ON UPDATE reference_option]
Здесь:
поле в дочерней таблице – имя поля содержащего внешний ключ в дочерней таблице, по данному полю должен быть создан индекс
имя родительской таблицы – имя внешней (родительской) таблицы на данные из которой ссылается внешней ключ
поле в родительской таблице – имя поля в родительской таблице, на которую ссылается внешний ключ, по данному полю должен быть создан индекс.
ON DELETE, ON UPDATE reference_option – правило поведения при (удалении/изменении) родительской записи, может принимать значения:
CASCADE – каскадное изменение
SET NULL – устанавливать дочернее поле в NULL
NO ACTION – игнорировать существование ограничения
RESTRICT – в MySQL 5 то же что и NO ACTION
Как правило, задается только ON DELETE правило, так как при синхронизации по первичному реляционному ключу (авто-инкрементому) обновления значения ключа не происходит.
Перед заданием правила необходимо создать ключевые поля в дочерней и родительской таблицах. Также правило может быть задано и после создания таблиц, например (здесь и далее рассматриваются таблицы из ЛР № 4):
ALTER TABLE `students`
ADD CONSTRAINT `students_fk`
FOREIGN KEY (`group_id`)
REFERENCES `groups` (`group_id`) ON DELETE CASCADE;
В EMS Manager для задания таких правил существует удобный интерфейс (см рисунок 8.1), данный диалог может быть вызван из закладки Foreign Keys для любой таблицы:
Здесь:
Table fields – задание поля дочерней таблицы;
Foreign table fields – задание поля родительской таблицы;
On delete rule – задает правила поведения при удалении строки в
родительской таблице
On update rule - – задает правила поведения при обновлениее строки в
родительской таблице
Рисунок 8.1 – Утилита EMS SQL Manager Lite for MySQL: диалог в режиме
редактирования внешнего ключа.
2.2 Транзакции
По умолчанию MySQL работает в режиме автоматического завершения транзакций (autocommit). Это означает, что как только выполняется оператор обновления данных, который модифицирует таблицу, MySQL тут же сохраняет изменения на диске (данное поведение может быть изменено, рассмотрение изменения поведения завершения транзакций находится за рамками данной лабораторной работы).
Если есть необходимость отключить режим автоматического завершения транзакций только для отдельной последовательности операторов, можно воспользоваться оператором
START TRANSACTION:
START TRANSACTION
SELECT … FROM GROUPS
UPDATE STUDENTS SET …
COMMIT;
После START TRANSACTION режим автоматического завершения транзакций остается выключенным до явного завершения транзакции с помощью COMMIT или отката посредством ROLLBACK. Затем режим автоматического завершения возвращается в свое предыдущее состояние. Уровень изоляции транзакций может быть изменен оператором SET TRANSACTION ISOLATION LEVEL (см. ниже).
Для некоторых операторов нельзя выполнить откат с помощью ROLLBACK. В их число входят операторы языка определения данных (Data Definition Language - DDL), которые создают и уничтожают базы данных, а также создают, удаляют и изменяют таблицы.
Следующие операторы неявно завершают транзакцию (как если бы перед их выполнением был выдан COMMIT):
ALTER TABLE
BEGIN
CREATE INDEX
DROP DATABASE
DROP INDEX
DROP TABLE
LOAD MASTER DATA
LOCK TABLES
RENAME TABLE
SET AUTOCOMMIT=1
START TRANSACTION
TRUNCATE TABLE
Оператор UNLOCK TABLES также завершает транзакцию, если какие-либо таблицы были блокированы.
Транзакции в MySQL не могут быть вложенными. Это следствие того, что неявный COMMIT выполняется для любой текущей транзакции, когда выполняется оператор START TRANSACTION или его синонимы. Операторы SAVEPOINT и ROLLBACK TO SAVEPOINT:
SAVEPOINT идентификатор
ROLLBACK TO SAVEPOINT идентификатор
Оператор SAVEPOINT устанавливает именованную точку начала транзакции с именем идентификатор. Если текущая транзакция уже имеет точку сохранения с таким же именем, старая точка удаляется и устанавливается новая.
Оператор ROLLBACK TO SAVEPOINT откатывает транзакцию к именованной точке сохранения. Модификации строк, которые выполнялись текущей транзакцией после этой точки, отменяются откатом. Точки сохранения, установленные в более поздние моменты, чем именованная точка, удаляются.
Операторы LOCK TABLES и UNLOCK TABLES:
LOCK TABLES
имя_таблицы [AS псевдоним] {READ [LOCAL] | [LOW_PRIORITY]
WRITE}
[,имя_таблицы [AS псевдоним] {READ [LOCAL] | [LOW_PRIORITY]
WRITE}] ...
UNLOCK TABLES
LOCK TABLES блокирует таблицы для текущего потока сервера. UNLOCK TABLES снимает любые блокировки, удерживаемые текущим потоком. Все таблицы, заблокированные в текущем потоке, неявно разблокируются, когда поток выполняет другой оператор LOCK TABLES либо когда закрывается соединение с сервером.
LOCK TABLES не является оператором, безопасным в отношении транзакций, и неявно завершает транзакцию перед попыткой блокировать таблицы.
Основная причина необходимости применения LOCK TABLES – эмуляция транзакций или повышение скорости обновления таблиц. Если поток устанавливает блокировку по чтению (READ) на таблице, то этот поток (и все остальные) может только читать данные из таблицы. Если поток устанавливает блокировку записи (WRITE) таблицы, то лишь этот поток может читать и писать в таблицу. Доступ остальных нитей к таблице блокируется.
Разница между READ LOCAL и READ состоит в том, что READ LOCAL позволяет неконфликтующим операторам INSERT (параллельным вставкам) выполняться, пока блокировка удерживается. Однако это не может быть выполнено, если осуществлена попытка манипулировать файлами базы данных извне MySQL в то время, пока удерживается блокировка (т.н. оптимистическая и пессимистическая блокировка).
В случае применения LOCK TABLES необходимо блокировать все таблицы, которые используются в запросах. Если одна и та же таблица используется несколько раз в запросе (через псевдонимы), необходимо получить блокировку на каждый псевдоним. Пока блокировка, полученная от LOCK TABLES, активна, нельзя получить доступ ни к каким таблицам, которые не были блокированы этим оператором.
Если запрос обращается к таблице через псевдоним, то необходимо блокировать таблицу, используя тот же псевдоним. Блокировка таблицы не будет работать, если не указан псевдоним, например, выполнение операторов
LOCK TABLE students READ;
SELECT * FROM students AS studentstable;
вызовет ошибку: Table 'studentstable' was not locked with LOCK TABLES, для блокировки таблицы через псевдоним необходимо было использовать конструкцию LOCK TABLE students AS studentstable READ.
Блокировки по записи (WRITE) обычно имеют более высокий приоритет, чем блокировки по чтению (READ), чтобы гарантировать, что обновления данных пройдут как можно быстрее. Это означает, что если один поток получает блокировку по чтению, а затем другой поток запрашивает блокировку по записи, то последующие запросы на блокировку по чтению будут ожидать, пока не будет установлена и снята блокировка по записи (приоритет операций может быть изменен, рассмотрение изменения приоритета операций находится за рамками данной лабораторной работы). LOCK TABLES работает следующим образом:
1. В определенном внутреннем порядке сортируются все таблицы, подлежащие блокировке. С точки зрения пользователя, этот порядок не определен.
2. Если таблица блокируется и по чтению и по записи, устанавливается блокировка записи перед блокировкой чтения.
3. Блокируется по одной таблице за раз до тех пор, пока поток не получит все блокировки.
Эта политика гарантирует, что при этом не случится взаимных блокировок (deadlocks).
Оператор SET TRANSACTION
SET TRANSACTION
SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ |
SERIALIZABLE }
Этот оператор устанавливает уровень изоляции следующей транзакции, глобально либо только для текущего сеанса. Поведение SET TRANSACTION по умолчанию заключается в том, что он устанавливает уровень изоляции для следующей (еще не стартовавшей) транзакции. Если используется ключевое слово GLOBAL, оператор устанавливает глобальный уровень изоляции транзакций по умолчанию для всех новых соединений, которые будут установлены с этого момента. Существующие соединения не затрагиваются. Уровни изоляции транзакций и их смысл соответствуют рассмотренным в разделе «Общие сведения».
LOCK TABLE (блокировка) и SET TRANSACTION (установка уровня изоляции транзакций) представляют собой различные подходы к изоляции транзакций.
Рассмотрим примеры, связанные с выполнением транзакций:
Запросы:
START TRANSACTION;
insert into students (student_id, firstname, lastname, group_id)
values (21, 'Степанов', 'Георгий', 3);
insert into students (student_id, firstname, lastname, group_id)
values (22, 'Дуравкин', 'Петр', 3);
ROLLBACK;
не внесут изменения в БД.
Запрос
START TRANSACTION;
insert into students (student_id, firstname, lastname, group_id)
values (21, 'Степанов', 'Георгий', 3);
SAVEPOINT onestud;
insert into students (student_id, firstname, lastname, group_id)
values (22, 'Дуравкин', 'Петр', 3);
ROLLBACK TO SAVEPOINT onestud;
добавит в таблицу students только одну запись.
В качестве примера использования транзакций в прикладных программах при взаимодействии с БД рассмотрим следующею ситуацию:
необходимо вставить в таблицу некоторой БД 10 строк, в случае невозможности вставки записи (неправильный внешний ключ, дублирование первичного реляционного ключа), и т.д. данные не должны быть вставлены вообще
Тогда схематически алгоритм добавления данных можно описать следующим образом:
Шаг 1. START TRANSACTION
Шаг 2. если остались не добавленные записи выполнить запрос INSERT для текущей записи, иначе Шаг 4
Шаг 3. если запрос был выполнен удачно, перейти к Шагу 2, иначе к Шагу 5
Шаг 4. COMMIT, Выход из процедуры добавления
Шаг 5. ROLLBACK, Выход из процедуры добавления
Таким образом, либо все записи будут добавлены удачно и команда COMMIT подтвердит добавление данных, либо команда ROLLBACK вернет таблицы БД к состоянию до начала транзакции.