Третья нормальная форма — студенческий портал

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

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

Нормализация баз данных заключается в приведении структуры хранения данных к нормальным формам (NF). Всего таких форм существует 8, но часто достаточным является соблюдение первых трех. Рассмотрим их более подробно на примере учебной базы данных. Примеры будут строится по принципу «что было бы, если было иначе, чем сейчас».

Первая нормальная форма

Основным правилом первой формы является необходимость неделимости значения в каждом поле (столбце) строки – атомарность значений.

Рассмотрим таблицы сотрудников и телефонных линий.

• Чтобы избавиться от связывающей таблицы «Сотрудники_Линии», мы могли бы записать идентификаторы сотрудников для каждой линии в виде перечня в дополнительном столбце:
• 

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

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

Помимо атомарности к первой нормальной форме относятся следующие правила:

• Строки таблиц не должны зависеть друг от друга, т.е. первая запись не должна влиять на вторую и наоборот, вторая на третью и т.д. Размещение записей в таблице не имеет никакого значения.
• Аналогичная ситуация со столбцами записей. Их порядок не должен влиять на понимание информации.
• Каждая строка должна быть уникальна, поэтому для нее определяется первичный ключ, состоящий из одного либо нескольких полей (составной ключ). Первичный ключ не может повторяться в пределах таблицы и служит идентификатором записи.

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

Условием этой формы является отсутствие зависимости неключевых полей от части составного ключа.

Так как составной ключ в учебной базе наблюдается только в таблице «Сотрудники_Линии», то рассмотрим пример на ней.

На представленной диаграмме столбцы описания и приоритета зависят от столбца «Линия», входящего в составной ключ. Это значит, что для каждой линии, подключенной разным сотрудникам, потребуется повторно указывать описание и приоритетность. Подобная структура приводит к избыточности данных.

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

Если соблюдены правила первой нормальной формы, то создание таблицы «Линии» и перенос в нее зависимых столбцов удовлетворяет второй нормальной форме.

Третья нормальная форма

3NF схожа по логике с 2NF, но с некоторым отличием. Если 2 форма ликвидирует зависимости неключевых полей от части ключа, то третья нормальная форма исключает зависимость неключевых полей от других неключевых полей.

На приведенном примере таблицы сотрудников видно, что столбец «Супервайзер» имеет зависимость от столбца «Группа», а это значит, что при изменении значения поля группы, потребуется изменить значение поля супервайзера.

Все риски, которые были рассмотрены для 2NF, так же относятся к 3NF и устраняются переносом зависимых полей в отдельную таблицу.

Денормализация базы данных

Теория нормальных форм не всегда применима на практике. Например, неатомарные значения не всегда являются «злом», а иногда наоборот. Связано это с необходимостью дополнительного объединения (следовательно, затрат производительности системы) при выполнении запросов, особенно когда производится обработка большого массива информации.

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

Новые статьи:

Если материалы office-menu.ru Вам помогли, то поддержите, пожалуйста, проект, чтобы я мог развивать его дальше.

Источник: https://office-menu.ru/uroki-sql/51-normalizatsiya-bazy-dannykh

Третья нормальная форма

Понятие третьей нормальной формы основывается на понятии нетранзитивной зави­симости.

Транзитивная зависимость наблюдается в том случае, если один из двух описательных реквизитов зависит от ключа, а другой описательный рекви­зит зависит от первого описательного реквизита.

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

Требование третьей нормальной формы сводится к тому, чтобы все нёключевые поля зависели только от первичного ключа и не зависели друг от друга.

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

Пример 7.

Если в состав описательных реквизитов информационного объекта Студент включить фамилию старосты группы (Староста), которая определяется только номером группы, то одна и та же фамилия старосты будет многократно повторять­ся в разных экземплярах данного информационного объекта. В этом случае наблюдаются затруднения в корректировке фамилии старосты в случае назначения нового старосты, а также неоправданный расход памяти для хранения дублированной информации.

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

