Ранее было сказано, что в процессе проектирования с помощью проекции декомпозицию следует осуществлять путем поиска цепочек ФЗ, а именно: A -> B -> C с последующим проецированием, порождаемым ФЗ, замыкающей цепочки. В данном случае это ФЗ В -> С.
Отступим от этого правила и в качестве ФЗ для композиции возьмем А -> В. Если исходное отношение имеет вид R(A,B,C),то полученные в результате отношения будут R1(A, В) и R2(A, С).
Хотя оба эти отношения находятся в НФБК, со всей отчетливостью обнаруживается следующая проблема. Ни отношение R1(А,В), ни R2(A,C) не содержит ФЗ В -> С, которая является ФЗ исходного отношения.
Эта зависимость утеряна в процессе декомпозиции. С практической точки зрения это означает, что если приведенные выше отношения R1 и R2 будут использованы для создания БД, то нельзя будет утверждать, что некорректные связи между В и С не будут привнесены в БД.
Проблема в данном примере возникает из-за проекции, порожденной ФЗ, зависимостная часть которой сама является детерминантом другой ФЗ. При использовании правила цепочки эта проблема не возникает.
Таким образом, следует избегать выбора ФЗ, зависимостная часть которой сама - целиком или частично является детерминантом другой ФЗ.
Другим случаем возможной потери ФЗ в процессе декомпозиции является ситуация, в которой один атрибут зависит от двух различных детерминантов. Пусть для отношения R(A,B,C) определены зависимости, показанные на рис.14.
А
В R(A, B,C)
С
Рис.14. Два детерминанта с одним и тем же зависимым атрибутом.
Это отношение не находится в НФБК, т.к. имеется только один возможный ключ <A,C>, в то время как детерминантами являются <А> и <C>. Правило цепочек здесь не приемлемо по причине их отсутствия. Кроме того, если одна из ФЗ будет выделена обычным способом, то другая будет потеряна. Например, при выделении из R(A, B,C) зависимости А -> В будут получены отношения R1(A,C) и R2(A,B), ни одно из которых не будет содержать зависимости С -> В. Наоборот, при первоочередном выделении С -> В будет утеряна зависимость А -> В.
Таким образом, возникла ситуация, обязывающая проектировщика найти способ разбиения отношения R(A,B,C) на два, не приводящей к утере ни одной ФЗ. Этот путь не соответствует стандартному методу декомпозиции, но может привести к лучшему результату. Единственное что может сделать проектировщик, столкнувшись с указанной ситуацией, это проверить три возможных набора отношений и оценить, какой из трех наиболее соответствует нуждам пользователя. В частности, полученные в последнем случае отношения необходимо проверить на предмет возникновения проблем в случае соединения двух итоговых отношений при поиске данных на этапе эксплуатации окончательного варианта базы.
Второй метод разбиения отношения, основан на подходе к проектированию, отличном от декомпозиции, тем не менее используется многими проектировщиками. В основе подхода, называемого некоторыми МЕТОДОМ СИНТЕЗА, лежит утверждение (в своей простейшей форме), что необходимо все ФЗ с одинаковыми детерминантами выделять в группы и каждой группе отводить свое собственное отношение. Получаемые отношения проверяются на их соответствие НФБК. В последнем примере были две зависимости с различными детерминантами. Согласно методу синтеза каждой ФЗ следует выделить ее отношение - R1(A,B) и R2(C,B). Метод синтеза может быть использован как самостоятельно, так и в сочетании с методом декомпозиции.
Тот факт, что существуют различные методы проектирования, которые могут быть использованы как порознь, так и смешанным образом, свидетельствует о том, что проектирование БД является частично наукой, а частично искусством. Возможность развития нескольких вполне "законных" проектов, имеющих общую исходную точку, является неотъемлемым фактором области проектирования БД. Часть процесса проектирования заключается в оценке нескольких альтернатив с целью выявления наиболее отвечающей нуждам пользователя.
