Нормализация баз данных. Нормальная форма Бойса-Кодда, четвертая и пятая нормальные формы.

Нормальная форма Бойса-Кодда (англ. Boyce-Codd normal form; сокращённо BCNF) — одна из возможных нормальных форм отношения в реляционной модели данных.Иногда нормальную форму Бойса-Кодда называют усиленной третьей нормальной формой, поскольку она во всех отношениях сильнее (строже) по сравнению с ранее определённой 3НФ^[1]. Отношение R находится нормальной форме Бойса – Кодда (НФБК) в том и только в том случае, если каждый его детерминант является возможным ключом.Проблема нормальной формы Бойса – Кодда может возникнуть только тогда, когда в отношении имеется несколько возможных ключей, эти ключи являются составными и пересекающимися (т.е. имеют общие атрибуты). Если в отношении имеется только один возможный ключ (являющийся первичным ключом), то это определение становится эквивалентным определению третьей нормальной формы. Таким образом, нормальная форма Бойса – Кодда представляет собой усиленную третью нормальную форму.

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

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

Отношение находится в 4НФ, если оно находится в НФБК и все нетривиальные многозначные зависимости фактически являются функциональными зависимостями от ее потенциальных ключей.В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от СПредположим, что рестораны производят разные виды пиццы, а службы доставки ресторанов работают только в определенных районах города. Составной первичный ключ соответствующей переменной отношения включает три атрибута: {Ресторан, Вид пиццы, Район доставки}.Такая переменная отношения не соответствует 4НФ, так как существует следующая многозначная зависимость:
{Ресторан} → {Вид пиццы}
{Ресторан} → {Район доставки}
То есть, например, при добавлении нового вида пиццы придется внести по одному новому кортежу для каждого района доставки. Возможна логическая аномалия, при которой определенному виду пиццы будут соответствовать лишь некоторые районы доставки из обслуживаемых рестораном районов.Для предотвращения аномалии нужно декомпозировать отношение, разместив независимые факты в разных отношениях. В данном примере следует выполнить декомпозицию на {Ресторан, Вид пиццы} и {Ресторан, Район доставки}.Однако, если к исходной переменной отношения добавить атрибут, функционально зависящий от потенциального ключа, например цену с учётом стоимости доставки ({Ресторан, Вид пиццы, Район доставки} → Цена), то полученное отношение будет находиться в 4НФ и его уже нельзя подвергнуть декомпозиции без потерь.

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

Отношения находятся в 5НФ, если оно находится в 4НФ и отсутствуют сложные зависимые соединения между атрибутами.
Если «Атрибут зависит от «Атрибута_2», а «Атрибут_2» в свою очередь зависит от «Атрибута_3», а «Атрибут_3» зависит от «Атрибута_1», то все три атрибута обязательно входят в один кортеж.Это очень жесткое требование, которое можно выполнить лишь при дополнительных условиях. На практике трудно найти пример реализации этого требования в чистом виде.Например, некоторая таблица содержит три атрибута «Поставщик», «Товар» и «Покупатель». Покупатель1 приобретает несколько Товаров у Поставщика1. Покупатель 1 приобрел новый Товар у Поставщика2. Тогда в силу изложенного выше требования I поставщик1 обязан поставлять Покупателю1 тот же самый новый Товар, а Поставщик2 должен поставлять Покупателю 1, кроме нового Товара, всю номенклатуру Товаров Поставщика1. Этого на практике не бывает. Покупатель свободен в своем выборе товаров. Поэтому для устранения отмеченного затруднения все три атрибута разносят по разным отношениям (таблицам). После выделения трех новых отношений (Поставщик, Товар и Покупатель) необходимо помнить, что при извлечении информации (например, О покупателях и товарах) необходимо в запросе соединить все три отношения. Любая комбинация соединения двух отношений изгрех неминуемо приведет к извлечению неверной (некорректной) информации. Некоторые СУБД снабжены специальными механизмами, устраняющими извлечение недостоверной информации. Тем не менее следует придерживаться общей рекомендации: структуру базы данных строить таким образом, чтобы избежать применения 4НФ и 5НФ.Пятая нормальная форма ориентирована на работу с зависимыми соединениями. Указанные зависимые соединения между тремя атрибутами встречаются очень редко. Зависимые соединениямежду четырьмя, пятью и более атрибутами указать практически невозможно