Объектно–ориентированная модель 2 страница

Отношения находятся во второй нормальной форме, если все его неключевые атрибуты зависят от всего ключа. В соответствии с этим определением, если отношение имеет в качестве ключа одиночный атрибут, то оно автоматически находится во второй нормальной форме. Поскольку ключ является одиночным атрибутом, то по умолчанию каждый неключевой атрибут зависит от всего ключа, и частичных зависимостей не может быть.
Рассмотрим следующий пример схемы отношения:
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ
(СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР -> ОТД_НОМЕР
ОТД_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН
Как видно, хотя первичным ключом является составной атрибут СОТР_НОМЕР, ПРО_НОМЕР, атрибуты СОТР_ЗАРП и ОТД_НОМЕР функционально зависят от части первичного ключа, атрибута СОТР_НОМЕР. В результате мы не сможем вставить в отношение СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ кортеж, описывающий сотрудника, который еще не выполняет никакого проекта (первичный ключ не может содержать неопределенное значение). При удалении кортежа мы не только разрушаем связь данного сотрудника с данным проектом, но утрачиваем информацию о том, что он работает в некотором отделе. При переводе сотрудника в другой отдел мы будем вынуждены модифицировать все кортежи, описывающие этого сотрудника, или получим несогласованный результат. Такие неприятные явления называются аномалиями схемы отношения. Они устраняются путем нормализации.
Вторая нормальная форма (в этом определении предполагается, что единственным ключом отношения является первичный ключ)
Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда находится в 1NF, и каждый неключевой атрибут полностью зависит от первичного ключа.
Можно произвести следующую декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР -> ОТД_НОМЕР
ОТД_НОМЕР -> СОТР_ЗАРП
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
Каждое из этих двух отношений находится в 2NF, и в них устранены отмеченные выше аномалии (легко проверить, что все указанные операции выполняются без проблем).
Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда оно находится в 1NF, и каждый неключевой атрибут полностью зависит от каждого ключа R.
Здесь и далее мы не будем приводить примеры для отношений с несколькими ключами. Они слишком громоздки и относятся к ситуациям, редко встречающимся на практике.

Отношения находятся в третьей нормальной, если оно находится во второй нормальной форме и не имеет транзитивных зависимостей.
Транзитивная зависимость – неключевой атрибут функционально зависит от неключевых атрибутов. (транзитивная зависимость – если атрибут В зависит от атрибута А, а атрибут С зависит от атрибута В, то атрибут С транзитивно зависит от атрибута А).
Отношения в данной таблице также содержит транзитивную зависимость. Номер студента определяет атрибут Секции, а Секции определяет атрибут Плата, Поэтому отношения данной таблицы не находится в третьей нормальной форме. Разбиение этой таблицы на две таблицы устраняет аномалии.
Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся в 2NF. Заметим, что функциональная зависимость СОТР_НОМЕР -> СОТР_ЗАРП является транзитивной; она является следствием функциональных зависимостей СОТР_НОМЕР -> ОТД_НОМЕР и ОТД_НОМЕР -> СОТР_ЗАРП. Другими словами, заработная плата сотрудника на самом деле является характеристикой не сотрудника, а отдела, в котором он работает (это не очень естественное предположение, но достаточное для примера).
В результате мы не сможем занести в базу данных информацию, характеризующую заработную плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первичный ключ не может содержать неопределенное значение). При удалении кортежа, описывающего последнего сотрудника данного отдела, мы лишимся информации о заработной плате отдела. Чтобы согласованным образом изменить заработную плату отдела, мы будем вынуждены предварительно найти все кортежи, описывающие сотрудников этого отдела. Т.е. в отношении СОТРУДИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Их можно устранить путем дальнейшей нормализации.
Третья нормальная форма. (Снова определение дается в предположении существования единственного ключа.)
Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 2NF и каждый неключевой атрибут нетранзитивно зависит от первичного ключа.
Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два отношения СОТРУДНИКИ и ОТДЕЛЫ:
СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> ОТД_НОМЕР
ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП)
Первичный ключ:
ОТД_НОМЕР
Функциональные зависимости:
ОТД_НОМЕР -> СОТР_ЗАРП
Каждое из этих двух отношений находится в 3NF и свободно от отмеченных аномалий.
Если отказаться от того ограничения, что отношение обладает единственным ключом, то определение 3NF примет следующую форму:
Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если находится в 1NF, и каждый неключевой атрибут не является транзитивно зависимым от какого-либо ключа R.
На практике третья нормальная форма схем отношений достаточна в большинстве случаев, и приведением к третьей нормальной форме процесс проектирования реляционной базы данных обычно заканчивается. Однако иногда полезно продолжить процесс нормализации.