Пример 8. «Расщепление» информационного объекта, содержащего транзитив­ную зависимость описательных реквизитов, показано на рис. 5.6. Как видно из рис. 5.

6, исходный информационный объект Студент группы пред­ставляется в виде совокупности правильно структурированных информационных объ­ектов (Студент и Группа), реквизитный состав которых тождественен исходному объекту.

Отношение Студент = (Номер, Фамилия, Имя, Отчество, Дата, Группа) нахо­дится одновременно в первой, второй и третьей нормальной форме.

Рисунок 5.6. «Расщепление» информационного объекта, содержащего транзитив­ную зависимость описательных реквизитов.

Типы связей

Свойства отношений.

Отсутствие кортежей-дубликатов. Из этого свойства вытекает наличие у каждого кортежа первичного ключа. Для каждого отношения, по крайней мере, полный набор его атрибутов является первичным ключом.

Однако, при определении первичного ключа должно соблюдаться требование «минимальности», т.е.

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

Отсутствие упорядоченности кортежей.

Отсутствие упорядоченности атрибутов. Для ссылки на значение атрибута всегда используется имя атрибута.

Атомарность значений атрибутов, т.е. среди значений домена не могут содержаться множества значений (отношения).

Реляционные базы данных состоят из нескольких таблиц, связь между которыми устанавливается с помощью совпадающих полей. Каждая запись в таблицах идентифицирует один объект. Отношение между объектами определяет отношение между таблицами. Существует 4 типа отношений:

Отношение «один-к-одному» (1:1)означает, что каждая запись в одной таблице соответствует только одной записи в другой таблице.

Отношение «один-ко-многим» (1 :М)означает, что каждой записи в одной таблице соответствует одна или несколько записей в другой таблице.

Отношение «многие-ко-одному» (М:1)аналогично рассмотренному ранее типу. Тип отношения между объектами зависит от вашей точки зрения.

Отношение «многие-ко-многим» (М:М).возникает между двумя таблицами в тех случаях, когда:

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

Пример 9. Дана совокупность информационных объектов, отражающих учебный процесс в вузе:

СТУДЕНТ (Номер, Фамилия, Имя, Отчество, Пол, Дата рождения, Группа) СЕССИЯ (Номер, Оценка1, Оценка2, ОценкаЗ, Оценка4, Результат) СТИПЕНДИЯ (Результат, Процент) ПРЕПОДАВАТЕЛЬ (Код преподавателя. Фамилия, Имя, Отчество)

Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В и наоборот. Рисунок 5.7 иллюстрирует указанный тип отношения.

Рисунок 5.7. Графическое изображение реального отношения 1:1

Пример 10. Примером связи 1:1 может служить связь между информационными объектами СТУДЕНТ и СЕССИЯ:

СТУДЕНТ СЕССИЯ Каждый студент имеет определенный набор экзаменационных оценок в сессию.

При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объектаВ, но каждый экземпляр объекта В свя­зан не более чем с 1 экземпляром объекта А. Графически данное соответствие имеет вид, представленный на рисунок 5.8.

Рисунок 5.8. Графическое изображение реального отношения 1 :М

• Пример 11. Примером связи 1 :М служит связь между информационными объекта­ми СТИПЕНДИЯ и СЕССИЯ:
• СТИПЕНДИЯ

Источник: https://megaobuchalka.ru/2/18725.html

Третья нормальная форма (3NF) | Портал информатики для гиков

Хотя отношения второй нормальной формы (2NF) имеют меньшую избыточность, чем отношения в 1NF, они все же могут страдать от аномалий обновления. Если мы обновим только один кортеж, а не другой, база данных будет в несогласованном состоянии. Эта аномалия обновления вызвана переходной зависимостью. Нам нужно удалить такие зависимости, перейдя к третьей нормальной форме (3NF).

Третья нормальная форма (3NF): Отношение находится в третьей нормальной форме, если нет транзитивной зависимости для непростых атрибутов, а также во второй нормальной форме.

Отношение находится в 3NF, если хотя бы одно из следующих условий выполняется в каждой нетривиальной зависимости функции X -> Y:

1. Х супер ключ.
2. Y является основным атрибутом (каждый элемент Y является частью некоторого ключа-кандидата).

Другими словами,

A relation that is in First and Second Normal Form and in which no non-primary-key attribute is transitively dependent on the primary key, then it is in Third Normal Form (3NF).

Примечание. Если A-> B и B-> C — два FD, то A-> C называется транзитивной зависимостью.

Нормализация отношений 2NF к 3NF включает удаление транзитивных зависимостей. Если транзитивная зависимость существует, мы удаляем транзитивно зависимый атрибут (ы) из отношения, помещая атрибут (ы) в новое отношение вместе с копией определителя.

• Рассмотрим примеры, приведенные ниже.
• Пример-1: В отношении СТУДЕНТА, приведенного в Таблице 4,

1. FD набор: {STUD_NO -> STUD_NAME, STUD_NO -> STUD_STATE, STUD_STATE -> STUD_COUNTRY, STUD_NO -> STUD_AGE}
2. Ключ кандидата: {} STUD_NO

Для этого отношения в таблице 4 значения STUD_NO -> STUD_STATE и STUD_STATE -> STUD_COUNTRY имеют значение true. Таким образом, STUD_COUNTRY транзитивно зависит от STUD_NO. Это нарушает третью нормальную форму. Чтобы преобразовать его в третью обычную форму, мы разложим отношение STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY_STUD_AGE) следующим образом:

STUDENT (STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_AGE)
STATE_COUNTRY (STATE, COUNTRY)

Пример-2: Рассмотрим соотношение R (A, B, C, D, E)

A -> BC,
CD -> E,
B -> D,
E -> A

Все возможные ключи-кандидаты в вышеприведенном отношении являются {A, E, CD, BC}. Все атрибуты находятся справа от всех функциональных зависимостей, простых.

Заметка — Третья нормальная форма (3NF) рассматривается для нормального проектирования реляционных баз данных, поскольку большинство таблиц 3NF не содержит аномалий вставки, обновления и удаления. Более того, 3НФ.

Рекомендуемые посты:

Третья нормальная форма (3NF)

0.00 (0%) 0 votes

Источник: http://espressocode.top/third-normal-form-3nf/

Нормализация баз данных: третья нормальная форма

Последний пост про нормальные формы, перевод книги PHP 6 and MySQL 5 for Dynamic Web Sites. Предыдущие три вынесены ссылками в конце поста.

Третья нормальная форма

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

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

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

Все эти поля будут подчинены друг другу, а не человеку, к которому относится эта запись.

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

Если вы чувствуете, что все эти действия могут быть излишними, вы правы.  Честно, в верхних уровнях нормализации часто нет необходимости.

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

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

Чтобы привести базу к третьей нормальной форме, надо:

1. Определить, в каких полях каких таблиц имеется взаимозависимость. Как только что говорилось, поля, которые зависят больше друг от друга (как город от штата), чем от ряда в целом. В базе форума такой проблемы нет. Взглянув на таблицу сообщений, увидите, что каждый заголовок, каждое тело сообщения относится к своему message ID.

2. Создайте соответствующие таблицы. Если есть проблемный столбец в шаге 1, создавайте раздельные таблицы для него. Как города и штаты, в примере с клиентами.

3. Создайте или выделите первичные ключи. Каждая таблица должна иметь первичный ключ. Для примера с клиентами это будут city ID и state ID.

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

Рассмотренная в качестве примера база данных с записями о клиентах, созданы две новых таблицы для хранения информации о городах и штатах.

Подсказки:

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

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

Нарушения правил нормализации

Убедившись, что база данных в 3НФ поможет гарантировать надёжность и жизнеспособность, не нужно полностью нормализовывать все базу, с которыми вы работаете. Перед тем, как использовать эти методы, имейте ввиду, что это может иметь долгосрочные разрушающие последствия.

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

