Всегда ли следует стремиться к BCNF?

Предположим теперь, что в организации все проекты включают разные задания, и по-прежнему каждый служащий может участвовать в нескольких проектах, но может выполнять в каждом проекте только одно задание. Одно задание в каждом проекте могут выполнять несколько служащих. Тогда переменная отношения СЛУЖ_ПРО_ЗАДАН имеет множество FD, показанное на рис. 7.9, и может содержать значение, показанное на том же рисунке.

Диаграмма FD отношения СЛУЖ_ПРО_ЗАДАН(новый вариант)

Значение переменной отношения СЛУЖ_ПРО_ЗАДАН(новый вариант)

Рис. 7.9. Новый вариант переменной отношения СЛУЖ_ПРО_ЗАДАН

В этом отношении два возможных ключа: {СЛУ_НОМ, ПРО_НОМ} и {СЛУ_НОМ, СЛУ_ЗАДАН}. Отношение удовлетворяет требованиям 3NF: отсутствуют не минимальные FD неключевых атрибутов от возможных ключей (поскольку нет неключевых атрибутов), и отсутствуют транзитивные FD. Однако по причине наличия FD СЛУ_ЗАДАН® ПРО_НОМэто отношение не находится в BCNF. Поэтому отношению СЛУ_ПРО_ЗАДАН снова свойственны аномалии обновления. Например (поскольку СЛУ_НОМявляется компонентом обоих возможных ключей), невозможно удалить данные о единственном служащем, выполняющем задание в некотором проекте, не утратив информацию об этом задании.

Можно привести отношение СЛУЖ_ПРО_ЗАДАН к BCNF, произведя его декомпозицию на отношения СЛУЖ_НОМ_ЗАДАН {СЛУ_НОМ, СЛУ_ЗАДАН}*и ПРО_НОМ_ЗАДАН{СЛУ_ЗАДАН, ПРО_НОМ}, и эта декомпозиция решает отмеченные проблемы (теперь можно хранить данные о задании проекта, не выполняемом ни одним служащим). Значения переменных отношений СЛУЖ_НОМ_ЗАДАН и ПРО_НОМ_ЗАДАНпоказаны на рис. 7.10.

Значение переменной отношения СЛУЖ_НОМ_ЗАДАН

Значение переменной отношения ПРО_НОМ_ЗАДАН

Рис. 7.10. Значения переменных отношений СЛУЖ_НОМ_ЗАДАН и ПРО_НОМ_ЗАДАН

Однако возникают новые трудности. Например, система должна запретить добавление в отношение СЛУЖ_НОМ_ЗАДАН кортежа <2934, D>, поскольку задание D относится к проекту 1, а служащий с номером 2934 уже выполняет задание в этом проекте. Так происходит, потому что исходная FD {СЛУ_НОМ, ПРО_НОМ} ® СЛУ_ЗАДАНне выводится из единственной (нетривиальной) действующей для этих проекций FD СЛУ_ЗАДАН® ПРО_НОМ,и соответствующее ограничение целостности становится ограничением базы данных.

Тем самым, проекции СЛУЖ_НОМ_ЗАДАН и ПРО_НОМ_ЗАДАН не являются независимыми, а отношение СЛУЖ_ПРО_ЗАДАН атомарно, хотя и не находится в BCNF. Из этого следует, что при проектировании реляционной базы данных приведение отношения к BCNF не должно быть самоцелью. Нужно внимательно оценивать положительные и отрицательные последствия нормализации.

Наконец, приведем пример, когда наличие двух перекрывающихся возможных ключей не мешает отношению находиться в BCNF. Предположим, что в организации проекты включают одни и те же задания, каждый служащий может участвовать в нескольких проектах, но может выполнять в каждом проекте только одно задание. Тогда переменная отношения СЛУЖ_НОМ_ЗАДАН имеет множество FD, показанное на рис. 7.11, и может содержать значение, показанное на том же рисунке.

Диаграмма FD отношения СЛУЖ_НОМ_ЗАДАН(третий вариант)

Возможное значение переменной отношения СЛУЖ_НОМ_ЗАДАН(третий вариант)

Рис. 7.11. Третий вариант отношения СЛУЖ_НОМ_ЗАДАН

В третьем варианте отношения СЛУЖ_НОМ_ЗАДАН имеются перекрывающиеся возможные ключи ({СЛУ_НОМ, ПРО_НОМ} и {ПРО_НОМ, СЛУ_ЗАДАН}), однако оно находится в BCNF, поскольку эти ключи являются единственными детерминантами. Легко убедиться, что отношению СЛУЖ_НОМ_ЗАДАН не свойственны аномалии обновления.