Четвертая нормальная форма (4NF) базы данных

Приветствую Вас на сайте Info-Comp.ru! Сегодня мы с Вами подробно рассмотрим четвертую нормальную форму (4NF) базы данных, Вы узнаете, какие требования предъявляются к таблицам, чтобы база данных находилась в четвертой нормальной форме, и для наглядности мы рассмотрим несколько примеров.

Четвертая нормальная форма (4NF) базы данных

Перед тем как переходить к процессу приведения таблиц базы данных до четвертой нормальной формы, необходимо чтобы эти таблицы уже находились в третьей нормальной форме или, если первичный ключ составной, в нормальной форме Бойса-Кодда, подробно процесс приведения таблиц базы данных до этих форм мы рассматривали в предыдущих материалах:

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

Требования четвертой нормальной формы (4NF)

Требование четвертой нормальной формы (4NF) заключается в том, чтобы в таблицах отсутствовали нетривиальные многозначные зависимости.

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

Начнем с того, что таблица должна иметь как минимум три столбца, допустим A, B и C, при этом B и C между собой никак не связаны и не зависят друг от друга, но по отдельности зависят от A, и для каждого значения A есть множество значений B, а также множество значений C.

В данном случае многозначная зависимость обозначается вот так:

A —> B

A —> C

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

Заметка! Как создать базу данных в PostgreSQL с помощью pgAdmin 4.

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

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

Курсы.

Идентификатор курса Название курса
1 SQL
2 Python
3 JavaScript

Преподаватели.

Идентификатор преподавателя ФИО
1 Иванов И.И.
2 Сергеев С.С.
3 John Smith

Аудитории.

Идентификатор аудитории Название аудитории
1 101
2 203
3 305
4 407
5 502

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

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

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

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

Заметка! Как создать таблицу в PostgreSQL с помощью pgAdmin 4.

Таблица связей курсов, преподавателей и аудиторий.

Курс Преподаватель Аудитория
SQL Иванов И.И. 101
SQL Иванов И.И. 203
SQL Сергеев С.С. 305
SQL Сергеев С.С. 407
Python John Smith 502
Python John Smith 305

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

Курс ->-> Преподаватель

Курс ->-> Аудитория

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

При этом, Вы понимаете, что преподавателю без разницы, в какой аудитории читать лекцию, ровно так же как и самой аудитории без разницы, какой преподаватель в ней будет работать))

Иными словами, эти два атрибута «Преподаватель» и «Аудитория» никак не зависят друг от друга, но они оба по отдельности зависят от курса.

Но что же плохого в этой таблице и в этой многозначной зависимости? Вы можете спросить.

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

Что будет если, например, преподаватель «Иванов И.И.» уволился? Нам нужно будет удалить две строки из этой таблицы, но удалив эти строки, мы удалим всю информацию и о аудиториях 101 и 203. Но они на самом-то деле есть и должны участвовать в планировании расписания. Это аномалия, и это плохо.

Или другая ситуация, что будет, если курсу назначен преподаватель, но аудитория еще не определена? Или наоборот, с аудиторией уже определились, а вот преподаватель еще не известен.

Мы должны создать записи либо с NULL либо со значениями по умолчанию, и это также является аномалией.

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

Поэтому главное правило четвертой нормальной формы звучит следующим образом:

В таблице не должно быть многозначных зависимостей

Решение в данном случае как всегда – декомпозиция.

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

Связь курсов и преподавателей.

Курс Преподаватель
SQL Иванов И.И.
SQL Сергеев С.С.
Python John Smith

Связь курсов и аудиторий.

Курс Аудитория
SQL 101
SQL 203
SQL 305
SQL 407
Python 502
Python 305

Заметка! FULL JOIN в MySQL – не поддерживается, как реализовать?

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

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

Таблица связей студентов, курсов и хобби.

Студент Курс Хобби
Иванов И.И. SQL Футбол
Иванов И.И. Java Хоккей
Сергеев С.С. SQL Волейбол
Сергеев С.С. SQL Теннис
John Smith Python Футбол
John Smith Java Теннис

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

Отсюда следует, что каждый студент может посещать несколько курсов и иметь несколько увлечений.

Первичный ключ здесь также составной и состоит он из всех трех столбцов.

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

Таким образом, мы можем наблюдать в этой таблице нетривиальную многозначную зависимость

Студент ->-> Курс

Студент ->-> Хобби

Поэтому эта таблица не находится в четвертой нормальной форме.

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