Отношения находятся в НФБК, если каждый детерминант является ключом-кандидатом (А®В)
Два или более атрибута или группы атрибутов, которые могут быть ключом, называются ключами-кандидатами. Тот из ключей-кандидатов, который выбирается в качестве ключа называется первичным ключом.
Рассмотрим следующий пример схемы отношения:
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ИМЯ, ПРО_НОМЕР, СОТР_ЗАДАН)
Возможные ключи:
СОТР_НОМЕР, ПРО_НОМЕР
СОТР_ИМЯ, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> CОТР_ИМЯ
СОТР_НОМЕР -> ПРО_НОМЕР
СОТР_ИМЯ -> CОТР_НОМЕР
СОТР_ИМЯ -> ПРО_НОМЕР
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
СОТР_ИМЯ, ПРО_НОМЕР -> CОТР_ЗАДАН
В этом примере мы предполагаем, что личность сотрудника полностью определяется как его номером, так и именем (это снова не очень жизненное предположение, но достаточное для примера).
В соответствии с определением отношение СОТРУДНИКИ-ПРОЕКТЫ находится в 3NF. Однако тот факт, что имеются функциональные зависимости атрибутов отношения от атрибута, являющегося частью первичного ключа, приводит к аномалиям. Например, для того, чтобы изменить имя сотрудника с данным номером согласованным образом, нам потребуется модифицировать все кортежи, включающие его номер.
Детерминант - любой атрибут, от которого полностью функционально зависит некоторый другой атрибут.
Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в том и только в том случае, если каждый детерминант является возможным ключом.
Очевидно, что это требование не выполнено для отношения СОТРУДНИКИ-ПРОЕКТЫ. Можно произвести его декомпозицию к отношениям СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ)
Возможные ключи:
СОТР_НОМЕР
СОТР_ИМЯ
Функциональные зависимости:
СОТР_НОМЕР -> CОТР_ИМЯ
СОТР_ИМЯ -> СОТР_НОМЕР
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Возможный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
Возможна альтернативная декомпозиция, если выбрать за основу СОТР_ИМЯ. В обоих случаях получаемые отношения СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ находятся в BCNF, и им не свойственны отмеченные аномалии.

Одному и тому же значению атрибута Номер студента может соответствовать много значений атрибута Специальность. Помимо того, одному и тому значению атрибута Номер студента может соответствовать много значений атрибута Секция.
Такая зависимость атрибутов называется многозначной зависимостью (каждому значению атрибута А соответствует множество значений атрибута В, несвязанное с другим атрибутом из этого же отношения). Многозначные зависимости приводят к аномалиям модификации.
Рассмотрим пример следующей схемы отношения:
ПРОЕКТЫ (ПРО_НОМЕР,ПРО_СОТР, ПРО_ЗАДАН)
Отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта список сотрудников, которые могут выполнять проект, и список заданий, предусматриваемых проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания.
Каждый кортеж отношения связывает некоторый проект с сотрудником, участвующим в этом проекте, и заданием, который сотрудник выполняет в рамках данного проекта (мы предполагаем, что любой сотрудник, участвующий в проекте, выполняет все задания, предусмотренные этим проектом). По причине сформулированных выше условий единственным возможным ключем отношения является составной атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и нет никаких других детерминантов. Следовательно, отношение ПРОЕКТЫ находится в BCNF. Но при этом оно обладает недостатками: если, например, некоторый сотрудник присоединяется к данному проекту, необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько заданий в нем предусмотрено.
Многозначные зависимости. В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.
В отношении ПРОЕКТЫ существуют следующие две многозначные зависимости:
ПРО_НОМЕР -> -> ПРО_СОТР
ПРО_НОМЕР -> -> ПРО_ЗАДАН
Легко показать, что в общем случае в отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, когда существует многозначная зависимость R.A -> -> R.C.
Дальнейшая нормализация отношений, подобных отношению ПРОЕКТЫ, основывается на следующей теореме:
Теорема Фейджина
Отношение R (A, B, C) можно спроецировать без потерь в отношения R1 (A, B) и R2 (A, C) в том и только в том случае, когда существует MVD A -> -> B | C.
Под проецированием без потерь понимается такой способ декомпозиции отношения, при котором исходное отношение полностью и без избыточности восстанавливается путем естественного соединения полученных отношений.
Четвертая нормальная форма. Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости A -> -> B все остальные атрибуты R функционально зависят от A.
В нашем примере можно произвести декомпозицию отношения ПРОЕКТЫ в два отношения ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ:
ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН)
Оба эти отношения находятся в 4NF и свободны от отмеченных аномалий.

