Нормальные формы 4-6+

Четвертая НФ

Здесь настало время рассказать про виды связей таблиц:

1 к 1, когда на 1 запись из первой таблице всегда соответствует только 1 запись из второй таблицы. По сути один кортеж данных, разнесенный на 2 таблицы. Пример: Таблицы сотрудников и их рабочих телефонов, при учете, что у каждого сотрудника может быть только один телефон и один телефон может принадлежать только одному сотруднику. Это неправильное отношение. В данном случае данные должны быть слиты в одну таблицу, но иногда, в особых случаях приходится делать и такое, жертвуя логикой в угоду производительности.
1 ко многим, ну тут просто: у одной записи в первой таблице может быть много связей в другой. В нашем случае - это таблица товаров и таблица заказов, ведь у одного вида товара может быть несколько заказов.
многие ко многим. Вот об этом виде связей и есть четвертая НФ.

Смотри, допустим, у нас появляется таблица поставщиков

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

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

Пятая НФ

Это как обычно предыдущая, плюс еще некоторые условия. В нашем примере есть зависимость товара от поставщика а еще зависимость заказа от товара и поставщика. При объединении этих трех таблиц (привет, объединение множеств!), мы получим полную билеберду, не связанную с реальностью

Так вот, чтобы отношение находилось в 5 нормальной форме, нам надо иметь однозначные кортежи данных для всех возможных вариантов поставщиков, заказов и товаров, а это еще три таблицы:

Товары_Заказа, Товары_Поставщика, Поставщики_Заказов. В общем, штука, которая может и мозг пополам поломать. Но реальность состоит в том, что как правило, при проектировании ПО, 5 НФ уже является избыточной и поэтому ее не используют так часто.

Шестая НФ

Про нее я тебе расскажу справочно, лично я ее не использовал ни разу за 15+ лет своей карьеры. Но то, что она есть тебе знать надо - на интервью могут спросить. Таблица находится в 6 нормальной форме, когда она не может быть подвергнута дальнейшим декомпозициям без потерь. Бред какой-то, мы уже в 5 все оптимизировали по самые помидоры.

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

Дополнительные Нормальные Формы

Эти 6 форм - стандартные для всех реляционных баз данных, но есть и их дополнения в виде еще двух форм:

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

Все, я попытался максимально просто раскрыть достаточно сложную тему, но если у тебя есть вопросы - задавай, буду ждать комментариев! А еще - подписок!