Алгоритм нормализации (приведение к 3нф)

Шаг 1 (Приведение к 1НФ) . На первом шаге задается одно или несколько отношений, отображающих понятия предметной области. По модели предметной области (не по внешнему виду полученных отношений!) выписываются обнаруженные функциональные зависимости. Все отношения автоматически находятся в 1НФ.

Шаг 2 (Приведение к 2НФ) . Если в некоторых отношениях обнаружена зависимость атрибутов от части сложного ключа, то проводим декомпозицию этих отношений на несколько отношений следующим образом: те атрибуты, которые зависят от части сложного ключа выносятся в отдельное отношение вместе с этой частью ключа. В исходном отношении остаются все ключевые атрибуты:

Исходное отношение:  .

Ключ:   - сложный.

Функциональные зависимости:

 - зависимость всех атрибутов от ключа отношения.

 - зависимость некоторых атрибутов от части сложного ключа.

Декомпозированные отношения:

 - остаток от исходного отношения. Ключ  .

 - атрибуты, вынесенные из исходного отношения вместе с частью сложного ключа. Ключ  .

Шаг 3 (Приведение к 3НФ) . Если в некоторых отношениях обнаружена зависимость некоторых неключевых атрибутов других неключевых атрибутов, то проводим декомпозицию этих отношений следующим образом: те неключевые атрибуты, которые зависят других неключевых атрибутов выносятся в отдельное отношение. В новом отношении ключом становится детерминант функциональной зависимости:

Исходное отношение:  .

Ключ:  .

Функциональные зависимости:

 - зависимость всех атрибутов от ключа отношения.

 - зависимость некоторых неключевых атрибутов других неключевых атрибутов.

Декомпозированные отношения:

 - остаток от исходного отношения. Ключ  .

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

Замечание. На практике, при создании логической модели данных, как правило, не следуют прямо приведенному алгоритму нормализации. Опытные разработчики обычно сразу строят отношения в 3НФ. Кроме того, основным средством разработки логических моделей данных являются различные варианты ER-диаграмм. Особенность этих диаграмм в том, что они сразу позволяют создавать отношения в 3НФ. Тем не менее, приведенный алгоритм важен по двум причинам. Во-первых, этот алгоритм показывает, какие проблемы возникают при разработке слабо нормализованных отношений.Во-вторых, как правило, модель предметной области никогда не бывает правильно разработана с первого шага. Эксперты предметной области могут забыть о чем-либо упомянуть, разработчик может неправильно понять эксперта, во время разработки могут измениться правила, принятые в предметной области, и т.д. Все это может привести к появлению новых зависимостей, которые отсутствовали в первоначальной модели предметной области. Тут как раз и необходимо использовать алгоритм нормализации хотя бы для того, чтобы убедиться, что отношения остались в 3НФ и логическая модель не ухудшилась.

8. Нормальная форма Бойса-Кодда. Четвертая нормальная форма. Корректность процедуры нормализации - декомпозиция без потерь. Теорема Хеза.

Эта нормальная форма вводит дополнительное ограничение по сравнению с 3НФ.

Отношение находится в нормальной форме Бойса-Кодда (БКНФ), если оно находится во 3НФ и в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов.

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

Ситуация, когда отношение будет находится в 3NF, но не в BCNF, возникает при условии, что отношение имеет два (или более) возможных ключа, которые являются составными и имеют общий атрибут. Заметим, что на практике такая ситуация встречается достаточно редко, для всех прочих отношений 3NF и BCNF эквивалентны.

Отношение, находящееся в 3НФ, но не в БКНФ допускает аномалии обновления, связанные с изменением значения ключевого поля, зависящего не от потенциального ключа.

Приведение отношения к БКНФ позволяет исключить данный тип аномалий обновления. Более того, отношение в БКНФ позволяет исключить все виды аномалий обновления, связанные с функциональными зависимостями.

