- •Базы данных
- •Введение
- •Часть 1. Проектирование баз данных
- •1.1. Некоторые понятия и определения
- •1. 2. Модели данных
- •1.2.1. Иерархическая модель данных
- •1.2.2. Сетевая модель данных
- •1.2.3. Реляционная модель данных Основные определения
- •Типы связей между отношениями
- •1.3. Классификация баз данных
- •1.4. Цели проектирования баз данных
- •1.5. Проектирование баз данных с использованием универсального отношения
- •1.5.1. Универсальное отношение
- •1.5.2. Проблемы, вызываемые использованием универсального отношения
- •Проблема вставки
- •Проблемы обновления
- •Проблемы удаления
- •1.5.3. Нормальная форма Бойса -Кодда
- •Функциональные зависимости
- •Возможный ключ и детерминант
- •Общий подход к декомпозиции
- •Анализ исходных аномалий
- •1.5.4. Возможные потери фз при декомпозиции
- •1.5.5. Избыточные функциональные зависимости
- •Приемы удаления избыточных фз
- •Минимальное покрытие
- •Модернизированный алгоритм проектирования бд
- •1.5. Метод er - проектирования
- •1.5.1. Сущности и связи
- •1.5.2. Степень связи
- •1.5.3. Переход от диаграмм er – типа к отношениям
- •Предварительные отношения для бинарных связей степени 1:1
- •Предварительные отношения для бинарных связей степени 1:n.
- •Предварительные отношения для бинарных связей степени n:m
- •1.5.4. Дополнительные конструкции, используемые в er - методе
- •Необходимость связей более высокого порядка
- •Предварительные отношения для трехсторонних связей
- •Использование ролей
- •1.5.5. Последовательность проектирования бд при использовании er- метода
- •1.5.5. Проверка отношений на завершающейся фазе проектирования
- •1.7. Другие нормальные формы
- •Часть 2. Специальные аспекты работы с базами данных
- •2.1. Защита данных в базе
- •2.2.1. Общие вопросы защиты данных
- •2.2.2. Реализация защиты данных в различных системах
- •Управление доступом в sql
- •Реализация системы защиты в ms sql Server
- •2.2. Обеспечение целостности данных
- •2.3. Организация параллельных процессов обработки данных
- •2.4. Восстановление бд
- •2.4.1. Уровни восстановления.
- •2.4.2. Восстановление и логический элемент работы
- •Требования к лэр
- •2.4.3. Промежуточное восстановление
- •2.4.4. Длительное восстановление
- •2.5. Математический аппарат, используемый при работе с реляционной базой данных
- •2.5.1. Теоретико-множественные операции реляционной алгебры
- •2.5.2. Специальные операции реляционной алгебры
- •Часть 3. Разработка приложений для работы с базами данных
- •3.1. Краткий обзор субд
- •3.2. Субд Access
- •3.2.1. Вводные замечания
- •3.2.2. Создание базы данных
- •3.2.3. Создание и работа с таблицами
- •3.2.4. Работа с запросами
- •3.2.5. Создание форм
- •3.2.5. Отчеты в Access
- •3.2.7. Макросы в Access
- •Преобразование макросов в программы на Visual Basic
- •3.2.8. Работа с внешними данными
- •3.3. Программирование в Access
- •3.3.1. Вводные замечания
- •3.3.2. Объявление переменных
- •3.3.3. Константы
- •3.3.4. Тип данных Variant
- •3.3.5. Пользовательские типы данных
- •3.3.5.Операторы, команды и выражения в vba
- •3.3.7. Процедуры vba
- •3.3.8. Управляющие структуры в vba
- •Работа с управляющими структурами
- •3.3.9. Объекты в Access
- •3.3.10. Классы в Access
- •3.3.11. Работа с ошибками в vba
- •3.4.Работа в ms sql –Server
- •3.4.1. Основные количественные показатели системы sql-сервер
- •3.4.2. Создание баз данных
- •3.4.3. Создание таблицы
- •3.4.4. Извлечение данных
- •3.4.5. Добавление данных
- •3.4.5. Изменение данных
- •3.4.7. Удаление данных
- •Цитированная литература
- •Оглавление
- •Часть 1. Проектирование баз данных 3
- •Часть 2. Специальные аспекты работы с базами данных 70
- •Часть 3. Разработка приложений для работы с базами данных 113
2.3. Организация параллельных процессов обработки данных
Наглядным примером автоматизированных систем, в которых над базой данных требуется параллельно выполнять ряд процессов обработки, являются системы продажи авиа- или железнодорожных билетов. В этих системах к общей БД одновременный доступ имеют многие операторы, работающие в различных транспортных агентствах, но выполняющие одни и те же функции по продаже билетов пассажирам. Так как оператор не только читает данные из БД (поиск свободных мест на требуемые рейсы), но и вносит изменения в базу (отмечает проданные места, отмечает возвращенные билеты), то необходимо принимать специальные меры для исключения возможности продажи билетов на одно и то же место нескольким пассажирам.
Если бы выполнялись только операции чтения данных из БД, и не было никаких операций записи данных, то проблемы с организацией параллельных процессов обработки над одними и теми же данными не существовало бы. В таком случае следует максимально стремиться к использованию параллелизма а работе системы, чтобы повысить ее производительность. Примером подобных систем служит любая информационно-справочная система, в которой пользователям разрешен только режим чтения данных из БД и в период, когда работают пользователи, никаких изменений данных не производится.
Однако как только пользователи получают возможность выполнять операции изменения одних и тех же данных в БД, ситуация изменяется. Вернемся к системе продажи билетов. Например, три различных оператора, находясь в различных транспортных агенствах города, одновременно запросили один билет до Москвы на 1 февраля, в поезде N 351, в купейном вагоне. В этом случае будет независимо друг от друга выполнено три процесса (транзакции). Транзакция - это разовое выполнение некоторой программы (программа может быть сложной прикладной, выраженной на одном из языков программирования, а может быть реализацией простого запроса, выраженного на языке запросов системы).
Независимо от того, выполняется ли несколько независимых прогонов одной и той же программы или выполняется независимо несколько различных программ, каждая из самостоятельных реализаций самой программы считается отдельной транзакцией. Если в период выполнения этих трех транзакций в БД не поступало от других операторов системы изменений (именно на этот поезд, на это число, на места в купированных вагонах), то, поскольку трижды выполняется одна и та же программа, будет получено три одинаковых ответа. Если места удовлетворяют пассажиров, то каждый оператор посылает в систему сообщение, что место продано (будет также выполнено три транзакции, но уже другой программы, которая проставляет "месту" признак, что оно продано, т.е. первая транзакция поставит признак, а две другие его повторят).
Решение этой проблемы заключается в недопущении параллельного исполнения двух и более транзакций, в которых выполняется чтение и изменение одних и тех же данных.
Блокировки. Решение задачи защиты данных при параллельном доступе заключается во введение блокировок для доступа к данным. Прежде чем прочитать некоторое данное X, транзакция T1 обязана его заблокировать: УСТАНОВИТЬ - БЛОКИРОВКУ X. Блокировка предотвращает доступ к этому данному другой транзакции Т2. Транзакция Т2 должна ждать, пока транзакция T1 не закончит работу с данным Х и не разблокирует его: СНЯТЬ -БЛОКИРОВКУ X. Если некоторая транзакций пытается блокировать уже блокированный элемент, она становится в очередь на ожидание, пока блокировка с этого элемента данных не будет снята.
Для реализации механизма блокировок база разбивается структурно на элементы, которые можно блокировать. Выбор характера и размера элементов, подлежащих блокированию, выполняется исходя из специфики решаемых системой функциональных (прикладных) задач. Выбор больших по размеру элементов, подлежащих блокированию (например, отношений), снижает расходы ресурсов по поддержанию блокировок, однако снижает также и возможности параллельного исполнения процессов. Выбор малых по размеру элементов, подлежащих блокированию (например, кортежей или даже атрибутов), увеличивает возможности системы с точки зрения параллельного исполнения транзакций, однако увеличивает и затраты ресурсов системы на поддержание блокировок.
Модели блокировок. Для блокировки могут использоваться простая модель и модель с блокировкой для чтения и записи. Рассмотрим эти модели.
Простая модель. В данной модели не вводится различие блокировок для операции чтения или операции записи элемента X. Установление блокировки предотвращает доступ к элементу X от других транзакций как по операции чтения, так и по операции записи до тех пор, пока этот элемент не будет разблокирован.
Модель с блокировками для чтения и записи. В данной модели имеется два вида доступа к элементу X: доступ только для чтения, доступ для чтения и записи. Соответственно различают два типа команд блокировки.
1. Команда блокировки элемента Х по чтению. Транзакция, в которой требуется выполнить только чтение элемента X, осуществляет его блокировку по чтению. Блокировка по чтению запрещает любой другой транзакции выполнять запись нового значения элемента X, пока он не будет разблокирован. Блокировку элемента Х по чтению могут одновременно устанавливать несколько транзакций (т.е. допускается параллельная работа по чтению данных для нескольких транзакций).
2. Команда блокировки элемента Х по записи. Команда блокировки по записи соответствует команде блокировки в простой модели, т.е. предотвращается доступ к элементу Х от других транзакций по чтению и по записи. Если некоторая транзакция установила блокировку элемента Х по записи, то никакая другая транзакция не сможет его заблокировать ни по записи, ни по чтению. Блокировка по чтению и блокировка по записи снимается одной командой; СНЯТЬ - БЛОКИРОВКУ X. В модели допускается, что транзакция может вначале устанавливать блокировку элемента X по чтению, а затем блокировку элемента X по записи.
Ожидание и тупики. При использовании механизма блокировок сталкиваются с такими двумя нежелательными явлениями, как бесконечные ожидания и тупиковые ситуации.
Бесконечные ожидания могут, при определенных условиях, появится в любой системе с параллельным выполнением процессов. Например, элемент Х заблокирован выполняющейся транзакцией T1. Поступившая в систему транзакция Т2, которой необходима работа с этим элементом, переходит в состояние ожидания. В момент разблокировки элемента Х транзакцией T1, в систему поступает транзакция Т3, которой также требуется элемент Х и перехватывает инициативу по его блокировке и т.д. В таких условиях не исключена возможность, что транзакция Т2 будет все время находится в состоянии ожидания. Чтобы избежать бесконечного ожидания, система блокировок должна регистрировать все поступившие запросы и предоставлять им возможность блокировок требуемых элементов по правилу “первый вошел - первый обслуживается”.
Для пояснения тупиковой ситуации рассмотрим алгоритм двух программ П1 и П2.
Программа П1
1 шаг - войти в программу;
2 шаг - установить блокировку А;
3 шаг - читать А;
4 шаг - установить блокировку В;
5 шаг - читать В;
5 шаг - выполнить совместную обработку А и В;
7 шаг - писать А;
8 шаг - снять блокировку с А;
9 шаг - писать В;
10 шаг - сиять блокировку с В;
11 шаг - выйти из программы.
Программа П2
1 шаг - войти в программу;
2 шаг - установить блокировку В;
3 шаг - читать В;
4 шаг - установить блокировку А;
5 шаг - читать А;
5 шаг - установить блокировку С;
7 шаг - читать С;
8 шаг - выполнить совместную обработку А, В и С;
9 шаг - писать В;
10 шаг - снять 5локировку с В;
11 шаг - писать А;
12 шаг - с н я т ь б л о к и р о в к у с А;
13 шаг - писать С;
14 шаг - снять блокировку с А;
15 шаг - выйти из программы.
При попытке параллельного исполнения двух транзакций Т1 - выполнение программы П1, а Т2 - выполнение программы П2, они заблокируют друг друга и возникнет тупиковая ситуация. Вначале Т1 заблокирует элемент А, а Т2 - элемент В. Здесь никаких осложнений нет, элементы различны и система разрешает транзакциям Т1 и Т2 выполняться параллельно. Закончив 3-й шаг, транзакции Т1 и Т2 перейдут в состояние ожидания: транзакция T1 будет ждать разблокировки элемента В, заблокированного транзакцией Т2; транзакция Т2 будет ждать разблокировки элемента А, заблокированного транзакцией Т1. Ни одна транзакция не может продолжаться из-за блокировок общих элементов. Это и есть тупиковая ситуация.
Существуют следующие подходы к разрешению тупиковых ситуаций.
1.Выполняется линейное упорядочение элементов по любому принципу (например, последовательно перечислить все элементы БД, подлежащих блокированию) и вводится системное требование на составление программ, т.е. все программы должны выполнять блокировки в определенном порядке. Все транзакции будут запрашивать блокировки в соответствии с принятой, единой для всех упорядоченностью элементов, что предотвратит тупики.
2.Вводится системное требование, чтобы в каждой программе все блокировки запрашивались сразу. Каждая транзакция будет единовременно запрашивать все необходимые ей блокировки. Это позволит СУБД выполнять управление транзакциями без тупиковых ситуаций.
3. Не вводится никаких системных требований на написание программ. В этом случае СУБД следит за возникновением тупиковых ситуаций. При обнаружении тупика действие одной из транзакций аннулируется, все выполненные ею изменения в БД устраняются. Транзакция переводится в состояние ожидания, и через некоторое время выполняется ее рестарт или полностью аннулируется. Чтобы выполнить рестарт или аннулирование транзакции, СУБД фиксирует транзакцию, записывая для каждой транзакции ее идентификатор, все произведенные ею вычисления, время начала и завершения. Такая информация позволяет в случае системного сбоя выполнить также рестарт всех зафиксированных транзакций, которые не успели успешно завершиться.