. Другая декомпозиция отношения консультант

Ранее декомпозиция отношения КОНСУЛЬТАНТ на три отношения была начата проекцией, порождае­мой ФЗ:

Кном -> Тном.

Указанная ФЗ была выбрана потому, что являлась последней в цепочке ФЗ, выявленных на рис. 20:

Сном -> Кном -> Тном.

Внимательное изучение представленных на рис. 20 ФЗ показывает, что на этом рисунке присутствует другая цепочка зависимостей с таким же их числом

Сном -> Тном -> Кном.

Здесь крайней правой ФЗ является Тном -> Кном . Если эта ФЗ выделяется первой из отношения КОНСУЛЬТАНТ, то в итоге будет получена следующая БД в НФБК:

R2 (Тном, Кном)

R3 (Сном, Курс, Семестр,Оценка)

R4(Сном,Cфам,Тном )

Эта БД столь же корректна, как и БД, приведен­ная на рис. 25. Единственное отличие состоит в том, что номер Тном стал выполнять роль более важную, нежели Кном. Тном в данной ситуации используется в качестве первичного ключа для отношения R2 (а не Кном) и атрибута, связывающего R4 и R2. Два различных решения одной проблемы являются пря­мым результатом взаимной зависимости, существую­щей между атрибутами Тном и Кном. Какое из двух решений является "лучшим" определяется выбором проектировщика и зависит до некоторой степени от того, как консультант планирует использовать БД.

Некоторые комментарии к декомпозиционному алгоритму проектирования

Было сказано, что в процессе проектиро­вания с помощью проекции декомпозицию следует осуществлять путем поиска цепочек ФЗ, а именно:

А -> В, В -> С

с последующим проецированием, порождаемым ФЗ, замыкающей цепочку. В данном случае первой ФЗ будет В -> С. Другой путь обоснования процедуры выбора состоит в утверждении, что всеми средствами следует избегать выбора ФЗ, зависимостная часть которой сама - целиком или частично - является детерминантом другой ФЗ.

Если в вышеприведенном случае положить, что обсуждаемое отношение имеет вид R(A,B,C) и ФЗ А->В выбрана для проекции в первую очередь, то полученные в результате отношения будут R1(A,C) и R2(A,B). Хотя оба эти отношения находятся НФБК, со всей отчетливостью обнаруживается следующая проблема:

Ни отношение R1(A,C), ни R2(A,B) автономно не содержат атрибуты, присутствующие в ФЗ В -> С, которая является ФЗ исходного отношения. Эта зависимость утеряна в процессе проектирования. С практической точки зрения это означает, что если приведенные выше отношения R1 и R2 будут исполь­зованы для создания БД, то нельзя будет утверждать, что некорректные связи между В и С не будут привнесены в БД. Рис. 26 иллюстрирует выявленную проблему. При соединении R1 и R2 по атрибуту А два значения С (3 и 4) могут быть соотнесены с В, что противоречит ФЗ, утерянной в процессе проектирования.

Рис. 26. Экземпляры отношений, удовлетворяющие ФЗ отношений R1 и R2, но противоречащие ФЗ, представленной в исходных спецификациях

Проблема в данном примере возникает из-за про­екции, порожденной ФЗ, зависимостная часть которой сама является детерминантом другой ФЗ. При исполь­зовании правила цепочки эта проблема не возникает.

Другим случаем возможной потери ФЗ в процессе проектирования является ситуация, в которой один атрибут зависит от двух различных детерминантов. Пусть для отношения R(A,B,C) определены зависимо­сти, показанные на рис. 27.

Рис. 27. Два детерминанта с одним и тем же зави­симым атрибутом

Это отношение не находится в НФБК, так как имеется только один возможный ключ <А,С>, в то время как детерминантами являются <А> и <С>. Правило цепочек здесь неприложимо по причине их отсутствия. Кроме того, если одна из ФЗ будет выде­лена обычным способом, то другая будет потеряна. Например, при выделении из R(A,B,C) зависимости А -> В будут получены отношения R1(A,C) и R2(A,B), ни одно из которых не будет содержать за­висимости С -> В. Наоборот, при первоочередном выделении С -> В будет утеряна зависимость А -> В. Возникла ситуация, обязывающая проектировщика найти способ разбиения отношения R(A,B,C) на R1(A,B) и R2(C,B), не приводящий к утере ни одной ФЗ. Этот путь не соответствует стандартному методу декомпозиции, но может привести к лучшему резуль­тату. Единственное, что может сделать проектиров­щик, столкнувшись с указанной ситуацией, это про­верить три возможных набора отношений и оценить, какой из трех наиболее соответствует нуждам пред­приятия. В частности, полученные в последнем слу­чае отношения необходимо проверить на предмет воз­никновения проблем в случае соединения двух итого­вых отношений при поиске данных на этапе эксплуа­тации окончательного варианта базы.

Второй метод разбиения отношения, обсуждение которого велось с привлечением рис. 27, хотя и ос­нован на подходе к проектированию, отличном от де­композиции, тем не менее используется многими про­ектировщиками. В основе подхода, называемого неко­торыми методом синтеза, лежит утверждение (в своей простейшей форме), что необходимо все ФЗ с одинаковыми детерминантами выделять в группы и каждой группе отводить свое собственное отношение. Получаемые отношения проверяются на их соответст­вие НФБК. В последнем примере были две зависимо­сти с различными детерминантами. Согласно методу синтеза каждой ФЗ следует выделить ее собственное отношение - R1(A,B) и R2(C,B). Метод синтеза мо­жет быть использован как самостоятельно, так и в сочетании с методом декомпозиции. В книге акцент делается на метод декомпозиции (также называемый методом проекции), а метод синтеза используется как альтернатива при поиске выхода из затруднительных ситуаций, подобных разобранной выше. Как будет по­казано в гл. 5, зависимости, сходные с той, которая приведена на рис. 3.9, могут возникнуть в жизнен­ных ситуациях реального мира.

Тот факт, что существуют различные методы про­ектирования, которые могут быть использовать как порознь, так и до некоторой степени смешанным об­разом, свидетельствует о том, что проектирование БД является частично наукой, а частично искусством. Возможность развития нескольких вполне "законных" проектов, имеющих общую исходную точку, является неотъемлемым фактором области проектирования БД. Часть процесса проектирования заключается в оценке нескольких альтернатив с целью выявления наиболее отвечающей нуждам предприятия.