Для приведения отношения из 3НФ к БКНФ следует:  а) для каждой ФЗ с детерминантом – не потенциальным ключом, выполнить проекцию на атрибуты, входящие в функциональную зависимость; б) выполнить проекцию на все атрибуты, кроме тех, которые входят в правую часть ФЗ с детерминантом – не потенциальным ключом.

8. Нормальная форма Бойса-Кодда. Четвертая нормальная форма. Корректность процедуры нормализации - декомпозиция без потерь. Теорема Хеза.

Эта нормальная форма вводит дополнительное ограничение по сравнению с 3НФ.

Отношение находится в нормальной форме Бойса-Кодда (БКНФ), если оно находится во 3НФ и в ней отсутствуют зависимости атрибутов первичного ключа от неключевых атрибутов.

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

Ситуация, когда отношение будет находится в 3NF, но не в BCNF, возникает при условии, что отношение имеет два (или более) возможных ключа, которые являются составными и имеют общий атрибут. Заметим, что на практике такая ситуация встречается достаточно редко, для всех прочих отношений 3NF и BCNF эквивалентны.

Отношение, находящееся в 3НФ, но не в БКНФ допускает аномалии обновления, связанные с изменением значения ключевого поля, зависящего не от потенциального ключа.

Приведение отношения к БКНФ позволяет исключить данный тип аномалий обновления. Более того, отношение в БКНФ позволяет исключить все виды аномалий обновления, связанные с функциональными зависимостями.

Для приведения отношения из 3НФ к БКНФ следует:  а) для каждой ФЗ с детерминантом – не потенциальным ключом, выполнить проекцию на атрибуты, входящие в функциональную зависимость; б) выполнить проекцию на все атрибуты, кроме тех, которые входят в правую часть ФЗ с детерминантом – не потенциальным ключом.

Четвертая нормальная форма

Четвертая нормальная форма (4НФ) связана с таким понятием, как многозначная зависимость. Рассмотрим следующий пример. Пусть в таблице хранится информация о поставщиках, заказчиках и магазинах заказчика.

<Поставщик, Заказчик, Магазин>

Поставим условие, что атрибут (Поставщик) никак не зависит от атрибута (Магазин), что вполне логично, так как поставка идет заказчику, а не в магазин. Предположим также, что  данному заказчику может соответствовать произвольное количество поставщиков и магазинов. Заметим, что первичным ключом данной таблицы является совокупность всех ее столбцов, а поэтому она находится в третьей нормальной форме.  Не смотря на это работать с таблицей не удобно. Действительно, если необходимо для данного заказчика добавить нового поставщика, то делать это придется, указав конкретный магазин. Удалить же поставщика можно, только удалив все записи, где он присутствует, что может привести  к удалению и заказчика.

В указанном примере причиной проблем является так называемая многозначная зависимость. Дело в том, что поле (Заказчик) не явно определяет и множество поставщиков, и множество магазинов. Такое отношение называетсямногозначной зависимостью.  И так в нашем случае налицо две многозначные зависимости.  Записывается это так: (Заказчик)->>(Поставщик) и (Заказчик)->>(Магазин).

Четвертая нормальная форма. 

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

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

<Поставщик, Заказчик>  

<Заказчик, Магазин>

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

• Корректность процедуры нормализации. Теорема Хеза;

