Полная функциональная зависимость - это состояние нормализации базы данных, которое соответствует стандарту нормализации второй нормальной формы (2NF). Короче говоря, это означает, что он отвечает требованиям первой нормальной формы (1NF), и все неключевые атрибуты полностью функционально зависят от первичного ключа.
Это не так сложно, как может показаться. Давайте рассмотрим это более подробно.
Резюме первой нормальной формы
Прежде чем база данных будет полностью функционально зависима, она должна сначала соответствовать первой нормальной форме.
Все это означает, что каждый атрибут должен содержать одно атомное значение.
Например, в следующей таблице не соответствуют 1NF, потому что сотрудник Tina связан с двумя местоположениями, причем оба они находятся в одной ячейке:
| Работник | Место нахождения |
|---|---|
| Джон | Лос-Анджелес |
| Тина | Лос-Анджелес, Чикаго |
Разрешение этой конструкции может негативно повлиять на обновления данных или записи. Чтобы обеспечить соответствие 1NF, переставьте таблицу так, чтобы все атрибуты (или ячейки столбцов) содержали одно значение:
Первое соответствие нормальной форме
Но 1NF все еще недостаточно, чтобы избежать проблем с данными.
Как работает 2NF для обеспечения полной зависимости
Чтобы быть полностью зависимыми, все атрибуты ключа не-кандидата должны зависеть от первичного ключа. (Помните, что атрибут ключевого ключа - это любой ключ (например, первичный или внешний ключ), используемый для уникальной идентификации записи базы данных.
Разработчики баз данных используют обозначения для описания зависимых отношений между атрибутами:
Если атрибут A определяет значение B, мы пишем этоA -> B- означает, что B функционально зависит от A. В этом отношении A определяет значение B, а B зависит от A.
Например, в следующем Отделы сотрудников table, EmployeeID и DeptID являются обеими ключами-кандидатами: EmployeeID является основным ключом таблицы, а DeptID - внешним ключом.
Любой другой атрибут - в этом случае EmployeeName и DeptName - должен зависеть от первичного ключа, чтобы получить его значение.
| EmployeeID | Имя сотрудника | DeptID | DEPTNAME |
|---|---|---|---|
| Emp1 | Джон | Dept001 | финансов |
| етр2 | Тина | Dept003 | Продажи |
| Emp3 | Carlos | Dept001 | финансов |
В этом случае таблица не полностью зависит от того, что, поскольку имя EmployeeName зависит от первичного ключа EmployeeID, вместо этого DeptName зависит от DeptID. Это называется частичная зависимость .
Чтобы таблица соответствовала 2NF, нам необходимо разделить данные на две таблицы:
| EmployeeID | Имя сотрудника | DeptID |
|---|---|---|
| Emp1 | Джон | Dept001 |
| етр2 | Тина | Dept003 |
| Emp3 | Carlos | Dept001 |
Мы удаляем атрибут DeptName из Сотрудники таблицы и создать новую таблицу ведомства :
| DeptID | DEPTNAME |
|---|---|
| Dept001 | финансов |
| Dept002 | Отдел кадров |
| Dept003 | Продажи |
Теперь отношения между таблицами полностью зависят или в 2NF.
Почему важна полная зависимость
Полная зависимость между атрибутами базы данных помогает обеспечить целостность данных и избежать аномалий данных.
Например, рассмотрим таблицу в разделе выше, который придерживается только 1NF. Вот оно, опять:
| Работник | Место нахождения |
|---|---|
| Джон | Лос-Анджелес |
| Тина | Лос-Анджелес |
| Тина | Чикаго |
У Тины две записи. Если мы обновим его, не осознавая, что их два, результатом будут несогласованные данные.
Или, что, если мы хотим добавить сотрудника в эту таблицу, но мы еще не знаем местоположение? Нам может быть отказано в добавлении нового сотрудника, если атрибут Location не допускает значения NULL.
Полная зависимость - это не вся картина, хотя, когда дело доходит до нормализации. Вы должны убедиться, что ваша база данных находится в третьей нормальной форме (3NF).
