Скажем, R имеет следующие атрибуты: {A,B,C,D,E} и имеет следующие функциональные зависимости:
A -> BC
CD -> E
B -> D
E -> A
И есть разложение, состоящее из R1(A,B,C) и R2(A,D,E). Как я могу вычислить функциональные зависимости R1 и R2?
Фактический вопрос по домашнему заданию спрашивает меня, находятся ли R1/R2 в BCNF/3NF/ни в одном, но я уже знаю, как сделать эту часть (посмотрите, содержится ли левая часть FD в ключах-кандидатах).
Хитрость заключается в том, чтобы думать о FD как об определяющих ключах не в вашей заданной схеме, а в ее ПРОЕКЦИЯХ.
Например, в исходной схеме {ABCDE} FD A -> BC говорит, что A (фактически {A}) представляет собой ключ в этой таблице, спроецированный до {ABC}. То есть объединение LHS и RHS FD определяет, какая проекция, а LHS определяет ключ на этой проекции.
Теперь вернемся к декомпозированной версии, в которой у вас есть две отдельные таблицы (схемы) {ABC} и {ADE}.
Ваши первый и последний FD все еще могут быть выражены в этих схемах. Первый FD в первой схеме/таблице и последний в последней.
Но оставшиеся два стали невыразимыми (то есть невыразимыми КАК FD) из-за декомпозиции. Что это означает для общего дизайна базы данных, так это то, что вам придется объявить/определить/реализовать ограничение базы данных, которое говорит и делает то же самое, что и исходный FD. (Общий рецепт для этого следующий: восстановить исходную таблицу, снова объединив разложения, спроектировать, которые соединяются по упомянутым атрибутам, и применить ключ к этой проекции. Достижение этого будет не совсем тривиальным для таких случаев, как эти упражнения курса.)
Решение о том, находятся ли R1/R2 в xNF, теперь должно быть сделано с учетом только тех из исходных FD, которые еще можно выразить (a->BC).
Я полагаю, вы должны прийти к выводу, что R1 находится в 3/BC NF, а R2 все еще нет.
Примеры, подобные этим (и большинство упражнений курса именно такого рода), на самом деле иллюстрируют, насколько смехотворно преувеличена концепция нормализации в области проектирования баз данных. Важна общая картина, включающая ВСЕ ограничения, применимые к базе данных.
