Читайте также:
|
|
Было сказано, что в процессе проектирования с помощью проекции декомпозицию следует осуществлять путем поиска цепочек ФЗ, а именно:
А -> В, В -> С
с последующим проецированием, порождаемым ФЗ, замыкающей цепочку. В данном случае первой ФЗ будет В -> С. Другой путь обоснования процедуры выбора состоит в утверждении, что всеми средствами следует избегать выбора ФЗ, зависимостная часть которой сама - целиком или частично - является детерминантом другой ФЗ.
Если в вышеприведенном случае положить, что обсуждаемое отношение имеет вид 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, могут возникнуть в жизненных ситуациях реального мира.
Тот факт, что существуют различные методы проектирования, которые могут быть использовать как порознь, так и до некоторой степени смешанным образом, свидетельствует о том, что проектирование БД является частично наукой, а частично искусством. Возможность развития нескольких вполне "законных" проектов, имеющих общую исходную точку, является неотъемлемым фактором области проектирования БД. Часть процесса проектирования заключается в оценке нескольких альтернатив с целью выявления наиболее отвечающей нуждам предприятия.
Дата добавления: 2015-07-08; просмотров: 191 | Нарушение авторских прав
<== предыдущая страница | | | следующая страница ==> |
ПРИМЕР НОРМАЛИЗАЦИИ | | | Транзитивные зависимости |