- Таблица 3NF всегда соответствует BCNF (нормальная форма Бойса-Кодда)
- Достижимость BCNF
- Разложение на BCNF
- Несколько базовых советов
- Используйте как минимум третью нормальную форму
- Первая нормальная форма
- Вторая нормальная форма
- Третья нормальная форма
- Создайте последнюю линию обороны в виде ограничений
- Никогда не храните в одном поле целые адреса
- Еще одна проблема адресов — «анонимные» поля
- Никогда не храните в одном поле имя и фамилию
- Установите соглашения для имен таблиц и полей и придерживайтесь их
- Нормализация отношений. Шесть нормальных форм
- Используемые термины
- Нормальная форма Бойса-Кодда (НФБК) (частная форма третьей нормальной формы)
- Четвертая нормальная форма
- Пятая нормальная форма
- Доменно-ключевая нормальная форма
- Шестая нормальная форма
- Третья и Бойса-Кодда
- Приведение в 3НФ
- Приведение в НФБК
- Роль нормализации в проектировании реляционных баз данных
- Вторая нормальная форма (2NF)
- Третья нормальная форма (3NF)
- Нормальная форма Бойса — Кодда (BCNF)
- Четвёртая нормальная форма (4NF)
- Пятая нормальная форма (5NF)
Таблица 3NF всегда соответствует BCNF (нормальная форма Бойса-Кодда)
Однако только S1, S2, S3 и S4 являются кандидатами на ключи (то есть минимальными суперключами для этого отношения), потому что, например, S1 ⊂ S5, поэтому S5 не может быть потенциальным ключом.
Напомним, что 2NF запрещает частичные функциональные зависимости непростых атрибутов (т. е. атрибут, который не встречается ни в одном ключе-кандидате. См. «ключи-кандидаты») и что 3NF запрещает транзитивные функциональные зависимости непростых атрибутов от кандидата. ключи.
Достижимость BCNF
Для каждой комбинации типа «Человек/Магазин» таблица показывает, какой магазин этого типа географически находится ближе всего к дому человека. Для простоты будем считать, что один магазин не может относиться к более чем одному типу.
Поскольку все три атрибута являются простыми атрибутами (т.е. принадлежат потенциальным ключам), таблица находится в 3NF. Однако таблица не находится в BCNF, поскольку атрибут типа магазина функционально зависит от несуперключа: Ближайший магазин.
Нарушение BCNF означает, что таблица подвержена аномалиям. Например, тип магазина Eagle Eye может быть изменен на «Оптометрист» в записи «Фуллер», сохраняя при этом тип магазина «Оптик» в записи «Дэвидсон». Это означало бы противоречивые ответы на вопрос: «Какой тип магазина Eagle Eye?»
Разложение на BCNF
Поскольку это определение примерно на три года предшествовало определению Бойса и Кодда, мне кажется, что BCNF по праву следует называть нормальной формой Хита. Но это не так.
Геометрия цветов от Mookiezoolook
Для приложений, которые масштабируются по трафику и сложности, крайне важно сначала спроектировать грамотную схему базы данных. Если сделать плохой выбор, придется пойти на многое, чтобы этот плохой шаблон не распространился на службы и контроллеры бэкендов и, наконец, на фронтенд.
Но как оценить, какая схема лучше? И что вообще значит «лучше», когда мы говорим об архитектуре БД? Команда Mail.ru Cloud Solutions предлагает познакомиться с рекомендациями Майка Алча, консультанта по разработке программного обеспечения. Нам кажется, что он довольно лаконично резюмировал некоторые принципы грамотной конструкции.
Несколько базовых советов
Что касается второго момента: хотим ли мы уменьшить избыточность только из-за проблемы с размером хранилища? Нет, мы делаем это главным образом потому, что наличие избыточных данных приводит к проблеме несогласованности, если во время обновления вы не обновляете все поля, представляющие одну и ту же информацию.
Используйте как минимум третью нормальную форму
Архитектуру баз данных можно отнести к следующим категориям:
Эти категории представляют классификацию по качеству. Кратко рассмотрим все категории и раз беременности, почему нужна третья нормальная форма.
Первая нормальная форма
Для первой нормальной формы каждое значение, каждый столбец, каждая таблица в БД должна быть атомарной. Что значит атомарным? Если кратко, то атомарное значение представляет собой «единичную вещь».
Здесь столбец областей («Области») содержит значения, которые не являются атомарными. Например, в строке Джона Доу поле хранит две сущности: «Дизайн веб-сайтов» и «Исследование клиентуры».
Таким образом, эта таблица не находится в первой нормальной форме.
Чтобы привести ее к такой форме, в каждом поле должно храниться только одно значение.
Вторая нормальная форма
Во второй нормальной форме ни один столбец, который не является частью первичного ключа (или который может действовать как часть другого первичного ключа), не может быть выведен из меньшей части первичного ключа.
Что это значит?
Допустим, у вас такая архитектура базы (я подчеркнул поля, соответствующие первичному ключу в этой таблице):
В этом проекте имя сотрудника может быть непосредственно выведено из employeee_id, поскольку идея заключается в том, что имя сотрудника однозначно определяется его идентификатором.
Аналогично, имя проекта однозначно определяется идентификатором project_id.
Таким образом, у нас два столбца можно вывести из части первичного ключа.
Каждого из этих примеров было бы достаточно, чтобы выбросить эту таблицу из второй нормальной формы.
Еще один вывод заключается в том, что если таблица была в первой нормальной форме и все первичные ключи являются одиночными столбцами, то таблица уже находится во второй нормальной форме.
Третья нормальная форма
Чтобы таблица соответствовала третьей нормальной форме, она должна быть во второй нормальной форме, при этом в ней не должно быть атрибутов (столбцов), кроме первичного, которые транзитивно зависят от первичного ключа.
Допустим, у вас следующая архитектура (которая далека от идеала):
В этой таблице department_number можно вывести из employee_id, а department_name можно вывести из department_number. Таким образом, department_name транзитивно зависит от employee_id!
Какие проблемы возникают из-за этого?
Если название отдела можно вывести из его номера, то хранение этого поля для каждого сотрудника вводит лишнюю избыточность.
Представьте, что отдел маркетинга меняет название на «Маркетинг и продажи». Чтобы сохранить согласованность, придется обновить ячейку в каждой строке таблицы для каждого сотрудника этого отдела! В третьей нормальной форме такого бы не произошло.
Кроме того, вот, что произойдет, если Мэри решит покинуть компанию: мы должны удалить ее строку из таблицы, но если она была единственным сотрудником оперативного отдела, то отдел тоже придется удалить.
Всех этих проблем можно полностью избежать в третьей нормальной форме.
Мамины эксплойты. Ее дочь зовут Помогите! Меня заставляют подделывать паспорта
Создайте последнюю линию обороны в виде ограничений
База данных, с которой вы работаете, — это больше, чем просто группа таблиц. В нее встроена определенная функциональность. Многие из этих функций помогают обеспечить качество и корректность данных.
Ограничения устанавливают правила, какие значения можно вносить в поля БД.
Когда определяете отношения в базе данных, обязательно установите ограничения внешних ключей.
Обязательно укажите, что должно произойти при удалении и обновлении строки, связанной с другими строками в других таблицах (правила ON DELETE и ON UPDATE).
Обязательно используйте NOT NULL для всех полей, которые никогда не должны обнуляться. Возможно, есть смысл установить проверку на бэкенде, но помните, что сбои случаются всегда, поэтому не помешает добавить и такое ограничение.
Установите проверочные ограничения CHECK, чтобы убедиться — значения таблицы находятся в допустимом диапазоне, например, цена на товар всегда имеет положительное значение.
Интересный факт: в апреле 2020 года именно такое ограничение в программном обеспечении помешало торгам на московской бирже ММВБ, потому что цена на нефтяные фьючерсы WTI опустилась ниже нуля. В отличие от московской биржи, Нью-Йоркская товарная биржа NYMEX обновила софт за неделю до инцидента, поэтому сумела успешно провести сделки по отрицательной цене, то есть с доплатой покупателю от продавца — прим. пер.
Никогда не храните в одном поле целые адреса
Поскольку полный адрес хранится как строка в поле БД, в первую очередь придется разбираться, какая часть этой строки является городом! И это почти невыполнимая задача, учитывая все возможные форматы адресов в этом поле.
Поэтому обязательно разбивайте универсальное поле «Адрес» на конкретные поля: улица, номер дома, город, область, почтовый индекс и так далее.
Еще одна проблема адресов — «анонимные» поля
Какие тут видны возможные проблемы? Сможете ли вы легко отличить город Чикаго от улицы Чикаго? Наверное, нет.
Поэтому не забывайте всегда давать четкие имена столбцов каждой единице информации.
Никогда не храните в одном поле имя и фамилию
Аналогично ситуации с адресами: количество вариаций имени и фамилии слишком велико, чтобы их четко различать.
Как определить, где имя, а где фамилия, чтобы разделить строку? Ошибки неизбежны.
Способ избежать многих проблем — создать отдельные поля (в формах) для имен пользователей first_name и last_name. Таким образом, вы позволите пользователям разделить свои собственные имена и сможете хранить данные согласованным образом.
Примечание: я не говорю, что в полях БД запрещены пробелы. Например, для таких имен, как «Хуан Мартин Дель Потро», первая часть «Хуан Мартин» входит в поле first_name, а «Дель Потро» — в поле last_name. Конечно, это не идеально. Можно дополнительно завести столбцы middle_name и second_last_name.
Посмотрите подробнее о возможных вариациях имен и фамилий в списке «Заблуждения программистов об именах» и статье «Заблуждения программистов об именах — с примерами». Придется согласиться на какой-то компромисс между точностью и практичностью.
Установите соглашения для имен таблиц и полей и придерживайтесь их
Я бы посоветовал установить правила именования с подчеркиванием, потому что не все SQL-движки одинаково обрабатывают заглавные буквы, а заключать всё в кавычки весьма утомительно.
Нормализация отношений. Шесть нормальных форм
Процесс проектирования БД с использование метода НФ является итерационным и заключается в последовательном переводе отношения из 1НФ в НФ более высокого порядка по определенным правилам. Каждая следующая НФ ограничивается определенным типом функциональных зависимостей и устранением соответствующих аномалий при выполнении операций над отношениями БД, а также сохранении свойств предшествующих НФ.
Используемые термины
Атрибут — свойство некоторой сущности. Часто называется полем таблицы.
Домен атрибута — множество допустимых значений, которые может принимать атрибут.
Кортеж — конечное множество взаимосвязанных допустимых значений атрибутов, которые вместе описывают некоторую сущность (строка таблицы).
Отношение — конечное множество кортежей (таблица).
Схема отношения — конечное множество атрибутов, определяющих некоторую сущность. Иными словами, это структура таблицы, состоящей из конкретного набора полей.
Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.
Нормальная форма — требование, предъявляемое к структуре таблиц в теории реляционных баз данных для устранения из базы избыточных функциональных зависимостей между атрибутами (полями таблиц).
Метод нормальных форм (НФ) состоит в сборе информации о объектах решения задачи в рамках одного отношения и последующей декомпозиции этого отношения на несколько взаимосвязанных отношений на основе процедур нормализации отношений.
Цель нормализации: исключить избыточное дублирование данных, которое является причиной аномалий, возникших при добавлении, редактировании и удалении кортежей(строк таблицы).
Аномалией называется такая ситуация в таблице БД, которая приводит к противоречию в БД либо существенно усложняет обработку БД. Причиной является излишнее дублирование данных в таблице, которое вызывается наличием функциональных зависимостей от не ключевых атрибутов.
Аномалии-модификации проявляются в том, что изменение одних данных может повлечь просмотр всей таблицы и соответствующее изменение некоторых записей таблицы.
Аномалии-удаления — при удалении какого либо кортежа из таблицы может пропасть информация, которая не связана на прямую с удаляемой записью.
Аномалии-добавления возникают, когда информацию в таблицу нельзя поместить, пока она не полная, либо вставка записи требует дополнительного просмотра таблицы.
Отношение находится в 1НФ, если все его атрибуты являются простыми, все используемые домены должны содержать только скалярные значения. Не должно быть повторений строк в таблице.
Нарушение нормализации 1НФ происходит в моделях BMW, т.к. в одной ячейке содержится список из 3 элементов: M5, X5M, M1, т.е. он не является атомарным. Преобразуем таблицу к 1НФ:
Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут неприводимо зависит от Первичного Ключа(ПК).
Неприводимость означает, что в составе потенциального ключа отсутствует меньшее подмножество атрибутов, от которого можно также вывести данную функциональную зависимость.
Отношение находится в 3НФ, когда находится во 2НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа. Проще говоря, второе правило требует выносить все не ключевые поля, содержимое которых может относиться к нескольким записям таблицы в отдельные таблицы.
Нормальная форма Бойса-Кодда (НФБК) (частная форма третьей нормальной формы)
Определение 3НФ не совсем подходит для следующих отношений:
1) отношение имеет два или более потенциальных ключа;
2) два и более потенциальных ключа являются составными;
3) они пересекаются, т.е. имеют хотя бы один общий атрибут.
Для отношений, имеющих один потенциальный ключ (первичный), НФБК является 3НФ.
Отношение находится в НФБК, когда каждая нетривиальная и неприводимая слева функциональная зависимость обладает потенциальным ключом в качестве детерминанта.
Предположим, рассматривается отношение, представляющее данные о бронировании стоянки на день:
Тариф имеет уникальное название и зависит от выбранной стоянки и наличии льгот, в частности:
Недостатком данной структуры является то, что, например, по ошибке можно приписать тариф «Бережливый» к бронированию второй стоянки, хотя он может относиться только к первой стоянки.
Можно улучшить структуру с помощью декомпозиции отношения на два и добавления атрибута Имеет льготы, получив отношения, удовлетворяющие НФБК (подчёркнуты атрибуты, входящие в первичный ключ.):
Четвертая нормальная форма
Отношение находится в 4НФ, если оно находится в НФБК и все нетривиальные многозначные зависимости фактически являются функциональными зависимостями от ее потенциальных ключей.
То есть, например, при добавлении нового вида пиццы придется внести по одному новому кортежу для каждого района доставки. Возможна логическая аномалия, при которой определенному виду пиццы будут соответствовать лишь некоторые районы доставки из обслуживаемых рестораном районов.
Пятая нормальная форма
Отношения находятся в 5НФ, если оно находится в 4НФ и отсутствуют сложные зависимые соединения между атрибутами. Если «Атрибут_1» зависит от «Атрибута_2», а «Атрибут_2» в свою очередь зависит от «Атрибута_3», а «Атрибут_3» зависит от «Атрибута_1», то все три атрибута обязательно входят в один кортеж.
Это очень жесткое требование, которое можно выполнить лишь при дополнительных условиях. На практике трудно найти пример реализации этого требования в чистом виде.
Пятая нормальная форма ориентирована на работу с зависимыми соединениями. Указанные зависимые соединения между тремя атрибутами встречаются очень редко. Зависимые соединения между четырьмя, пятью и более атрибутами указать практически невозможно.
Доменно-ключевая нормальная форма
Переменная отношения находится в ДКНФ тогда и только тогда, когда каждое наложенное на неё ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данную переменную отношения.
Ограничение домена – ограничение, предписывающее использовать для определённого атрибута значения только из некоторого заданного домена. Ограничение по своей сути является заданием перечня (или логического эквивалента перечня) допустимых значений типа и объявлением о том, что указанный атрибут имеет данный тип.
Шестая нормальная форма
Переменная отношения находится в шестой нормальной форме тогда и только тогда, когда она удовлетворяет всем нетривиальным зависимостям соединения. Из определения следует, что переменная находится в 6НФ тогда и только тогда, когда она неприводима, то есть не может быть подвергнута дальнейшей декомпозиции без потерь. Каждая переменная отношения, которая находится в 6НФ, также находится и в 5НФ.
Идея «декомпозиции до конца» выдвигалась до начала исследований в области хронологических данных, но не нашла поддержки. Однако для хронологических баз данных максимально возможная декомпозиция позволяет бороться с избыточностью и упрощает поддержание целостности базы данных.
Для хронологических баз данных определены U_операторы, которые распаковывают отношения по указанным атрибутам, выполняют соответствующую операцию и упаковывают полученный результат. В данном примере соединение проекций отношения должно производится при помощи оператора U_JOIN.
Переменная отношения «Работники» не находится в 6НФ и может быть подвергнута декомпозиции на переменные отношения «Должности работников» и «Домашние адреса работников».
Третья и Бойса-Кодда
Третья нормальная форма исправляет оставшиеся после приведения в 2НФ простые аномалии. Форма Бойса-Кодда является самой сильной формой, не допускающей аномалий, причиной возникновения которых являются сложные функциональные зависимости, и логически находится между третьей и четвертой НФ.
Третья нормальная форма позволяет исправить те аномалии, которые не были исправлены при переходе от 1НФ к 2НФ из-за транзитивных функциональных зависимостей.
Рассмотрим пример отношений, приведенных в 2НФ, которые еще не находятся в 3НФ:
В нем есть две базовые функциональные зависимости: и . Из-за того, что только транзитивно зависит от ключа, имеют место аномалии вставки, удаления и изменения.
Приведение в 3НФ
Отношение в 2НФ приводится в 3НФ похожим образом на то, как 1НФ приводится в 2НФ – с помощью декомпозиции по неудовлетворяющим условию функциональным зависимостям. Чтобы избавиться от транзитивных зависимостей, выполним декомпозицию по последней в каждой цепочке ФЗ зависимости, и будем повторять такую операцию, пока все цепочки зависимостей не станут длины 1. В данном примере единственная цепочка ФЗ – это . Выполнив декомпозицию по , получим
Нетрудно заметить, что после приведения в 3НФ не остается никаких «неявных» зависимостей между атрибутами одного отношения. Благодаря этому, аномалии вставки, удаления и изменения больше не проявляются: не зависимые друг от друга напрямую неключевые данные никак не влияют на возможности сохранить или обновить ту или иную информацию.
Отношения в 3НФ все еще подвержены аномалии обновления, но в более редких случаях. Рассмотрим следующий пример, в котором у каждого преподавателя свой телефон и каждый преподаватель принимает у ровно одной группы.
Функциональные зависимости в данном отношении – это , и , а также все следующие из них.
Если преподаватель ведет разные предметы у разных групп, такая структура отношения позволяет задать преподавателю разные телефоны, что нарушает целостность БД. Причиной такой аномалии является то, что в данном отношении есть несколько ключей, и каждый атрибут является частью хотя бы одного ключа (в частности, – это ключ), тогда как первые три НФ не накладывают никакие ограничения на ключевые атрибуты.
Следует отметить, что определение НФБК не требует 3НФ. Однако можно доказать, что любое отношение в НФБК автоматически находится в 3НФ.
Нормальная форма Бойса-Кодда исправляет аномалии, возникающие из-за перекрывающихся ключей. В частности, если отношение находится в 3НФ и в нем нет перекрывающихся ключей, оно автоматически находится в НФБК. Поскольку, опираясь только на функциональные зависимости, нельзя потребовать более сильное условие, чем надключ в левой части каждой ФЗ, то НФБК – «совершенная» НФ с точки зрения только функциональных зависимостей.
В НФБК запрещены функциональные зависимости от наборов атрибутов, не являющихся надключами. В качестве примера возьмем отношение, расмотренное в секции «Аномалии» третьей нормальной формы.
Приведение в НФБК
Как и в случае с предыдущими двумя нормальными формами, приведение в НФБК осуществляется с помощью декомпозиций по функциональным зависимостям, нарушающим условие из определения НФБК. На рассматриваемом примере только в отношении ни одна из частей не является надключом, поэтому делаем по нему декомпозицию. В данном случае не имеет значения, рассматривать ли зависимость в правую сторону или в левую, поэтому для примера будем использовать . Получаем отношения
После приведения в НФБК свойство независимости не связанных друг с другом напрямую данных теперь распространяется и на ключевые атрибуты, что позволяет полностью исплючить аномалии изменения.
Замечание. Несмотря на то, что любое отношение можно привести в НФБК, иногда при этом могут «распадаться» функциональные зависимости. Так, например, если рассмотреть отношение, в котором на каждой кафедре конкретный предмет читается только одним преподавателем, и никаким преподавателем не читается два разных предмета, можно обнаружить, что при проведении декомпозии, первая ФЗ () распадается, так как части ключа оказываются в разных отношениях.
Замечание 2. Всегда можно привести отношение к 3НФ, сохранив все ФЗ, если производить декомпозиции в правильном порядке.
В НФБК не может быть аномалий, связанных с функциональными зависимостями, так как на них наложено самое сильное ограничение. Однако есть более сложные виды зависимостей и аномалий. Так, аномалии многозначных зависимостей исправляются четвертой НФ, а аномалии зависимостей соединения исправляются пятой НФ.
Нормальная форма Бойса — Кодда (сокращённо BCNF от англ. Boyce–Codd normal form) — одна из возможных нормальных форм отношения в реляционной модели данных.
Менее формально, переменная отношения находится в нормальной форме Бойса — Кодда тогда и только тогда, когда детерминанты всех её функциональных зависимостей являются потенциальными ключами.
Для определения BCNF следует понимать понятие функциональной зависимости атрибутов отношения.
Пусть R является переменной отношения, а X и Y — произвольными подмножествами множества атрибутов переменной отношения R. Y функционально зависимо от X тогда и только тогда, когда для любого допустимого значения переменной отношения R, если два кортежа переменной отношения R совпадают по значению X, они также совпадают и по значению Y. Подмножество X называют детерминантом, а Y — зависимой частью.
Функциональная зависимость тривиальна тогда и только тогда, когда её правая (зависимая) часть является подмножеством её левой части (детерминанта).
Функциональная зависимость называется неприводимой слева, если ни один атрибут не может быть опущен из её детерминанта без нарушения зависимости (иными словами, детерминант неизбыточен).
Ситуация, когда отношение будет находиться в 3NF, но не в BCNF, возникает, например, при условии, что отношение имеет два (или более) потенциальных ключа, которые являются составными, и между отдельными атрибутами таких ключей существует функциональная зависимость.
Поскольку описанная зависимость не является транзитивной, то такая ситуация под определение 3NF не подпадает. На практике такие отношения встречаются достаточно редко, для всех прочих отношений 3NF и BCNF эквивалентны.
Предположим, рассматривается отношение, представляющее данные о бронировании теннисных кортов на день:
Недостатком данной структуры является то, что, например, по ошибке можно приписать тариф «Корт 1 для членов клуба» к бронированию второго корта, хотя он может относиться только к первому корту.
Можно улучшить структуру с помощью декомпозиции отношения на два, получив отношения, удовлетворяющие BCNF (подчёркнуты атрибуты, входящие в первичный ключ). Для большей наглядности к информации о тарифах добавлен атрибут Для членов клуба:
Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, потенциально приводящей к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение.
Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов).
Роль нормализации в проектировании реляционных баз данных
Переменная отношения находится в первой нормальной форме (1НФ) тогда и только тогда, когда в любом допустимом значении отношения каждый его кортеж содержит только одно значение для каждого из атрибутов.
В реляционной модели отношение всегда находится в первой нормальной форме по определению понятия отношение. Что же касается различных таблиц, то они могут не быть правильными представлениями отношений и, соответственно, могут не находиться в 1НФ.
Вторая нормальная форма (2NF)
Переменная отношения находится во второй нормальной форме тогда и только тогда, когда она находится в первой нормальной форме и каждый неключевой атрибут неприводимо (функционально полно) зависит от её потенциального ключа. Функционально полная зависимость означает, что если потенциальный ключ является составным, то атрибут зависит от всего ключа и не зависит от его частей.
Третья нормальная форма (3NF)
Переменная отношения находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме, и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых.
Нормальная форма Бойса — Кодда (BCNF)
Переменная отношения находится в нормальной форме Бойса — Кодда (иначе — в усиленной третьей нормальной форме) тогда и только тогда, когда каждая её нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.
Четвёртая нормальная форма (4NF)
Переменная отношения находится в четвёртой нормальной форме, если она находится в нормальной форме Бойса — Кодда и не содержит нетривиальных многозначных зависимостей.
Пятая нормальная форма (5NF)
Переменная отношения находится в пятой нормальной форме (иначе — в проекционно-соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения.