Анализ исходных аномалий

Зададимся вопросом: присутствует ли в БД УСПЕХИ те же аномалии, которые характеризовали отношение УСПЕВАЕМОСТЬ, или декомпозиция автоматически привела к их устранению? Для того, чтобы подтвердить устранение аномалий, а именно эта цель ставилась в первую очередь при осуществлении декомпозиции, рассмотрим, опираясь на приведенную на рис.13 БД УСПЕХИ, проблемы вставки, удаления и обновления.

Вставка. Когда отношение УСПЕВАЕМОСТЬ служило основой БД, новый студент не мог быть в нее включен до действительного завершения им хотя бы одного семестра. В БД УСПЕХИ информация общего характера о студентах хранится в отношении R4. Как только новый студент принимается в институт и ему отводится комната, так этот студент может быть включен в БД (в R4). Студенту даже нет необходимости просто приступить к посещению занятий для того, чтобы быть включенным в БД. Таким образом, исходная аномалия вставки исключена с помощью декомпозиции.

Обновление. В исходном отношении УСПЕВАЕМОСТЬ попытка изменить номер телефона Серова, проживающего в комнате 120 может привести к тому, что в БД появится два различных телефонных номера, установленного в комнате 120. В БД УСПЕХИ телефонные номера располагаются в отношении R2 и каждая комната может иметь только один телефонный номер. Следует помнить, что Кном является первичным ключом отношения R2, а значения первичного ключа по определению должны быть уникальными. Для изменения телефонного номера Серова следует в кортеже отношения R2, в котором Кном=120, изменить номер Тном. При этом будет изменен номер телефона для всех студентов, живущих в этой комнате. Таким образом, исходная аномалия обновления устраняется с помощью НФБК-проектирования.

Необходимо еще раз подчеркнуть, что устранение аномалии обновления базируется на том положении, что СУБД, в среде которой будет создаваться БД, не допускает дублирования значений первичных ключей.

Удаление. Когда отношение УСПЕВАЕМОСТЬ использовалось в качестве БД, удаление кортежа включавшего значения Сном=110 и Дисц. ВМ, привело к исчезновению из БД студента с номерами 110. Этого не может произойти в случае БД УСПЕХИ, поскольку информация о студентах общего характера разнесена в два различных отношения (R3 и R4). При исключении из отношения R3 кортежа <110,ВМ,1,4>, общая информация о студенте, хранимая в R4, останется.

Итак, все три аномалии, присутствовавшие в БД, состоящей из одного отношения, устраняются при таком проектировании. Результат устранения аномалий - появление вместо одного трех, требующих хранения, отношений. Это означает, что запросы, которые должны быть составлены для получения информации из БД, возможно, станут более сложными, поскольку они должны поддерживать прохождение цепочки из двух или трех отношений при поиске требуемых данных.

1.5.4. Возможные потери фз при декомпозиции

Ранее было сказано, что в процессе проектирования с помощью проекции декомпозицию следует осуществлять путем поиска цепочек ФЗ, а именно: 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). Метод синтеза может быть использован как самостоятельно, так и в сочетании с методом декомпозиции.

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