4. Контрольные вопросы

1) Знать определения ОБЛ: представление, хранимая процедура, триггер, и понимать логические схемы их функционирования.

2) Знать синтаксис команд создания / удаления представлений.

3) Знать синтаксис команд создания / изменения / удаления хранимых процедур (синтаксис изменения / удаления в данном документе не приведен и выносится на самостоятельную проработку с использованием рекомендованной литературы – см. ниже).

4) Знать синтаксис команд создания/удаления триггеров (синтаксис удаления в данном документе не приведен и выносится на самостоятельную проработку с использованием рекомендованнойлитературы – см. ниже).

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

1) Лекции по курсу «Организация Баз Данных и Знаний» / каф. АСУ, НТУ «ХПИ».

2) Дэйт К. Дж. Введение в системы баз данных – М-С.Пб-К: Вильямс,2001. – 1072 с.

3) Грабер Мартин. Введение в SQL – М.: Лори, 1996 – 382 с.

4) MySQL 5.1 Reference Manual // http://downloads.mysql.com/docs/refman5.1-en.chm

5) www.mysql.ru

6) Справка SQL Manager 2005 for MySQL

ЛАБОРАТОРНАЯ РАБОТА № 8

Тема: ИЗУЧЕНИЕ СРЕДСТВ ПОДДЕРЖКИ ССЫЛОЧНОЙ

ЦЕЛОСТНОСТИ И УПРАВЛЕНИЯ ТРАНЗАКЦИЯМИ

В СУБД MYSQL 5

Цель работы:

Ознакомиться с основными функциональными возможностями СУБД

MySQL 5 для разработки механизмов поддержки ссылочной целостности и

для упоавления транзакциями.

1. Общие сведения

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

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

0 — Read Uncommited (Dirty Read) — чтение незафиксированных изменений своей транзакции и конкурирующих транзакций, возможны некорректные, неповторяемые чтения и фантомы

1 — Read Commited — чтение всех изменений своей транзакции и зафиксированных изменений конкурирующих транзакций, некорректные чтения невозможны, возможны неповторяемые чтения и фантомы

2 — Repeatable Read (Snapshot) — чтение всех изменений своей транзакции, любые изменения, внесённые конкурирующими транзакциями после начала своей недоступны, некорректные и неповторяемые чтения невозможны, возможны фантомы

3 — Serializable — cериализуемые транзакции, то есть транзакции, результат действия которых не зависит от порядка выполнения шагов транзакции (запрещено чтение всех данных изменённых с начала транзакции, в том числе и своей транзакцией).

Чем выше уровень изоляции, тем больше требуется ресурсов, чтобы их поддерживать. Чаще всего используется уровень 1 (Read Commited). Уровень 0 используется в основном для отслеживания изменений длительных транзакций. Уровень 2 —соответствует теоретическому пониманию изоляции транзакций. Уровень 3 удобен для оптимизаторов СУБД. Несмотря на то, что наиболее безопасными являются второй и третий уровни изоляции транзакций, в различных ситуациях (когда гарантировано известно, что те или иные проблемы не возникнут) можно использовать и более низкие уровни изоляции с тем, чтобы снизить количество используемых в ходе работы транзакций ресурсов.

Часть СУБД, в которой хранятся записи о планирующихся транзакциях называется журнал транзакций. Работа с ним состоит из трёх шагов:

1. Сделать запись о намерение произвести некоторые операции.

2. Выполнить операции.

3. Внести запись, что операции выполнены безошибочно.

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

• Если повреждена запись, то сбой произошёл во время проставления отметки в журнале. Значит, ничего важного не потерялось, игнорируем эту ошибку.

• Если все записи помечены как успешно выполненные, то сбой произошёл между транзакциями, здесь также нет потерь.

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