Предположим, что мы уже имеем работающую систему, в которой накоплены данные. Пусть данные корректны в текущий момент, т.е. факты предметной области правильно отражаются текущим состоянием базы данных. Если в предметной области обнаружена новая функциональная зависимость (либо она была пропущена на этапе моделирования предметной области, либо просто изменилась предметная область), то возникает необходимость заново нормализовать данные. При этом некоторые отношения придется декомпозировать в соответствии с алгоритмом нормализации. При декомпозиции мы из одного отношения получаем два или более отношений, каждое из которых содержит часть атрибутов исходного отношения. В полученных новых отношениях необходимо удалить дубликаты строк, если таковые возникли. Это в точности означает, что декомпозиция отношения есть не что иное, как взятие одной или нескольких проекций исходного отношения так, чтобы эти проекции в совокупности содержали (возможно, с повторениями) все атрибуты исходного отношения. Т.е., при декомпозиции не должны теряться атрибуты отношений. Но при декомпозиции также не должны потеряться и сами данные.  Данные можно считать не потерянными в том случае, если возможна обратная операция - по декомпозированным отношениям можно восстановить исходное отношение в точности в прежнем виде. Операцией, обратной операции проекции, является операция соединения отношений. Имеется большое количество видов операции соединения. Т.к. при восстановлении исходного отношения путем соединения проекций не должны появиться новые атрибуты, то необходимо использовать естественное соединение. Определение 6. Проекция R[X] отношения R на множество атрибутов X называется собственной, если множество атрибутов Xявляется собственным подмножеством множества атрибутов отношения R(т.е. множество атрибутов X не совпадает с множеством всех атрибутов отношения R).  Определение 7. Собственные проекции R1 и R2 отношения R называются декомпозицией без потерь, если отношение R точно восстанавливается из них при помощи естественного соединения для любого состояния отношения R:  R1 JOINR2=R.  Вывод. Таким образом, без дополнительных ограничений на отношение  нельзя говорить о декомпозиции без потерь. Такими дополнительными ограничениями и являются функциональные зависимости. Имеет место следующая теорема Хеза:  Теорема (Хеза). Пусть R(A,B,C) является отношением, и (A,B,C) - атрибуты или множества атрибутов этого отношения. Если имеется функциональная зависимость A→B, то проекции R1=R[A,B] и R2=R[A,C] образуют декомпозицию без потерь. Доказательство. Необходимо доказать, что R1 JOINR2 = R для любого состояния отношения R. В левой и правой части равенства стоят множества кортежей, поэтому для доказательства достаточно доказать два включения для двух множеств кортежей:  R1 JOIN R2 Ê R и R1 JOIN R2 Í  R . Докажем первое включение. Возьмем произвольный кортеж r =(a,b,c)ÎR. Докажем, что он включается также и в R1 JOINR2 . По определению проекции, кортежи  r1 =(a,b)ÎR1 и r2 =(a,c)ÎR2.  По определению естественного соединения кортежи r1 и r2, имеющие одинаковое значение  общего атрибута a, будут соединены в процессе естественного соединения в кортеж (a,b,c)ÎR1 JOINR2. Таким образом, включение доказано. Докажем обратное включение. Возьмем произвольный кортеж r =(a,b,c)ÎR1 JOINR2. Докажем, что он включается также и в R. По определению естественного соединения получим, что имеются кортежи r1 =(a,b)ÎR1 и r2 =(a,c)ÎR2. Т.к. R1=R[A,B] , то существует некоторое значение c1, такое что кортеж r1 =(a,b,c1)ÎR. Аналогично, существует некоторое значение b1, такое что кортеж r2 =(a,b1,c)ÎR. Кортежи r1 и r2 имеют одинаковое значение атрибута A, равное a. Из этого, в силу функциональной зависимости A→B, следует, что b=b1. Таким образом, кортеж r2 =(a,b,c)ÎR. Обратное включение доказано.

9. Понятие транзакции. Свойства транзакции.

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

Различают последовательные (обычные), параллельные и распределённые транзакции. Распределённые транзакции подразумевают использование больше чем одной транзакционной системы и требуют намного более сложной логики (например, two-phase commit — двухфазный протокол фиксации транзакции). Также, в некоторых системах реализованы автономные транзакции, или под-транзакции, которые являются автономной частью родительской транзакции.

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

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

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

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

10. Классификация ограничений целостности. Ограничения атрибута, кортежа, отношения, базы данных.

Классификация ограничений целостности

Ограничения целостности можно классифицировать несколькими способами:

• По способам реализации.

• По времени проверки.

• По области действия.

Классификация ограничений целостности по способам реализации

Каждая система обладает своими средствами поддержки ограничений целостности. Различают два способа реализации:

• Декларативная поддержка ограничений целостности.

• Процедурная поддержка ограничений целостности.

 Декларативная поддержка ограничений целостности заключается в определении ограничений средствами языка определения данных (DDL - Data Definition Language). Обычно средства декларативной поддержки целостности (если они имеются в СУБД) определяют ограничения на значения доменов и атрибутов, целостность сущностей (потенциальные ключи отношений) и ссылочную целостность (целостность внешних ключей). Декларативные ограничения целостности можно использовать при создании и модификации таблиц средствами языка DDL или в виде отдельных утверждений (ASSERTION).

Например, следующий оператор создает таблицу PERSON и определяет для нее некоторые ограничения целостности: CREATE TABLE PERSON (Pers_Id INTEGER PRIMARY KEY, Pers_Name CHAR(30) NOT NULL, Dept_Id REFERENCES DEPART(Dept_Id) ON UPDATE CASCADE ON DELETE CASCADE);

После выполнения оператора для таблицы PERSON будут объявлены следующие ограничения целостности:

• Поле Pers_Id образует потенциальный ключ отношения.

• Поле Pers_Name не может содержать null-значений.

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

Средства декларативной поддержки ограничений описаны в стандарте SQL и более подробно рассматриваются ниже.

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

Не все ограничения целостности можно реализовать декларативно.

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

 Ограничения с отложенной проверкой проверяется в момент фиксации транзакции оператором COMMIT WORK. Внутри транзакции ограничение может не выполняться. Если в момент фиксации транзакции обнаруживается нарушение ограничения с отложенной проверкой, то транзакция откатывается.

11. Синтаксис ограничений стандарта SQL. Синтаксис операторов SQL, использующих ограничения.

Синтаксис операторов SQL, использующих ограничения

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

• CREATE DOMAIN - создать домен

• ALTER DOMAIN - изменить домен

• DROP DOMAIN - удалить домен

• CREATE TABLE - создать таблицу

• ALTER TABLE - изменить таблицу

• DROP TABLE - удалить таблицу

• CREATE ASSERTION - создать утверждение

• DROP ASSERTION - удалить утверждение

• COMMIT WORK - зафиксировать транзакцию

• SET CONSTRAINTS - установить момент проверки ограничений

CREATE DOMAIN Имя домена [AS] Тип данных

Синтаксис ограничений стандарта sql

Синтаксис ограничений стандарта SQL

Понятие ограничения используется во многих операторах определения данных (DDL).

Ограничение check::= CHECK Предикат

Ограничения таблицы ::= [CONSTRAINT Имя ограничения] { {PRIMARY KEY (Имя столбца.,..)} | {UNIQUE (Имя столбца.,..)} | {FOREIGN KEY (Имя столбца.,..) REFERENCES Имя таблицы [(Имя столбца.,..)] [Ссылочная спецификация]} | { Ограничение check } } [Атрибуты ограничения]

Ограничения столбца::= [CONSTRAINT Имя ограничения] { {NOT NULL} | {PRIMARY KEY} | {UNIQUE} | {REFERENCES Имя таблицы [(Имя столбца)] [Ссылочная спецификация]} | { Ограничение check } } [Атрибуты ограничения]

Ссылочная спецификация::= [MATCH {FULL | PARTIAL}] [ON UPDATE {CASCADE | SET NULL | SET DEFAULT | NO ACTION}] [ON DELETE {CASCADE | SET NULL | SET DEFAULT | NO ACTION}]

Атрибуты ограничения::= {DEFERRABLE [INITIALLY DEFERRED | INITIALLY IMMEDIATE]} | {NOT DEFERRABLE}

Ограничение типа CHECK. Ограничение типа CHECK содержит предикат, могущий принимать значения TRUE, FALSE и UNKNOWN (NULL).

12. Работа транзакций в смеси. Проблема потери результатов обновления. Проблема незафиксированной зависимости. Неповторяемое считывание. Фиктивные элементы (фантомы). Собственно несовместимый анализ.