отношение находится в третьей нормальной форме тогда и только тогда когда
Третья нормальная форма
Третья нормальная форма (англ. Third normal form ; сокращённо 3NF) — одна из возможных нормальных форм отношения реляционной базы данных. 3NF была изначально сформулирована Э. Ф. Коддом в 1971 году.
Содержание
Определение
Переменная отношения R находится в 3NF тогда и только тогда, когда выполняются следующие условия:
Пояснения к определению:
Неключевой атрибут отношения R — это атрибут, который не принадлежит ни одному из потенциальных ключей R.
Функциональная зависимость множества атрибутов Z от множества атрибутов X (записывается X → Z, произносится «икс определяет зет») является транзитивной, если существует такое множество атрибутов Y, что X → Y и Y → Z. При этом ни одно из множеств X, Y и Z не является подмножеством другого, то есть функциональные зависимости X → Z, X → Y и Y → Z не являются тривиальными.
Определение 3NF, эквивалентное определению Кодда, но по-другому сформулированное, дал Карло Заниоло в 1982 году. Согласно ему, переменная отношения находится в 3NF тогда и только тогда, когда для каждой из её функциональных зависимостей X → A выполняется хотя бы одно из следующих условий:
Определение Заниоло четко определяет разницу между 3NF и более строгой нормальной формой Бойса-Кодда (НФБК): НФБК исключает третье условие («А — ключевой атрибут»).
«Ничего, кроме ключа»
Запоминающееся и, по традиции, наглядное резюме определения 3NF Кодда было дано Биллом Кентом: каждый неключевой атрибут «должен предоставлять информацию о ключе, полном ключе и ни о чём, кроме ключа». [1]
Условие зависимости от «полного ключа» неключевых атрибутов обеспечивает то, что таблица находится во второй нормальной форме; а условие зависимости их от «ничего, кроме ключа» — то, что они находятся в третьей нормальной форме.
Крис Дэйт говорит о резюме Кента как о «интуитивно привлекательной характеристике» 3NF, и замечает, что с небольшим изменением она может служить и как определение более строгой нормальной формы Бойса-Кодда: «Каждый атрибут должен предоставлять информацию о ключе, полном ключе и ни о чём, кроме ключа». Вариант определения 3NF Кента является менее строгим, чем вариант НФБК Дэйта, поскольку первая утверждает только, что неключевые атрибуты зависят от ключей. Первичные атрибуты (которые являются ключами или их частями) вовсе не должны быть функционально зависимыми; каждый из них предоставляет информацию о ключе предоставлением самого ключа или его части. Здесь следует отметить, что это правило справедливо только для неключевых атрибутов, так как применение его ко всем атрибутам будет полностью запрещать все сложные альтернативные ключи, поскольку каждый элемент такого ключа будет нарушать условие «полного ключа».
Пример
Рассмотрим в качестве примера отношение, которое находится во 2NF, но не соответствует 3NF:
Сотрудник | Отдел | Телефон |
---|---|---|
Гришин | Бухгалтерия | 11-22-33 |
Васильев | Бухгалтерия | 11-22-33 |
Петров | Снабжение | 44-55-66 |
В отношении атрибут «Сотрудник» является первичным ключом. Личных телефонов у сотрудников нет, и телефон сотрудника зависит исключительно от отдела.
Таким образом, в отношении существуют следующие функциональные зависимости: Сотрудник → Отдел, Отдел → Телефон, Сотрудник → Телефон.
Зависимость Сотрудник → Телефон является транзитивной, следовательно, отношение не находится в 3NF.
В результате декомпозиции отношения R1 получаются два отношения, находящиеся в 3NF:
Отдел | Телефон |
---|---|
Бухгалтерия | 11-22-33 |
Снабжение | 44-55-66 |
Сотрудник | Отдел |
---|---|
Гришин | Бухгалтерия |
Васильев | Бухгалтерия |
Петров | Снабжение |
Исходное отношение R1 при необходимости легко получается в результате операции соединения отношений R2 и R3.
Примечания
Литература
Нормальные формы: третья и Бойса-Кодда
Третья нормальная форма исправляет оставшиеся после приведения в 2НФ простые аномалии. Форма Бойса-Кодда является самой сильной формой, не допускающей аномалий, причиной возникновения которых являются сложные функциональные зависимости, и логически находится между третьей и четвертой НФ.
Содержание
Третья нормальная форма [ править ]
Третья нормальная форма позволяет исправить те аномалии, которые не были исправлены при переходе от 1НФ к 2НФ из-за транзитивных функциональных зависимостей.
Запрещенные конструкции [ править ]
Рассмотрим пример отношений, приведенных в 2НФ, которые еще не находятся в 3НФ:
CourseId | Year | Lecturer | Phone |
---|---|---|---|
1 | 2020 | Корнеев Г. А. | 111-11-11 |
2 | 2019 | Киракозов А. Х. | 222-22-22 |
2 | 2020 | Киракозов А. Х. | 222-22-22 |
3 | 2019 | Левина А. Б. | 333-33-33 |
3 | 2020 | Чепурной А. И. | 444-44-44 |
Приведение в 3НФ [ править ]
CourseId | Year | Lecturer |
---|---|---|
1 | 2020 | Корнеев Г. А. |
2 | 2019 | Киракозов А. Х. |
2 | 2020 | Киракозов А. Х. |
3 | 2019 | Левина А. Б. |
3 | 2020 | Чепурной А. И. |
Lecturer | Phone |
---|---|
Корнеев Г. А. | 111-11-11 |
Киракозов А. Х. | 222-22-22 |
Левина А. Б. | 333-33-33 |
Чепурной А. И. | 444-44-44 |
Нетрудно заметить, что после приведения в 3НФ не остается никаких «неявных» зависимостей между атрибутами одного отношения. Благодаря этому, аномалии вставки, удаления и изменения больше не проявляются: не зависимые друг от друга напрямую неключевые данные никак не влияют на возможности сохранить или обновить ту или иную информацию.
Аномалии [ править ]
Отношения в 3НФ все еще подвержены аномалии обновления, но в более редких случаях. Рассмотрим следующий пример, в котором у каждого преподавателя свой телефон и каждый преподаватель принимает у ровно одной группы.
CourseId | Group | Examiner | Phone |
---|---|---|---|
1 | M3239 | Корнеев Г. А. | 111-11-11 |
4 | M3439 | Корнеев Г. А. | 111-11-11 |
1 | M3238 | Ведерников Н. В. | 222-22-22 |
2 | M3439 | Киракозов А. Х. | 333-33-33 |
Если преподаватель ведет разные предметы у разных групп, такая структура отношения позволяет задать преподавателю разные телефоны, что нарушает целостность БД. Причиной такой аномалии является то, что в данном отношении есть несколько ключей, и каждый атрибут является частью хотя бы одного ключа (в частности, [math]\mathrm
Нормальная форма Бойса-Кодда [ править ]
Следует отметить, что определение НФБК не требует 3НФ. Однако можно доказать, что любое отношение в НФБК автоматически находится в 3НФ.
Нормальная форма Бойса-Кодда исправляет аномалии, возникающие из-за перекрывающихся ключей. В частности, если отношение находится в 3НФ и в нем нет перекрывающихся ключей, оно автоматически находится в НФБК. Поскольку, опираясь только на функциональные зависимости, нельзя потребовать более сильное условие, чем надключ в левой части каждой ФЗ, то НФБК – «совершенная» НФ с точки зрения только функциональных зависимостей.
Запрещенные конструкции [ править ]
В НФБК запрещены функциональные зависимости от наборов атрибутов, не являющихся надключами. В качестве примера возьмем отношение, расмотренное в секции «Аномалии» третьей нормальной формы.
Приведение в НФБК [ править ]
CourseId | Group | Examiner |
---|---|---|
1 | M3239 | Корнеев Г. А. |
4 | M3439 | Корнеев Г. А. |
1 | M3238 | Ведерников Н. В. |
2 | M3439 | Киракозов А. Х. |
Examiner | Phone |
---|---|
Корнеев Г. А. | 111-11-11 |
Ведерников Н. В. | 222-22-22 |
Киракозов А. Х. | 333-33-33 |
После приведения в НФБК свойство независимости не связанных друг с другом напрямую данных теперь распространяется и на ключевые атрибуты, что позволяет полностью исплючить аномалии изменения.
Достижимость [ править ]
Замечание. Несмотря на то, что любое отношение можно привести в НФБК, иногда при этом могут «распадаться» функциональные зависимости. Так, например, если рассмотреть отношение, в котором на каждой кафедре конкретный предмет читается только одним преподавателем, и никаким преподавателем не читается два разных предмета, можно обнаружить, что при проведении декомпозии, первая ФЗ ( [math]\mathrm
Замечание 2. Всегда можно привести отношение к 3НФ, сохранив все ФЗ, если производить декомпозиции в правильном порядке.
Аномалии [ править ]
В НФБК не может быть аномалий, связанных с функциональными зависимостями, так как на них наложено самое сильное ограничение. Однако есть более сложные виды зависимостей и аномалий. Так, аномалии многозначных зависимостей исправляются четвертой НФ, а аномалии зависимостей соединения исправляются пятой НФ.
Система управления базами данных SQLite. Изучаем язык запросов SQL и реляционные базы данных на примере библиотекой SQLite3. Курс для начинающих.
Часть 3.8: Третья нормальная форма (3NF)
Здравствуйте, уважаемые посетители сайта ZametkiNaPolyah.ru. Продолжаем изучать базы данных и наше знакомство с библиотекой SQLite3. Мы уже рассмотрели первую и вторую нормальную форму, давайте теперь разберемся с тем, как привести отношение ко третьей нормальной форме и избавиться от транзитивной зависимости.
Повторю определение третьей нормальной формы и свои пояснения к этому определению. Переменная отношения находится в третьей нормальной форме тогда и только тогда, когда она находится во второй нормальной форме, и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых.
Давайте разбираться. Если база данных находится в третьей нормальной форме, то в ней должны быть соблюдены требования второй нормальной формы, а соответственно и первой. Область оптимизации третьей нормальной формы – таблица, третья нормальная форма избавляет нас от транзитивных зависимостей: любой столбец таблицы должен зависеть только от ключевого столбца.
Третья нормальная форма учит нас обеспечивать целостность данных в базах данных путем разрушения зависимостей. Изучая вторую нормальную форму, мы столкнулись с ситуацией, когда столбец город логически связан со столбцом индекс. Для того чтобы наше отношение находилось в третьей нормальной форме нам нужно разрушить эту связь, это можно сделать путем разбиение существующей таблицы: создадим два справочника. Первый справочник – справочник индексов, второй справочник – городов.
Данное отношение находится в третьей нормальной форме
На диаграмме видно, какие изменения я внес, теперь дам пояснения. Во-первых, мы исходим из того, что у одного города может быть несколько индексов. Во-вторых, названия небольших городов имеют свойства повторяться. Поэтому таблица ZIP является справочником для таблицы Publish (индекс более точно идентифицирует географическое положение издательства), а таблица City является справочником для таблицы ZIP.
Мы привели нашу базу данных к третьей нормальной форме, пусть и с некоторыми допущениями и оговорками, мы избавились от транзитивной зависимости тем самым мы устранили избыточность данных в базе данных и устранили аномалии, возникающие при добавлении данных и их удалении. Но взамен мы получили более сложную структуру, а значит, более сложные запросы к базе данных и более низкую скорость работы.
Кстати, внимательный читатель заметит, что индекс зависит не только от города, но и от адреса, если честно, он зависит от номера дома. Но об этом я предлагаю поговорить в следующей части данной темы.
Нормализация отношений. Шесть нормальных форм
В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.
Процесс проектирования БД с использование метода НФ является итерационным и заключается в последовательном переводе отношения из 1НФ в НФ более высокого порядка по определенным правилам. Каждая следующая НФ ограничивается определенным типом функциональных зависимостей и устранением соответствующих аномалий при выполнении операций над отношениями БД, а также сохранении свойств предшествующих НФ.
Используемые термины
Атрибут — свойство некоторой сущности. Часто называется полем таблицы.
Домен атрибута — множество допустимых значений, которые может принимать атрибут.
Кортеж — конечное множество взаимосвязанных допустимых значений атрибутов, которые вместе описывают некоторую сущность (строка таблицы).
Отношение — конечное множество кортежей (таблица).
Схема отношения — конечное множество атрибутов, определяющих некоторую сущность. Иными словами, это структура таблицы, состоящей из конкретного набора полей.
Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.
Функциональная зависимость между атрибутами (множествами атрибутов) X и Y означает, что для любого допустимого набора кортежей в данном отношении: если два кортежа совпадают по значению X, то они совпадают по значению Y. Например, если значение атрибута «Название компании» — Canonical Ltd, то значением атрибута «Штаб-квартира» в таком кортеже всегда будет Millbank Tower, London, United Kingdom. Обозначение:
Нормальная форма — требование, предъявляемое к структуре таблиц в теории реляционных баз данных для устранения из базы избыточных функциональных зависимостей между атрибутами (полями таблиц).
Метод нормальных форм (НФ) состоит в сборе информации о объектах решения задачи в рамках одного отношения и последующей декомпозиции этого отношения на несколько взаимосвязанных отношений на основе процедур нормализации отношений.
Цель нормализации: исключить избыточное дублирование данных, которое является причиной аномалий, возникших при добавлении, редактировании и удалении кортежей(строк таблицы).
Аномалией называется такая ситуация в таблице БД, которая приводит к противоречию в БД либо существенно усложняет обработку БД. Причиной является излишнее дублирование данных в таблице, которое вызывается наличием функциональных зависимостей от не ключевых атрибутов.
Аномалии-модификации проявляются в том, что изменение одних данных может повлечь просмотр всей таблицы и соответствующее изменение некоторых записей таблицы.
Аномалии-удаления — при удалении какого либо кортежа из таблицы может пропасть информация, которая не связана на прямую с удаляемой записью.
Аномалии-добавления возникают, когда информацию в таблицу нельзя поместить, пока она не полная, либо вставка записи требует дополнительного просмотра таблицы.
Первая нормальная форма
Отношение находится в 1НФ, если все его атрибуты являются простыми, все используемые домены должны содержать только скалярные значения. Не должно быть повторений строк в таблице.
Например, есть таблица «Автомобили»:
Вторая нормальная форма
Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут неприводимо зависит от Первичного Ключа(ПК).
Неприводимость означает, что в составе потенциального ключа отсутствует меньшее подмножество атрибутов, от которого можно также вывести данную функциональную зависимость.
Например, дана таблица:
Модель | Фирма | Цена | Скидка |
M5 | BMW | 5500000 | 5% |
X5M | BMW | 6000000 | 5% |
M1 | BMW | 2500000 | 5% |
GT-R | Nissan | 5000000 | 10% |
Таблица находится в первой нормальной форме, но не во второй. Цена машины зависит от модели и фирмы. Скидка зависят от фирмы, то есть зависимость от первичного ключа неполная. Исправляется это путем декомпозиции на два отношения, в которых не ключевые атрибуты зависят от ПК.
Модель | Фирма | Цена |
M5 | BMW | 5500000 |
X5M | BMW | 6000000 |
M1 | BMW | 2500000 |
GT-R | Nissan | 5000000 |
Третья нормальная форма
Отношение находится в 3НФ, когда находится во 2НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа. Проще говоря, второе правило требует выносить все не ключевые поля, содержимое которых может относиться к нескольким записям таблицы в отдельные таблицы.
Модель | Магазин | Телефон |
BMW | Риал-авто | 87-33-98 |
Audi | Риал-авто | 87-33-98 |
Nissan | Некст-Авто | 94-54-12 |
Таблица находится во 2НФ, но не в 3НФ.
В отношении атрибут «Модель» является первичным ключом. Личных телефонов у автомобилей нет, и телефон зависит исключительно от магазина.
Таким образом, в отношении существуют следующие функциональные зависимости: Модель → Магазин, Магазин → Телефон, Модель → Телефон.
Зависимость Модель → Телефон является транзитивной, следовательно, отношение не находится в 3НФ.
В результате разделения исходного отношения получаются два отношения, находящиеся в 3НФ:
Нормальная форма Бойса-Кодда (НФБК) (частная форма третьей нормальной формы)
Определение 3НФ не совсем подходит для следующих отношений:
1) отношение имеет два или более потенциальных ключа;
2) два и более потенциальных ключа являются составными;
3) они пересекаются, т.е. имеют хотя бы один общий атрибут.
Для отношений, имеющих один потенциальный ключ (первичный), НФБК является 3НФ.
Отношение находится в НФБК, когда каждая нетривиальная и неприводимая слева функциональная зависимость обладает потенциальным ключом в качестве детерминанта.
Предположим, рассматривается отношение, представляющее данные о бронировании стоянки на день:
Номер стоянки | Время начала | Время окончания | Тариф |
1 | 09:30 | 10:30 | Бережливый |
1 | 11:00 | 12:00 | Бережливый |
1 | 14:00 | 15:30 | Стандарт |
2 | 10:00 | 12:00 | Премиум-В |
2 | 12:00 | 14:00 | Премиум-В |
2 | 15:00 | 18:00 | Премиум-А |
Отношение находится в 3НФ. Требования второй нормальной формы выполняются, так как все атрибуты входят в какой-то из потенциальных ключей, а неключевых атрибутов в отношении нет. Также нет и транзитивных зависимостей, что соответствует требованиям третьей нормальной формы. Тем не менее, существует функциональная зависимость Тариф → Номер стоянки, в которой левая часть (детерминант) не является потенциальным ключом отношения, то есть отношение не находится в нормальной форме Бойса — Кодда.
Недостатком данной структуры является то, что, например, по ошибке можно приписать тариф «Бережливый» к бронированию второй стоянки, хотя он может относиться только к первой стоянки.
Можно улучшить структуру с помощью декомпозиции отношения на два и добавления атрибута Имеет льготы, получив отношения, удовлетворяющие НФБК (подчёркнуты атрибуты, входящие в первичный ключ.):
Тариф | Номер стоянки | Имеет льготы |
Бережливый | 1 | Да |
Стандарт | 1 | Нет |
Премиум-А | 2 | Да |
Премиум-В | 2 | Нет |
Тариф | Время начала | Время окончания |
Бережливый | 09:30 | 10:30 |
Бережливый | 11:00 | 12:00 |
Стандарт | 14:00 | 15:30 |
Премиум-В | 10:00 | 12:00 |
Премиум-В | 12:00 | 14:00 |
Премиум-А | 15:00 | 18:00 |
Четвертая нормальная форма
Отношение находится в 4НФ, если оно находится в НФБК и все нетривиальные многозначные зависимости фактически являются функциональными зависимостями от ее потенциальных ключей.
Предположим, что рестораны производят разные виды пиццы, а службы доставки ресторанов работают только в определенных районах города. Составной первичный ключ соответствующей переменной отношения включает три атрибута: <Ресторан, Вид пиццы, Район доставки>.
Такая переменная отношения не соответствует 4НФ, так как существует следующая многозначная зависимость:
<Ресторан>→ <Вид пиццы>
<Ресторан>→
То есть, например, при добавлении нового вида пиццы придется внести по одному новому кортежу для каждого района доставки. Возможна логическая аномалия, при которой определенному виду пиццы будут соответствовать лишь некоторые районы доставки из обслуживаемых рестораном районов.
Для предотвращения аномалии нужно декомпозировать отношение, разместив независимые факты в разных отношениях. В данном примере следует выполнить декомпозицию на <Ресторан, Вид пиццы>и <Ресторан, Район доставки>.
Однако, если к исходной переменной отношения добавить атрибут, функционально зависящий от потенциального ключа, например цену с учётом стоимости доставки ( <Ресторан, Вид пиццы, Район доставки>→ Цена), то полученное отношение будет находиться в 4НФ и его уже нельзя подвергнуть декомпозиции без потерь.
Пятая нормальная форма
Отношения находятся в 5НФ, если оно находится в 4НФ и отсутствуют сложные зависимые соединения между атрибутами.
Если «Атрибут_1» зависит от «Атрибута_2», а «Атрибут_2» в свою очередь зависит от «Атрибута_3», а «Атрибут_3» зависит от «Атрибута_1», то все три атрибута обязательно входят в один кортеж.
Это очень жесткое требование, которое можно выполнить лишь при дополнительных условиях. На практике трудно найти пример реализации этого требования в чистом виде.
Например, некоторая таблица содержит три атрибута «Поставщик», «Товар» и «Покупатель». Покупатель_1 приобретает несколько Товаров у Поставщика_1. Покупатель_1 приобрел новый Товар у Поставщика_2. Тогда в силу изложенного выше требования Поставщик_1 обязан поставлять Покупателю_1 тот же самый новый Товар, а Поставщик_2 должен поставлять Покупателю_1, кроме нового Товара, всю номенклатуру Товаров Поставщика_1. Этого на практике не бывает. Покупатель свободен в своем выборе товаров. Поэтому для устранения отмеченного затруднения все три атрибута разносят по разным отношениям (таблицам). После выделения трех новых отношений (Поставщик, Товар и Покупатель) необходимо помнить, что при извлечении информации (например, о покупателях и товарах) необходимо в запросе соединить все три отношения. Любая комбинация соединения двух отношений из трех неминуемо приведет к извлечению неверной (некорректной) информации. Некоторые СУБД снабжены специальными механизмами, устраняющими извлечение недостоверной информации. Тем не менее, следует придерживаться общей рекомендации: структуру базы данных строить таким образом, чтобы избежать применения 4НФ и 5НФ.
Пятая нормальная форма ориентирована на работу с зависимыми соединениями. Указанные зависимые соединения между тремя атрибутами встречаются очень редко. Зависимые соединения между четырьмя, пятью и более атрибутами указать практически невозможно.
Доменно-ключевая нормальная форма
Переменная отношения находится в ДКНФ тогда и только тогда, когда каждое наложенное на неё ограничение является логическим следствием ограничений доменов и ограничений ключей, наложенных на данную переменную отношения.
Ограничение домена – ограничение, предписывающее использовать для определённого атрибута значения только из некоторого заданного домена. Ограничение по своей сути является заданием перечня (или логического эквивалента перечня) допустимых значений типа и объявлением о том, что указанный атрибут имеет данный тип.
Ограничение ключа – ограничение, утверждающее, что некоторый атрибут или комбинация атрибутов является потенциальным ключом.
Любая переменная отношения, находящаяся в ДКНФ, обязательно находится в 5НФ. Однако не любую переменную отношения можно привести к ДКНФ.
Шестая нормальная форма
Переменная отношения находится в шестой нормальной форме тогда и только тогда, когда она удовлетворяет всем нетривиальным зависимостям соединения. Из определения следует, что переменная находится в 6НФ тогда и только тогда, когда она неприводима, то есть не может быть подвергнута дальнейшей декомпозиции без потерь. Каждая переменная отношения, которая находится в 6НФ, также находится и в 5НФ.
Идея «декомпозиции до конца» выдвигалась до начала исследований в области хронологических данных, но не нашла поддержки. Однако для хронологических баз данных максимально возможная декомпозиция позволяет бороться с избыточностью и упрощает поддержание целостности базы данных.
Для хронологических баз данных определены U_операторы, которые распаковывают отношения по указанным атрибутам, выполняют соответствующую операцию и упаковывают полученный результат. В данном примере соединение проекций отношения должно производится при помощи оператора U_JOIN.
Таб.№ | Время | Должность | Домашний адрес |
6575 | 01-01-2000:10-02-2003 | слесарь | ул.Ленина,10 |
6575 | 11-02-2003:15-06-2006 | слесарь | ул.Советская,22 |
6575 | 16-06-2006:05-03-2009 | бригадир | ул.Советская,22 |
Переменная отношения «Работники» не находится в 6НФ и может быть подвергнута декомпозиции на переменные отношения «Должности работников» и «Домашние адреса работников».