Пятая нормальная форма связана с зависимостями, которые имеют несколько неопределенный характер. Речь здесь идет об отношениях, которые можно разделить на несколько более мелких отношений, как мы делали выше, но затем невозможно восстановить.
Рассмотрим, например, отношение
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, ОТД_НОМЕР, ПРО_НОМЕР)
Предположим, что один и тот же сотрудник может работать в нескольких отделах и работать в каждом отделе над несколькими проектами. Первичным ключем этого отношения является полная совокупность его атрибутов, отсутствуют функциональные и многозначные зависимости.
Поэтому отношение находится в 4NF. Однако в нем могут существовать аномалии, которые можно устранить путем декомпозиции в три отношения.
Зависимость соединения Отношение R (X, Y,..., Z) удовлетворяет зависимости соединения * (X, Y,..., Z) в том и только в том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y,..., Z.
Пятая нормальная форма. Отношение R находится в пятой нормальной форме (нормальной форме проекции-соединения - PJ/NF) в том и только в том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R.
Введем следующие имена составных атрибутов:
СО = {СОТР_НОМЕР, ОТД_НОМЕР}
СП = {СОТР_НОМЕР, ПРО_НОМЕР}
ОП = {ОТД_НОМЕР, ПРО_НОМЕР}
Предположим, что в отношении СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ существует зависимость соединения:
* (СО, СП, ОП)
На примерах легко показать, что при вставках и удалениях кортежей могут возникнуть проблемы. Их можно устранить путем декомпозиции исходного отношения в три новых отношения:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, ОТД_НОМЕР)
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР)
ОТДЕЛЫ-ПРОЕКТЫ (ОТД_НОМЕР, ПРО_НОМЕР)
Пятая нормальная форма - это последняя нормальная форма, которую можно получить путем декомпозиции. Ее условия достаточно нетривиальны, и на практике 5NF не используется. Заметим, что зависимость соединения является обобщением как многозначной зависимости, так и функциональной зависимости.

ДКНФ – нормальная форма, которая свободна от аномалий любого типа. Когда мы приводим отношения к этой форме, мы знаем, что в этом случае даже скрытые аномалии, связанные с пятой нормальной формой, возникнуть не могут.
В 1981г. Фагин опубликовал статью, в которой он определил доменно–ключевую нормальную форму. Он показал, что отношение в ДКНФ не имеет аномалий модификации и, любое отношение, не имеющее аномалий модификации, должно находиться в ДКНФ. Это открытие положило конец введению нормальных форм, и теперь в нормальных формах более высокого порядка нет необходимости.
Определение доменно–ключевой нормальной формы затрагивает понятия домена и ключа – понятия фундаментальные и близкие сердцу специалиста в области базы данных.
Ключ – это уникальный идентификатор кортежа.
Домен – это описание допустимых значений атрибута. Он состоит из двух частей: физического описания и семантического, или логического, описания. Физическое описание – это множество значений, которые может принимать атрибут, а логическое описание – это смысл данного атрибута.
В настоящее время не существует не одного алгоритма приведения произвольного отношения к ДКНФ. Неизвестно также, какое отношение может быть приведено к этой форме.

