Номер поставщика
PNUM
|
Наименование поставщика
PNAME
|
Номер детали
DNUM
|
Поставляемое количество
VOLUME
|
1
|
Фирма 1
|
1
|
100
|
1
|
Фирма 1
|
2
|
200
|
1
|
Фирма 1
|
3
|
300
|
2
|
Фирма 2
|
1
|
150
|
2
|
Фирма 2
|
2
|
250
|
3
|
Фирма 3
|
1
|
1000
|
Таблица 1 Отношение "Поставки"
Данное отношение содержит два потенциальных ключа - {PNUM, DNUM} и {PNAME, DNUM}. Видно, что данные хранятся в отношении с избыточностью - при изменении наименования поставщика, это наименование нужно изменить во всех кортежах, где оно встречается. Можно ли эту аномалию устранить при помощи алгоритма нормализации, описанного в предыдущей главе? Для этого нужно выявить имеющиеся функциональные зависимости (как обычно, курсивом выделены ключевые атрибуты):
PNUM PNAME - наименование поставщика зависит от номера поставщика.
PNAME PNUM - номер поставщика зависит от наименования поставщика.
{PNUM, DNUM} VOLUME - поставляемое количество зависит от первого ключа отношения.
{PNUM, DNUM} PNAME - наименование поставщика зависит от первого ключа отношения.
{PNAME, DNUM} VOLUME - поставляемое количество зависит от второго ключа отношения.
{PNAME, DNUM} PNUM - номер поставщика зависит от второго ключа отношения.
Данное отношение не содержит неключевых атрибутов, зависящих от части сложного ключа (см. определение 2НФ). Действительно, от части сложного ключа зависят атрибуты PNAME и PNUM, но они сами являются ключевыми. Таким образом, отношение находится в 2НФ.
Кроме того, отношение не содержит зависимых друг от друга неключевых атрибутов, т.к. неключевой атрибут всего один - VOLUME (см. определение 3НФ). Таким образом, показано, что отношение "Поставки" находится в 3НФ.
Таким образом, описанный ранее алгоритм нормализации неприменим к данному отношению. Очевидно, однако, что аномалия данного отношения устраняется путем декомпозиции его на два следующих отношения:
Достарыңызбен бөлісу: |