ЧТО ТАКОЕ ТРЕТЬЯ НОРМАЛЬНАЯ ФОРМА? (БАЗЫ ДАННЫХ) - ТЕХНОЛОГИЯ - 2025

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

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

Источник: pixabay.com

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

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

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

Нормальные формы

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

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

Первая нормальная форма (1FN)

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

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

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

Вторая нормальная форма (2FN)

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

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

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

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

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

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

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

Следовательно, чтобы отношение в базе данных было в третьей нормальной форме, оно должно соответствовать:

- Все требования 2FN.

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

Примеры третьей нормальной формы

Пример 1

Пусть таблица будет STUDENT, первичный ключ которой является идентификатором студента (STUDENT_ID) и состоит из следующих атрибутов: STUDENT_NAME, STREET, CITY и POST_CODE, удовлетворяющих условиям, чтобы быть 2FN.

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

Поскольку студент находится на сайте, определенном CODE_POSTAL, STREET и CITY связаны с этим атрибутом. Из-за этой второй степени зависимости нет необходимости хранить эти атрибуты в таблице STUDENT.

Создать новую таблицу

Предположим, что есть несколько студентов, расположенных в одном и том же почтовом индексе, а таблица STUDENT содержит огромное количество записей, и требуется изменить название улицы или города, тогда эта улица или город должны быть найдены и обновлены во всей таблице УЧЕНИК.

Например, если вам нужно изменить улицу «Эль-Лимон» на «Эль-Лимон II», вам нужно будет выполнить поиск «Эль-Лимон» во всей таблице СТУДЕНТ, а затем обновить ее до «Эль-Лимон II».

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

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

В таблице POST будет сравнительно меньше записей, и эту таблицу POST нужно будет обновить только один раз. Это будет автоматически отражено в таблице STUDENT, что упростит базу данных и запросы. Итак, таблицы будут в 3FN:

Пример 2

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

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

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

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

Для соответствия третьей нормальной форме создается новая таблица (Менеджеры) для решения проблемы. Обе таблицы связаны через поле Project_Manager:

Ссылки

1. Терадата (2019). Первая, вторая и третья нормальные формы. Взято с: docs.teradata.com.
2. Обучающий кубок (2019). Третья нормальная форма (3NF). Взято с: tutorialcup.com.
3. Разработка базы данных (2015). Третья нормальная форма (3NF) - нормализация вашей базы данных. Взято с: databasedev.co.uk.
4. Дизайн реляционных БД (2019). Введение в третью нормальную форму. Взято с сайта relationaldbdesign.com.
5. Манекены (2019). Первая, вторая и третья нормальные формы SQL. Взято с: dummies.com.