Функциональные зависимости в отношениях dept н locstatus
|
Пример таблицы DEPT.
|
||
|
DEPTNO
|
DNAME
|
LOC
|
|
10
|
ACCOUNTING
|
NEW YORK
|
|
20
|
RESEARCH
|
DALLAS
|
|
30
|
SALES
|
CHICAGO
|
|
40
|
OPERATIONS
|
BOSTON
|
|
Пример таблицы LOCSTATUS
|
|
|
LOC
|
STATUS
|
|
NEW YORK
|
300
|
|
DALLAS
|
200
|
|
CHICAGO
|
400
|
|
BOSTON
|
300
|
|
ATLANTA
|
500
|
Процесс опять-таки обратим: RNF2 является соединением DEPT и LOCSTATUS по LOC (один столбец LOC исключается).
Должно быть ясно, что новая структура преодолевает все перечисленные выше проблемы при выполнении операций запоминания, касающиеся связи LOCSTATUS.
Сравнивая RNF2 и DEPT/LOCSTATUS, мы видим, что результатом дальнейшего преобразования стало устранение транзитивной зависимости STATUS от DEPTNO.
Теперь дадим определение третьей нормальной формы.
Отношение R находится в третьей нормальной форме (ЗНФ), если оно находится в 2НФ и каждый неключевой атрибут нетранэитивно зависит от первичного ключа.
Отношения DEPT и LOCSTATUS оба находятся в ЗНФ, а отношение RNF2 -нет. (Первичными ключами для DEPT и LOCSTATUS являются DEPTNO и LOC соответственно).
Отношение, находящееся во второй нормальной форме и не находящееся в третьей, всегда может быть преобразовано в эквивалентную совокупность отношений ЗНФ. Этот процесс обратим и, следовательно, никакая информация при преобразовании не теряется.
Однако отношение ЗНФ может содержать информацию, например, о том, что статус Атланты равен 500, которая не может быть представлена в исходном отношении, находящемся в 2НФ. Так же, как структура RNF2/EMPLO была несколько лучшим представлением реального мира, чем находящееся в 1НФ этношение RNF1, так и структура DEPT/LOCSTATUS является несколько лучшим представлением реального мира, чем находящееся в 2НФ отношение RNF2.
Подчеркнём, что уровень нормализации данного отношения определяется семантикой, а не значениями данных, которые появились в отношении в некоторый конкретный момент времени. Невозможно по содержанию таблицы данного угношения в данный момент сказать, находится или нет это отношение, например, в ЗНФ. Перед тем как сделать такое заключение, необходимо знать смысл данных, т. е. имеющиеся зависимости между ними. В частности, СУБД не может гарантировать, что отношение поддерживается в "наиболее удобной форме", без получения информации о всех соответствующих зависимостях. Для отношения в ЗНФ, однако, все, что необходимо сообщить СУБД об этих зависимостях, заключается только в указании атрибута(ов), составляющего первичный ключ. СУБД тогда будет знать, что все остальные атрибуты являются функционально-зависимыми от этого атрибута или от комбинации атрибутов, и сможет поддерживать это ограничение). Для отношения, которое не находится в ЗНФ, необходимы ещё и дополнительные спецификации.