Построение базы данных

      При записи страниц данных на диск фиксируется SCN транзакции, производящей эту запись. Этот SCN становится текущим системным номером страницы данных.

      Транзакции, только читающие данные не блокируют ничего в базе данных.

      Если транзакция A читает страницу данных, то SCN транзакции A сравнивается с SCN читаемой страницы данных.

      Если SCN страницы данных меньше или равен SCN транзакции A, то транзакция A читает эту страницу.

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

Рассмотрим, как решается проблема несовместного анализа с использованием механизма выделения версий. (см. Приложение 3)

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

Результат. Транзакция A, начавшаяся первой не тормозит конкурирующую транзакцию B. При обнаружении конфликта (чтение транзакцией A измененного счета 3), транзакции A предоставляется своя версия данных, которая была на момент начала транзакции A.

Теорема Есварана о сериализуемости. Концепция способности к упорядочению была впервые предложена Есвараном.

В этой работе был предложен протокол двухфазной блокировки:

      Перед выполнение каких-либо операций с некоторым объектом, транзакция должна заблокировать этот объект.

      После снятия блокировки, транзакция не должна накладывать никаких других блокировок.

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

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

Протокол называется двухфазным, потому что он характеризуется двумя фазами:

      1 фаза - нарастание блокировок. Во время этой фазы накладываются блокировки, и производится работа с заблокированными объектами.

      2 фаза - снятие блокировок. Во время этой фазы блокировки только снимаются. Работа с ранее заблокированными данными может продолжаться.

Работа транзакции может выглядеть приблизительно, как это изображено на Рисунке 2.

Рисунок 2. Работа транзакции по протоколу двухфазной блокировки

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

Рисунок 3. Транзакция, не подчиняющаяся протоколу двухфазной блокировки

На практике, как правило, вторая фаза сводится к одной операции завершения транзакции (или отката транзакции) с одновременным снятием всех блокировок.

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

Реализация изолированности транзакций средствами SQL. Стандарт SQL не предусматривает понятие блокировок для реализации сериализуемости смеси транзакций. Вместо этого вводится понятие уровней изоляции. Этот подход обеспечивает необходимые требования к изолированности транзакций, оставляя возможность производителям различных СУБД реализовывать эти требования своими способами (в частности, с использованием блокировок или выделением версий данных).

Стандарт SQL-92 определяет уровни изоляции, установка которых предотвращает определенные конфликтные ситуации. Введены следующие четыре уровня изоляции:

      Serializable (упорядочиваемость) Самый высокий уровень изолированности; транзакции полностью изолируются друг от друга. На этом уровне результаты параллельного выполнения транзакций для базы данных совпадают с последовательным выполнением тех же транзакций (по очереди в каком-либо порядке).

      Repeatable read (повторяемость чтения) - Уровень, при котором чтение одной и той же строки или строк в транзакции дает одинаковый результат. (Пока транзакция не завершена, никакие другие транзакции не могут модифицировать эти данные.)

      Read committed (чтение фиксированных данных)-Принятый по умолчанию уровень для SQL Server. На этом уровне разрешается чтение только фиксированных данных.

      Read uncommitted (чтение незафиксированных данных) - Самый низкий уровень изолированности. На этом уровне транзакции изолированы только в такой степени, чтобы нельзя было читать физически поврежденные данные.

Таблица 11 Поведение при различных уровнях изолированности. («+» — предотвращает, «–» — не предотвращает.)

Глава 3. Построение базы данных

Разработка реляционной базы данных «Футбольные матчи».

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

С учетом этих требований в MS Access была разработана и построена база данных, схема данных которой выглядит следующим образом:

Рис 3. Схема данных  БД  «Футбольные матчи».

Как видно из схемы данных  БД  включает в себя 9 таблиц: Игроки, Тренер, Команда, Амплуа, Поле, Команда1, Команда2, Матч и Судья.

Список полей, содержащихся в каждой таблице, виден на рис. 3, тем не менее, далее  рассмотрим содержание каждой таблицы в режиме конструктора.

Таблица Игроки:

Всего в ней 6 полей. Для каждого поля определен свой тип данных. Ключевым полем является поле Игрок.

Таблица Амплуа может показаться лишней в данной БД,  ее можно было и не строить. Но эта таблица не является лишней. Она сделана для того, что уменьшить число ошибок, при заполнении поля Амплуа в таблице Игрок, а также для  поля Амплуа в таблице Игрок она служит диапазоном значений в выпадающем списке.

Таблица Команда включает в себя  5 полей, ключевыми  полями будут  поля Команда и Тренер.  Для установки сразу двух полей выделим оба поля удерживая клавишу Shift и нажав правую кнопку мыши выберем в появившемся меню пункт Ключевое поле.

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

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

Еще более простой список полей имеет Таблица Поле (всего 3 поля), которая содержит в себе данные касающиеся места игры (т.е. стадиона).

Одинаковыми по составу полей являются таблицы Команда1 и Команда2, отличаются они только ключевыми полями IDGamer1 и IDGamer2 соответственно. В эти таблицы заносятся данные о командах – противниках, которые играют в общем матче. Данные этих таблиц соотносятся в Таблице  Матч через поле IDGame.

И самой крупной таблицей в данной БД является Таблица Матч.

Она включает в себя 9 полей. В эту таблицу заносится информация о состоявшихся матчах.

Кроме Схемы данных, состава таблиц требовалось включить в данную работу:

1.      описание порядка действий для создания однотабличной формы с вычисляемым полем;

2.      описание порядка действий для создания многотабличной формы;

3.      описание порядка действий для создания формы–заставки.

1.      Порядок  действий для создания однотабличной формы с вычисляемым полем

К примеру, подсчитаем сколько тренеров содержит наша база данных. Для этого  выберем пункт Создание формы с помощью Мастера.

В появившемся окне выберем таблицу Тренер и нужные нам поля. Далее выберем нужный вид формы  и стиль формы. На последнем шагу дадим название нашей форме и выберем пункт Изменить макет формы. После  этого форма откроется в режиме Конструктора.

Для создания вычисляемого поля создадим  поле. Дадим соответствующее название, а в само поле впишем «формулу» для вычисления количества записей в таблице. Запись будет выглядеть так:  =Count([Тренер]). Закроем форму и взглянем на полученный результат:

2. Описание порядка действий для создания многотабличной формы.

Выберем пункт Создание формы с помощью Мастера, в ней выберем нужные нам таблицы и поля. Нажмем Далее. Если между добавленными страницами имеется связь, появится окно, где можно выбрать вид представления данных, выберем нужный пункт и нажмем Далее. Дальше будут те же пункты, которые были при создании однотабличной формы.

В созданной форме будут содержаться  несколько таблиц.  Пример многотабличной  формы:

2.      Описание порядка действий для создания формы–заставки.

Создадим пустую форму, дадим ей название и введем в нее необходимую информацию. Создадим макрос, закрывающий форму. Откроем форму в режиме конструктора и в свойствах формы на вкладке Макет уберем ненужные параметры окна. На вкладке События в поле свойства Таймер выберем из списка макрос для закрытия заствки; в поле свойства Интервал таймера установим время в миллисекундах, по прошествии которого после открытия формы запустится макрос. Создадим макрос с именем Autoexec и запишем в него макрокоманду: Открыть Форму, задать имя нашей заставки.  Пример заставки:

Создадим запросы следующих видов:

1.                 На выборку со сложным условием отбора (с использованием логических операций OR, AND, NOT, встроенных функций);

Допустим требуется, отсортировать нападающих и защитников старше 1986 года рождения.