Вторая нормальная форма

О таблице говорят, что она находится во второй нормальной форме , если:

1. Если она удовлетворяет условиям первой нормальной формы

2. Любое не ключевое поле однозначно идентифицируется полным набором ключевых полей

Покупатели

Код Покупателя

Предприятие

Фамилия

Имя

Отчество

Индекс

Страна

Область

Город

Адрес

Кредит

Дополнительные сведения

Заказы

Номер

Код

Дата

Код менеджера

Имя менеджера

Продано

Номер

Код

Заказанное количество

Проданное количество

Дата продажи

Примечание

Телефоны

Код покупателя

Телефонная книга

Товары

Код товара

Наименование

Группа товара

Цена

Менеджер

Код менеджера

Имя менеджера

О таблице говорят, что она находится в третьей нормальной форме, если: 1) удовлетворяет условиям второй нормальной формы

3. Ни одно из не ключевых полей не идентифицируется с помощью другого не ключевого поля

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

Изолированность пользователей

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

1. Отсутствие потерянных изменений. Рассмотрим следующий сценарий совместного выполнения двух транзакций: Транзакция 1 изменяет объект А базы данных. До завершения транзакции 1транзакция 2 так же изменяет объект 2. Транзакция 2 завершается оператором rollback например по причине нарушения ограничений целостности. Тогда при повторном чтении объекта А транзакция 1не видит изменений этого объекта, произведенных ранее. Такая ситуация называется ситуацией потерянных изменений и она противоречит требованию изолированности пользователей. Чтобы избежать такой ситуации транзакция 1 требуется чтобы до завершения транзакции 1 никакая другая транзакция не могла изменять объект А. Отсутствие потерянных изменений является минимальным требованием к СУБД по части синхронизации параллельно выполняемых транзакций.

2. Отсутствие чтения грязных данных. Рассмотрим следующий сценарий совместного выполнения транзакции 1 и 2. Транзакция 1 изменяет объект А базы данных. Параллельно с этим транзакция 2 читает объект А. Поскольку операция изменения еще не завершена транзакция 2 видит несогласованные грязные данные. Это так же не соответствует изолированности пользователя. Чтобы избежать чтения грязных данных до завершения транзакции 1 изменявшей объект А никакая другая транзакция не должна читать объект А. ( минимальным требованием является блокировка чтения объекта А до завершения операции его изменения транзакции 1).

3. Отсутствие неповторяющихся чтений. рассмотрим следующий сценарий совместного выполнения транзакций 1 и 2. Транзакция 1 читает объект А базы данных. До завершения транзакции 1 транзакция 2 изменяет объект А и успешно завершается оператором commit. Транзакция 1 повторно читает объект А и видит его измененное состояние. Чтобы избежать неповторяющихся чтений до завершения транзакции 1

Существует возможность обеспечения разных уровней изолированности для разных транзакций выполняющихся в одной системе. Для поддержания целостности достаточен первый уровень. При этом удается существенно сократить накладные расходы СУБД и повысить общую эффективность. К более тонким проблемам изолированности транзакций относится так называемая проблема «кортежей-фантомов», вызывающая ситуации, которые так же противоречат изолированности пользователя. Рассмотрим следующий сценарий. Транзакция 1 выполняет оператор А выборки кортежей отношения R с условием выборки S, т.е. выбирает часть кортежей отношения R, удовлетворяющий условию S. До завершения транзакции 1 транзакция 2 выставляет

транщакция 1 повторно выполняет оператор А и в результате появляется кортеж, который отсутствовал при первом выполнении оператора А. Такая ситуация противоречит идее изолированности транзакций и может противоречить изолированности транзакций и может возникнуть даже на 3-м уровне изолированности транзакций. Чтобы избежать появления

Идея такой синхронизации – предикатные синхронизационные захваты. Известные давно, но в большинстве систем не реализованы.