Манипулирование реляционными данными. Реляционная алгебра

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

Отношение ТРЕТИКУРСНИК и ПОЧЕТНЫЙ СТУДЕНТ: а - пример отношения ТРЕТИКУРСНИК; б - пример отношения ПОЧЕТНЫЙ СТУДЕНТ.
Объединение (А+В) – это комбинирование картежей одного отношения с картежами другого отношения, в результате чего получается третье отношение. Порядок, в котором следуют картежи в результирующем отношении, несущественен, но повторяющиеся строки должны быть удалены.
Чтобы данная операция имела смысл, отношения должны быть совместимы по объединению, т.е. оба отношения должны иметь одинаковое количество атрибутов, и атрибуты в соответствующих столбцах должны принадлежать одному и тому же домену.

Разность (А-В) – это отношение, содержащее все кортежи, которые присутствуют в первом отношении, но не присутствуют во втором. Отношения должны быть совместимы по объединению. А-В не равняется В-А.

Пересечение – это отношение, содержащее кортежи, которые присутствуют и в первом и во втором отношениях. Отношения должны быть совместимы по объединению.

Произведение (декартово произведение) – это парная конкатенация всех строк одного отношения со всеми строками другого.

Произведение отношений СТУДЕНТ и ЗАПИСЬ
Проектирование (проекция) – это операция, которая выделяет заданные атрибуты отношения. Результатом проектирования является новое отношение, содержащее выбранные атрибуты. При проектировании могут возникнуть избыточные кортежи, ихи необходимо исключать.
Проекция отношения СТУДЕНТ [Имя, Специальность]

Выборка. Выборка выделяет горизонтальное подмножество (строки). Проектирование указывает, какие атрибуты должны быть в новом отношении, а выборка указывает, какие строки должны в нем присутствовать. Обозначается выборка путем указания имени отношения, за которым следует ключевое слово WHERE, за которым идет условие, накладываемое на атрибуты.

Выборка СТУДЕНТ WHERE Специальность = 'МАТЕМАТИКА'
Соединение. Операция соединения представляет собой комбинацию произведения, выборки и (возможно) проектирования. Бывают эквивалентное соединение (допускает наличие в результирующем отношении двух одинаковых столбцов), естественное соединение (не допускает наличие в результирующем отношении двух одинаковых столбцов) и Тетта - соединение (соединение двух отношений осуществляется, если выполняется заданное условие Тетта).

Классификация приложений для работы с базами данных Традиционно приложений для работы с базами данных делятся на локальные приложения и приложения в архитектуре клиент/сервер, которые в свою очередь подразделяются на клиентские и сер-верные составляющие. (Локальными называются программы, расположенные на одном компьютере с базой данных.) Иногда база данных может располагаться на фиксированном сетевом диске в локальной сети. Программа называется соответствующей архитектуре клиент/сервер, если она имеет мощный сервер БД, отвечающий за обработку поступающих запросов и передачу результата клиентам. Клиентское программное обеспечение чаще всего располагается на удаленных рабочих местах, в сетях, требующих отдельного администрирования. Схема проектирования приложения выглядит следующим образом: Сбор информации. Необходимо знать все, что хотят пользователи, заказчик или руководство от этой системы. Принято разделять программистов-аналитиков, проектирующих систему, от просто - программистов, пишущих код, и тем более различать администраторов и разработчиков БД. Выбор платформы. Включает в себя как выбор аппаратных средств, в соответствии с планируемой нагрузкой на БД с учетом масштабируемости, так и выбор СУБД. Существует множество критериев, и для каждого они свои. Для кого-то важна цена/бесплатность продукта, для кого-то производительность. Однако нужно реально оценивать возможности СУБД. Добавляются к этому затраты на администрирование БД. Грамотное проектирование структуры БД с максимальным вынесением логики работы на уровень сервера БД. Зачем делать лишнюю работу на клиенте, если она лучше и быстрее сделается на сервере. Плюс унифицированность системы. Чем грамотней и продуманней начальная структура БД, тем меньше проблем мы получаем на следующих этапах. Да и расходы на поддержку существенно уменьшаются. Собственно проектирование и разработка интерфейса к БД. Тут существует обратно-пропорциональная зависимость: чем универсальнее программное средство, тем тяжелей оно в понимании и эксплуатации. Пользователю надо дать интерфейс, причем интерфейс довольно узкоспециализированный. Т.е. всё должно быть настолько просто, насколько это вообще возможно. Причем, в большинстве своем пользователи хотят, чтобы все делалось при их минимальном участии. Если это возможно, то можно совместить разработчика БД с программистом. Если в силу особой сложности проекта или иных технических причин эта невоз-можно, то программист должен максимально тесно контактировать с разработчиком БД и ясно для себя представлять ее структуру.

Управление обработкой информации в многопользовательских базах данных. Параллельная обработка транзакций

Управление параллельной обработкой Меры по управлениюпараллельной обработкой нацелены на предотвращение непредусмотренного влияния одного пользователя на действия другого. Например, пользователь, который ввел свой заказ в компьютерную систему, должен получить один и тот же результат независимо от того, сколько еще есть пользователей кроме него. К сожалению, не существует способа управления параллельной обработкой, который бы одинаково хорошо подходил бы для всех ситуаций. Все эти способы предполагают некоторый компромисс. Например, пользователь может весьма жестко управлять параллельной обработкой, заблокировав всю базу данных, но пока будут обрабатываться данные для этого пользователя, ни один другой пользователь не сможет ничего сделать. Такая защита надежна, но дорога. Необходимость в атомарных транзакциях В большинстве приложений баз данных работа пользователей организована в форме транзакций. Транзакции – это последовательность действий с базой данных, в которой либо все действия выполняются успешно, либо не выполняется ни одно из них (в последнем случае база данных остается без изменений). Такая транзакция называется атомарной, поскольку она выполняется как единое целое. Параллельная обработка транзакций Когда в одно и тоже время происходит обработка двух транзакций с базой данных, эти транзакции называются параллельными транзакциями. Обычно транзакции выполняются попеременно, т.е. операционная система переключает процессор между несколькими задачами, так что за заданный промежуток времени выполняется некоторая часть каждой из них. Это переключение происходит столь быстро, что два человека, сидящие бок о бок перед двумя компьютерами, обрабатывающими одну и туже базу данных, могут подумать, что их транзакции выполняются одновременно. Проблема потерянного обновления Предположим, что два пользователя хотят обратиться к одному и тому же элементу. Например, пользователь А хочет заказать пять единиц товара 100, а пользователь В – три единицы этого же товара. Всего имеется 10 единиц товара 100. Пользователь А считывает запись о товаре 100 в свою рабочую область. В соответствии с этой записью в наличие имеется 10 единиц товара. Затем пользователь В читает запись о товаре 100 в свою рабочую область. Согласно этой записи имеется 10 единиц товара. Теперь пользователь А берет 5 единиц товара, уменьшает количество товара в свой рабочей области до пяти и обновляет запись для товара 100. после этого пользователь В берет три единицы товара, уменьшает количество товара в своей рабочей области до 7 единици записывает это количество в базу данных. Теперь база данных ошибочно показывает, что в наличии имеется 7 единиц товара 100. Блокировка ресурсов Один из способов предотвратить проблемы при параллельной обработке – запретить совместное использование ресурсов путем блокировки данных, которые считываются для обновления. Из – за блокировки транзакция пользователь В должна ждать, пока пользователь А не закончит работу с данными по товару 100. Блокировки могут налагаться как автоматически, по инициативе СУБД, так и командой, которая передается СУБД прикладной программой или запросом пользователя. Блокировки налагаемые СУБД, называются неявными блокировками, а блокировки, налагаемые по команде, - явными блокировками. При монопольной блокировке блокируются все виды доступа к элементу. Ни одна другая транзакция не может читать или изменять данные. Коллективная блокировка блокирует элемент от изменения, но не от чтения. То есть другая транзакция может свободно читать данный элемент, если они не пытаются изменить его. Сериализуемые транзакции Когда две или более транзакции обрабатываются параллельно, их результаты, сохраняемые в базе данных, должны быть логически согласованы с результатами, которые получились бы, если бы данные транзакции обрабатывались каким-нибудь последовательным способом. Такая схема обработки параллельных транзакций называется сериализуемой. Сериализуемость может быть достигнута несколькими способами. Один из способов – обработка транзакций с использование двухфазной блокировки. При этой стратегии транзакциям разрешается налагать блокировки по мере необходимости, но как только первая блокировка снимается, данная транзакция не может наложить никаких других блокировок. Таким образом, транзакции имеют фазу нарастания, на которой блокировки налагаются, и фазу сжатия, на которой блокировки снимаются. Взаимная блокировка Решая одну проблему блокировка способна вызвать другую. Предположим, что пользователь А хочет заказать бумагу, а если он сможет достать бумагу, то он закажет и карандаши. Теперь предположим, что пользователь В хочет заказать карандаши, а если удастся достать карандаши, то он закажет и бумагу. Пользователь А и В оказываются в ситуации, которая называется взаимная блокировка. Каждый из них ожидает освобождения ресурса, заблокированного другим пользователем. Есть два способа разрешения этой проблемы: не допускать возникновения взаимных блокировок либо позволять им возникать, а затем распутывать их. Предотвратить возникновения взаимной блокировки можно несколькими способами. Первый из них – заставлять пользователей блокировать все требуемые ресурсы сразу. Второй способ – требовать от всех прикладных программ блокировать ресурсы в одном и том же порядке. Почти в каждой СУБД имеются алгоритмы обнаружения взаимной блокировки. Когда происходит взаимная блокировка, обычное решение состоит в том, чтобы отменить одну из транзакций, тем самым удалив из базы данных произведенные ею изменения. Оптимистическая и пессимистическая блокировки Блокировки могут налагаться двумя основными стилями. При оптимистической блокировке делается предположение, что конфликта не произойдет. Данные считываются, транзакция обрабатывается, производятся обновления, а после этого делается проверка, не возник ли конфликт. Если нет, транзакция завершается. Если да, транзакция повторяется до тех пор, пока не сможет успешно завершиться. При пессимистической блокировке предполагается, что конфликт обязательно произойдет. Сначала налагаются блокировки, затем обрабатывается транзакция, а после этого блокировки снимаются. Уровень изоляции Блокировки предотвращают потерю изменений при параллельной обработке. Тем не менее, существует ряд проблем, которые они предотвратить не в состоянии. Одной из таких проблем является «грязное чтение» - чтение транзакций записи, которая изменена, но еще не записана в базе данных. Это может произойти например, когда одна транзакция считывает строку, измененную другой незавершенной транзакцией, а эта другая транзакция впоследствии отменяется. «Невоспроизводимое чтение» - это ситуация, когда при повторном чтении данных, уже считанных ранее, транзакция обнаруживает модификации или удаления произведенные другой завершенной транзакцией. «Фантомное чтение» - это ситуация, когда при повторном чтении данных транзакция обнаруживает новые строки, вставленные другой завершенной транзакцией после предыдущего чтения. В стандарте SQL 1992 г. Определены четыре уровня изоляции транзакций, которые определяют допустимость перечисленных выше проблем. Цель состоит в том, чтобы разработчик прикладной программы мог указать желаемый уровень изоляции, а СУБД осуществляла бы управление блокировками в соответствии с этими указаниями.

Как можно увидеть на данном рисунке уровень изоляции под названием «незавершенное чтение» допускает «грязное чтение», невоспроизводимое и фантомное чтение. Уровень изоляции «завершенное чтение» предотвращает «грязное чтение». Уровень изоляции «воспроизводимое чтение» предотвращает «грязное чтение» и невоспроизводимое чтение. Уровень изоляции «сериализуемость» не допускает возникновения ни одной из этих проблем.

Архитектуры организационных систем обработки данных. Системы удаленной обработки. клиент–серверные системы. Системы совместного использования файлов