Допустим, нам необходимо получить информацию о хобби студентов, которые посещают курс по SQL. Очевидным действием станет выборка с условием Курс = SQL, в результате мы получим 3 хобби: футбол, волейбол и теннис.

Результат выборки. Хобби студентов, которые посещают курс по SQL.

Студент Курс Хобби
Иванов И.И. SQL Футбол
Сергеев С.С. SQL Волейбол
Сергеев С.С. SQL Теннис

Однако, если мы заглянем в исходную таблицу, то мы четко увидим, что «Иванов И.И.» посещает курс по SQL и имеет хобби «Хоккей», но в нашей выборке этого хобби нет.

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

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

 Связь студентов и курсов.

Студент Курс
Иванов И.И. SQL
Иванов И.И. Java
Сергеев С.С. SQL
John Smith Python
John Smith Java

Связь студентов и хобби.

Студент Хобби
Иванов И.И. Футбол
Иванов И.И. Хоккей
Сергеев С.С. Волейбол
Сергеев С.С. Теннис
John Smith Футбол
John Smith Теннис

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

И если говорить о реальных данных, то нормализация до четвертой нормальной формы, как и до всех последующих, в современном мире практически не встречается. Если четвертую нормальную форму еще как-то можно представить и даже встретить данные, нормализованные до этой формы, то встретить данные, нормализованные до 5 или 6 нормальной формы, практически невозможно.

Заметка! ТОП 5 популярных систем управления базами данных (СУБД).

Вы можете спросить, а почему не нормализуют данные до 5 или 6 нормальной формы? Ведь каждая нормальная форма устраняет определенные аномалии, и если сделать полностью нормализованную базу данных, то по сути она будет идеальная, не содержащая ни одной аномалии, это же хорошо.

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

Обычно во всех источниках приводится два основных глобальных преимущества:

  • Устранение аномалий
  • Повышение производительности

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

Да, нормализация повышает производительность, но только где-то до 3 нормальной формы. Начиная с 4 нормальной формы, производительность увеличиваться не будет, более того, с каждой новой формой производительность будет значительно снижаться, не говоря уже о том, что с нормализованной базой данных до 5 или 6 нормальной формы будет крайне сложно и неудобно работать и сопровождать ее, ведь с каждой новой формой мы значительно увеличиваем количество таблиц в базе данных.

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

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

Полностью нормализованная база данных – это плохая база данных.

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

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

Заметка! Пятая нормальная форма (5NF) базы данных.

На сегодня это все, надеюсь, материал был Вам полезен, пока!

Понравилась статья? Поделиться с друзьями:
Заметки IT специалиста
Комментарии: 3
  1. TanVan

    «Однако, если мы заглянем в исходную таблицу, то мы четко увидим, что «Иванов И.И.» посещает курс по SQL и имеет хобби «Хоккей», но в нашей выборке этого хобби нет»

    Но в таблице по другому:
    «Иванов И.И.» Java Хоккей :?:

    1. Админ (автор)

      «Иванов И.И.» имеет 2 хобби: Футбол и Хоккей (о чем свидетельствует 2 записи в таблице), при этом он посещает курс по SQL (как и курс по Java), но если сделать выборку с условием «Курс = SQL», то хобби «Хоккей» там вообще не будет, однако у Иванова такое хобби есть.
      В результате наша выборка некорректна, так как нам нужно было узнать «хобби студентов, которые посещают курс по SQL», т.е. мы получили 3 хобби (футбол, волейбол и теннис), но фактически студенты, которые посещают курс по SQL, имеют 4 вида хобби.

  2. Алексей

    >Что будет если, например, преподаватель «Иванов И.И.» уволился? Нам нужно будет удалить две строки из этой таблицы, но удалив эти строки, мы удалим всю информацию и о аудиториях 101 и 203. Но они на самом-то деле есть и должны участвовать в планировании расписания. Это аномалия, и это плохо.

    Почему отсутствие информации об аудитория 101 и 203 в таблице курсов — это аномалия?
    Ведь значения 101 и 203 никуда не пропали из таблицы аудиторий.

    Ведь с таким же успехом можно сказать, что аномалия это когда в университет приходит новый преподаватель (или открывается новый учебный корпус).
    Неужели есть требование, чтобы в таблице _назначенных_ курсов-преподавателей-аудитории были _все_ значения из исходных таблиц?

Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:
Нажимая на кнопку «Отправить комментарий», я даю согласие на обработку персональных данных и принимаю политику конфиденциальности.