Вкратце, нормализация это сделка между целостностью/расширяемостью и простотой/скоростью.

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

Ссылки:

Источник: http://alexvolkov.ru/database-normalization-third-normal-form.html

Нормальные формы баз данных

Вы здесь:
Главная — MySQL — MySQL Основы — Нормальные формы баз данных.

Привет всем, и сегодня мы поговорим о том, что такое нормальные формы и как их правильно использовать.

Нормальные формы — это правила, которые должны соблюдаться при правильной проектировке базы данных.

Нормальных форм существует целых 6 штук, однако обычно соблюдают всего лишь 3 и этого более чем достаточно. Вот давайте их и разберем.

Первая нормальная форма

Чтобы была соблюдена первая форма, все данные в полях должны быть атомарны. Т.е. одно поле — одно значение.

Представим, например, что у нас есть таблица с учителями. Там есть поле «уроки», куда записываются те уроки, которые ведет данный учитель. У одного учителя может быть сразу несколько уроков, верно? И вы могли подумать, а почему бы не записывать их через запятую?

математика, русский

Но так ни в коем случае делать не стоит, ибо вы нарушите первую нормальную форму и выбирать данные будет не очень удобно, правда?

Чтобы это исправить, вы должны создать 2 записи с одним и тем же учителем.

1) Чемоданчиков	математика
2) Чемоданчиков	русский

Поздравляю! Первая нормальная форма выполнена. Давайте перейдем ко второй.

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

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

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

• Таблица с уроками
• Таблица с учителями
• Теперь заполним таблицу с учителями

id	Name	Second name
1	Сергей	Чемоданчиков
2	Игорь	Карапузиков
3	Петр	Первый

Вот такие учителя работают у нас. Теперь перейдем к таблице с уроками

id	Lesson	Teacher
1	математика	1
2	русский	1
3	литература	3

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

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

Поздравляю! Мы разобрались со второй нормальной формой. Перейдем к третьей, заключительной.

Третья нормальная форма

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

3. Например, у нас есть таблица с такими полями

Здесь у нас явно прослеживается транзитивная зависимость.

Зачем нам поле город, если у нас есть индекс? По индексу мы можем понять, что за город.

Итак, мы разобрались с тремя наиболее важными нормальными формами. Следите, чтобы ваши таблицы всегда были в этих формах. Удачного проектирования баз данных! 🙂

Предыдущая статья Следующая статья

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!

Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

1. Кнопка:

   Она выглядит вот так:

2. Текстовая ссылка:Как создать свой сайт

   Она выглядит вот так: Как создать свой сайт

3. BB-код ссылки для форумов (например, можете поставить её в подписи):
   [URL=»https://myrusakov.ru»]Как создать свой сайт[/URL]

Источник: https://MyRusakov.ru/databases-normal-forms.html

Нормализация отношений. Шесть нормальных форм

В данной теме я затрону 6 нормальных форм и методы приведения таблиц в эти формы.

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

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

Используемые термины

Атрибут — свойство некоторой сущности. Часто называется полем таблицы.

• Домен атрибута — множество допустимых значений, которые может принимать атрибут.
• Кортеж — конечное множество взаимосвязанных допустимых значений атрибутов, которые вместе описывают некоторую сущность (строка таблицы).
• Отношение — конечное множество кортежей (таблица).

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

Проекция — отношение, полученное из заданного путём удаления и (или) перестановки некоторых атрибутов.

Функциональная зависимость между атрибутами (множествами атрибутов) X и Y означает, что для любого допустимого набора кортежей в данном отношении: если два кортежа совпадают по значению X, то они совпадают по значению Y. Например, если значение атрибута «Название компании» — Canonical Ltd, то значением атрибута «Штаб-квартира» в таком кортеже всегда будет Millbank Tower, London, United Kingdom. Обозначение: {X} -> {Y}.

1. Нормальная форма — требование, предъявляемое к структуре таблиц в теории реляционных баз данных для устранения из базы избыточных функциональных зависимостей между атрибутами (полями таблиц).
2. Метод нормальных форм (НФ) состоит в сборе информации о объектах решения задачи в рамках одного отношения и последующей декомпозиции этого отношения на несколько взаимосвязанных отношений на основе процедур нормализации отношений.
3. Цель нормализации: исключить избыточное дублирование данных, которое является причиной аномалий, возникших при добавлении, редактировании и удалении кортежей(строк таблицы).

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

• Аномалии-модификации проявляются в том, что изменение одних данных может повлечь просмотр всей таблицы и соответствующее изменение некоторых записей таблицы.
• Аномалии-удаления — при удалении какого либо кортежа из таблицы может пропасть информация, которая не связана на прямую с удаляемой записью.
• Аномалии-добавления возникают, когда информацию в таблицу нельзя поместить, пока она не полная, либо вставка записи требует дополнительного просмотра таблицы.

Первая нормальная форма

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

Например, есть таблица «Автомобили»: Нарушение нормализации 1НФ происходит в моделях BMW, т.к. в одной ячейке содержится список из 3 элементов: M5, X5M, M1, т.е. он не является атомарным.

Преобразуем таблицу к 1НФ:

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

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

Например, дана таблица: Таблица находится в первой нормальной форме, но не во второй. Цена машины зависит от модели и фирмы. Скидка зависят от фирмы, то есть зависимость от первичного ключа неполная. Исправляется это путем декомпозиции на два отношения, в которых не ключевые атрибуты зависят от ПК.

Третья нормальная форма

Отношение находится в 3НФ, когда находится во 2НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа. Проще говоря, второе правило требует выносить все не ключевые поля, содержимое которых может относиться к нескольким записям таблицы в отдельные таблицы. Рассмотрим таблицу: Таблица находится во 2НФ, но не в 3НФ. В отношении атрибут «Модель» является первичным ключом.

Личных телефонов у автомобилей нет, и телефон зависит исключительно от магазина. Таким образом, в отношении существуют следующие функциональные зависимости: Модель → Магазин, Магазин → Телефон, Модель → Телефон. Зависимость Модель → Телефон является транзитивной, следовательно, отношение не находится в 3НФ.

В результате разделения исходного отношения получаются два отношения, находящиеся в 3НФ:

Нормальная форма Бойса-Кодда (НФБК) (частная форма третьей нормальной формы)

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

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

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

• «Бережливый»: стоянка 1 для льготников
• «Стандарт»: стоянка 1 для не льготников
• «Премиум-А»: стоянка 2 для льготников
• «Премиум-B»: стоянка 2 для не льготников.

Таким образом, возможны следующие составные первичные ключи: {Номер стоянки, Время начала}, {Номер стоянки, Время окончания}, {Тариф, Время начала}, {Тариф, Время окончания}. Отношение находится в 3НФ. Требования второй нормальной формы выполняются, так как все атрибуты входят в какой-то из потенциальных ключей, а неключевых атрибутов в отношении нет.

Также нет и транзитивных зависимостей, что соответствует требованиям третьей нормальной формы. Тем не менее, существует функциональная зависимость Тариф → Номер стоянки, в которой левая часть (детерминант) не является потенциальным ключом отношения, то есть отношение не находится в нормальной форме Бойса — Кодда.

Недостатком данной структуры является то, что, например, по ошибке можно приписать тариф «Бережливый» к бронированию второй стоянки, хотя он может относиться только к первой стоянки.

Можно улучшить структуру с помощью декомпозиции отношения на два и добавления атрибута Имеет льготы, получив отношения, удовлетворяющие НФБК (подчёркнуты атрибуты, входящие в первичный ключ.):

Тарифы

Бронирование

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

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

В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.

B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С.

Предположим, что рестораны производят разные виды пиццы, а службы доставки ресторанов работают только в определенных районах города. Составной первичный ключ соответствующей переменной отношения включает три атрибута: {Ресторан, Вид пиццы, Район доставки}. Такая переменная отношения не соответствует 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.

Работники

Переменная отношения «Работники» не находится в 6НФ и может быть подвергнута декомпозиции на переменные отношения «Должности работников» и «Домашние адреса работников».

Должности работников

Домашние адреса работников

Литература

Источник: https://habr.com/post/254773/

Реляционные базы данных | Третья нормальная форма

Последнее обновление: 02.07.2017

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

Транзитивная функциональная зависимость выражается следующим образом: А → В и В → С. То есть атрибут С транзитивно зависит от атрибута А, если атрибут С зависит от атрибута В, а атрибут В зависит от атрибута А (при условии, что атрибут А функционально не зависит ни от атрибута В, ни от атрибута С).

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

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

При применении третьей нормальной формы таблица должна находиться во второй нормальной форме. 3NF позволяет значительно снизить избыточность данных.

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

CourseId	Course	TeacherId	Teacher	Position
1	Математика	1	Смит	Профессор
2	JavaScript	2	Адамс	Ассистент
3	Алгоритмы	2	Адамс	Ассистент

• Какие функциональные зависимости здесь можно выделить:
• CourseId → Course, TeacherId, Teacher, Position
• Course → CourseId, TeacherId, Teacher, Position
• TeacherId → Teacher, Position
• Вторая зависимость фактически аналогична первой и говорит о том, что атрибут Course является потенциальным ключом.

Третья зависимость говорит о том, что, зная идентификатор преподавателя, мы можем узнать его фамилию и должность. То есть через атрибут TeacherId атрибуты Teacher и Position зависят от CourseId (CourseId→ TeacherId и TeacherId → Teacher, Position). И в данном случае мы можем говорить о транзитивной зависимости Teacher, Position от CourseId.

Для нормализации необходимо вынести в отдельную таблицу атрибуты TeacherId, Teacher, Position. Для этого пусть будет отдельная таблица Teachers:

TeacherId	Teacher	Position
1	Смит	Профессор
2	Адамс	Ассистент

А таблица Courses сократится следующим образом:

CourseId	Course	TeacherId
1	Математика	1
2	JavaScript	2
3	Алгоритмы	2

Источник: https://metanit.com/sql/tutorial/2.4.php

Третья нормальная форма — это… Что такое Третья нормальная форма?

Третья нормальная форма (англ. 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 выполняется хотя бы одно из следующих условий:

• Х содержит А (то есть X → A — тривиальная функциональная зависимость)
• Х — суперключ
• А — ключевой атрибут (то есть А входит в состав потенциального ключа).

Определение Заниоло четко определяет разницу между 3NF и более строгой нормальной формой Бойса-Кодда (НФБК): НФБК исключает третье условие («А — ключевой атрибут»).

«Ничего, кроме ключа»

Запоминающееся и, по традиции, наглядное резюме определения 3NF Кодда было дано Биллом Кентом: каждый неключевой атрибут «должен предоставлять информацию о ключе, полном ключе и ни о чём, кроме ключа».[1]

Условие зависимости от «полного ключа» неключевых атрибутов обеспечивает то, что таблица находится во второй нормальной форме; а условие зависимости их от «ничего, кроме ключа» — то, что они находятся в третьей нормальной форме.

Крис Дэйт говорит о резюме Кента как о «интуитивно привлекательной характеристике» 3NF, и замечает, что с небольшим изменением она может служить и как определение более строгой нормальной формы Бойса-Кодда: «Каждый атрибут должен предоставлять информацию о ключе, полном ключе и ни о чём, кроме ключа».

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

Здесь следует отметить, что это правило справедливо только для неключевых атрибутов, так как применение его ко всем атрибутам будет полностью запрещать все сложные альтернативные ключи, поскольку каждый элемент такого ключа будет нарушать условие «полного ключа».

Пример

Рассмотрим в качестве примера отношение, которое находится во 2NF, но не соответствует 3NF:

R1

Сотрудник
Отдел
Телефон

Гришин	Бухгалтерия

Источник: https://dic.academic.ru/dic.nsf/ruwiki/160256

4. Третья нормальная форма (3NF)

4. Третья нормальная форма (3NF)

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

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

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

Проиллюстрируем процесс приведения ненормализованного отношения к третьей нормальной форме. Для этого рассмотрим пример: отношение, находящееся не в третьей нормальной форме.

Итак, вариант 1 схемы отношения «Сотрудники»:

Сотрудники (№ табельный, Фамилия, Имя, Отчество, Код должности, Оклад);

Primary key (№ табельный);

Кроме того, над данным отношением «Сотрудники» задана следующая система функциональных зависимостей:

{Код должности} ? {Оклад};

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

• Именно поэтому это отношение «Сотрудники» и не находится в третьей нормальной форме, ведь получается, что неключевой атрибут «Оклад» полностью функционально зависит от атрибута «Код должности», хотя этот атрибут и не является ключевым.
• Любопытно, что к третьей нормальной форме любое отношение приводится точно таким же методом, как и к двум формам до этой, а именно, путем декомпозиции.
• Проведя декомпозицию отношения «Сотрудники», получим следующую систему новых самостоятельных отношений:
• Итак, вариант 2 схемы отношения «Сотрудники»:

1. Должности (Код должности, Оклад);
2. Primary key (Код должности);
3. Сотрудники (№ табельный, Фамилия, Имя, Отчество, Код должности);
4. Primary key (Код должности);
5. Foreign key (Код должности) references Должности (Код должности);

Теперь, как мы видим, в отношении «Должности» неключевой атрибут «Оклад» полностью функционально зависит от простого первичного ключа «Код должности» и только от этого ключа.

Заметим, что в отношении «Сотрудники» все четыре неключевых атрибута «Фамилия», «Имя», «Отчество» и «Код должности» полностью функционально зависят от простого первичного ключа «№ табельный». В этом отношении атрибут «Код должности» – внешний ключ, ссылающийся на первичный ключ отношения «Должности».

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

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

Следующая глава

Источник: https://it.wikireading.ru/32661

Database normalization description — Office

• 3/16/2020
• Время чтения: 5 мин
• Применяется к: Microsoft Office Access 2007, Microsoft Office Access 2003

Original KB number:   283878

This article explains database normalization terminology for beginners. A basic understanding of this terminology is helpful when discussing the design of a relational database.

Description of normalization

Normalization is the process of organizing data in a database. This includes creating tables and establishing relationships between those tables according to rules designed both to protect the data and to make the database more flexible by eliminating redundancy and inconsistent dependency.

Redundant data wastes disk space and creates maintenance problems. If data that exists in more than one place must be changed, the data must be changed in exactly the same way in all locations. A customer address change is much easier to implement if that data is stored only in the Customers table and nowhere else in the database.

What is an «inconsistent dependency»? While it is intuitive for a user to look in the Customers table for the address of a particular customer, it may not make sense to look there for the salary of the employee who calls on that customer.

The employee's salary is related to, or dependent on, the employee and thus should be moved to the Employees table. Inconsistent dependencies can make data difficult to access because the path to find the data may be missing or broken.

There are a few rules for database normalization. Each rule is called a «normal form.» If the first rule is observed, the database is said to be in «first normal form.

» If the first three rules are observed, the database is considered to be in «third normal form.

» Although other levels of normalization are possible, third normal form is considered the highest level necessary for most applications.

As with many formal rules and specifications, real world scenarios do not always allow for perfect compliance.

In general, normalization requires additional tables and some customers find this cumbersome.

The following descriptions include examples.

First normal form

• Eliminate repeating groups in individual tables.
• Create a separate table for each set of related data.
• Identify each set of related data with a primary key.

Do not use multiple fields in a single table to store similar data.

For example, to track an inventory item that may come from two possible sources, an inventory record may contain fields for Vendor Code 1 and Vendor Code 2.

What happens when you add a third vendor? Adding a field is not the answer; it requires program and table modifications and does not smoothly accommodate a dynamic number of vendors. Instead, place all vendor information in a separate table called Vendors, then link inventory to vendors with an item number key, or vendors to inventory with a vendor code key.

Second normal form

• Create separate tables for sets of values that apply to multiple records.
• Relate these tables with a foreign key.

Records should not depend on anything other than a table's primary key (a compound key, if necessary).

For example, consider a customer's address in an accounting system. The address is needed by the Customers table, but also by the Orders, Shipping, Invoices, Accounts Receivable, and Collections tables.

Instead of storing the customer's address as a separate entry in each of these tables, store it in one place, either in the Customers table or in a separate Addresses table.

Third normal form

• Eliminate fields that do not depend on the key.

Values in a record that are not part of that record's key do not belong in the table. In general, anytime the contents of a group of fields may apply to more than a single record in the table, consider placing those fields in a separate table.

For example, in an Employee Recruitment table, a candidate's university name and address may be included. But you need a complete list of universities for group mailings.

If university information is stored in the Candidates table, there is no way to list universities with no current candidates.

Create a separate Universities table and link it to the Candidates table with a university code key.

EXCEPTION: Adhering to the third normal form, while theoretically desirable, is not always practical.

If you have a Customers table and you want to eliminate all possible interfield dependencies, you must create separate tables for cities, ZIP codes, sales representatives, customer classes, and any other factor that may be duplicated in multiple records. In theory, normalization is worth pursing. However, many small tables may degrade performance or exceed open file and memory capacities.

It may be more feasible to apply third normal form only to data that changes frequently. If some dependent fields remain, design your application to require the user to verify all related fields when any one is changed.

Other normalization forms

Fourth normal form, also called Boyce Codd Normal Form (BCNF), and fifth normal form do exist, but are rarely considered in practical design. Disregarding these rules may result in less than perfect database design, but should not affect functionality.

Normalizing an example table

These steps demonstrate the process of normalizing a fictitious student table.

1. Unnormalized table:

   Student#
   Advisor
   Adv-Room
   Class1
   Class2
   Class3
   

   1022	Jones	412	101-07	143-01	159-02
   4123	Smith	216	201-01	211-02	214-01

2. First normal form: No repeating groups

   Tables should have only two dimensions. Since one student has several classes, these classes should be listed in a separate table. Fields Class1, Class2, and Class3 in the above records are indications of design trouble.

   Spreadsheets often use the third dimension, but tables should not. Another way to look at this problem is with a one-to-many relationship, do not put the one side and the many side in the same table. Instead, create another table in first normal form by eliminating the repeating group (Class#), as shown below:

   Student#
   Advisor
   Adv-Room
   Class#
   

   1022	Jones	412	101-07
   1022	Jones	412	143-01
   1022	Jones	412	159-02
   4123	Smith	216	201-01
   4123	Smith	216	211-02
   4123	Smith	216	214-01

3. Second normal form: Eliminate redundant data

   Note the multiple Class# values for each Student# value in the above table. Class# is not functionally dependent on Student# (primary key), so this relationship is not in second normal form.

   The following two tables demonstrate second normal form:

   Students:

   Student#
   Advisor
   Adv-Room
   

   1022	Jones	412
   4123	Smith	216

   Registration:

   Student#
   Class#
   

   1022	101-07
   1022	143-01
   1022	159-02
   4123	201-01
   4123	211-02
   4123	214-01

4. • Third normal form: Eliminate data not dependent on key
   • In the last example, Adv-Room (the advisor's office number) is functionally dependent on the Advisor attribute. The solution is to move that attribute from the Students table to the Faculty table, as shown below:
   • Students:
   Student#
   Advisor
   

   1022	Jones
   4123	Smith

   Faculty:

   Name
   Room
   Dept
   

   Jones	412	42
   Smith	216	42

Источник: https://support.microsoft.com/ru-ru/help/283878.