Полная функциональная зависимость в нормализации базы данных

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

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

Краткое изложение первой нормальной формы

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

Например, следующая таблица не соответствует 1NF, потому что сотрудник Tina связан с двумя местоположениями, оба из которых находятся в одной ячейке:

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

Разрешение такого дизайна может отрицательно повлиять на обновления данных или записи. Чтобы обеспечить соответствие 1NF, переставьте таблицу так, чтобы все атрибуты (или ячейки столбцов) содержали одно значение:

Соответствие первой нормальной форме

Расположение сотрудников Джон Лос-Анджелес Тина Лос-Анджелес Тина Чикаго

Но 1NF все еще недостаточно, чтобы избежать проблем с данными.

Как 2NF работает для обеспечения полной зависимости

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

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

Если атрибут A определяет значение B, мы пишем это A -> B – это означает, что B функционально зависит от A. В этих отношениях A определяет значение B, а B зависит от A.

Например, в следующей таблице Отделы сотрудников EmployeeID и DeptID являются ключами-кандидатами: EmployeeID – это первичный ключ таблицы, а DeptID – внешний ключ. Любой другой атрибут – в данном случае EmployeeName и DeptName – должен зависеть от первичного ключа для получения его значения.

Отделы персонала

В этом случае таблица не является полностью зависимой, поскольку, хотя EmployeeName зависит от первичного ключа EmployeeID, DeptName зависит вместо этого от DeptID. Это называется частичная зависимость .

Чтобы эта таблица соответствовала 2NF, нам нужно разделить данные на две таблицы:

Сотрудники

Мы удаляем атрибут DeptName из таблицы Сотрудники и создаем новую таблицу Отделы :

Отделы

Теперь отношения между таблицами полностью зависимы или в 2NF.

Почему важна полная зависимость

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

Например, рассмотрим таблицу в разделе выше, которая придерживается только 1NF. Вот и снова:

Соответствие первой нормальной форме

У Тины две записи. Если мы обновим один, не осознавая, что их два, результатом будут противоречивые данные.

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

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