Алгоритм проектирования бд методом декомпозиции (восходящий метод)

Следующий обобщенный алгоритм декомпозиции будет использоваться :

1. Построение универсального отношения для БД.

2. Определение всех ФЗ, существующих между атрибутами универсального отношения.

3. Удаление всех избыточных ФЗ из исходного набора ФЗ с целью получения минимального покрытия. Эта процедура проводится путем поочередного удале­ния избыточных ФЗ с последующей проверкой получаемого на каждом шаге набора ФЗ на наличие хотя бы одной избыточной ФЗ.

4. Использование ФЗ из минимального покрытия для декомпозиции универсального отношения в набор НФБК-отношений.

5. Если может быть получено более чем одно минимальное покрытие, осуществляется сравнение результатов, полученных на основе различных минимальных покрытий, с целью определения варианта, лучше других отвечающего требованиям предприятия.

При использовании алгоритма декомпозиции (Шаг 4) следует помнить о нежелательности проекции, порождаемой ФЗ, у которой зависимостная часть является детерминантом другой ФЗ; также повышенное внимание требуется в тех случаях, когда зависимостная часть ФЗ зависит более чем от одного детерминанта. В любом из этих случаев может быть утеряна ФЗ из БД. Если в процессе декомпозиции достигнуто состояние, в котором проецирование, невлекущее за собой потерь ФЗ, становится невозможным, проектировщик должен будет сделать выбор из двух альтернатив: (1) выбор оставшихся ФЗ и создание одного отношения для каждых детерминанта и набора зависящих от него атрибутов; (2) изменение порядка ранее проведенных декомпозиций, ведь алгоритм проектирования не ведет к единственному решению.

Проверка отношений на завершающей фазе их проектирования

После завершения разработки НФБК-отношений, рас­сматриваемых уже в качестве окончательного проекта, полученный набор необходимо проконтролировать на предмет наличия невыявленных проблем.

1. Составляются списки ФЗ для каждого отноше­ния. Эти списки проверяются по двум направлениям: во-первых, одна и та же ФЗ не должна появляться более чем в одном отношении; и во-вторых, набор ФЗ, полученный в результате проектирования, дол­жен в точности совпадать с набором, присутствующим в минимальном покрытии, полученном перед началом проектирования. В противном случае, необходимо по­казать возможность получения итогового набора ФЗ из минимального покрытия с помощью правил выво­да. Если хотя бы одна из этих проверок окажется недостоверной, следует проанализировать процесс про­ектирования для выявления ошибок и/или рассмот­реть другие варианты проектирования.

2. Осуществляется проверка на присутствие избыточных отношений. Отношение является избыточным, если (а) все атрибуты в избыточном отношении мо­гут быть найдены в одном другом отношении проект­ного набора; (б) все атрибуты в избыточном отношении могут быть найдены в отношении, которое может быть получено из других отношений предложенного проектного набора с помощью серии JOIN-операций (операций естественного соединения) над этими отношениями. Если устанавливается избыточность отношения, его следует исключить из проектного набора. Примеры обоих типов избыточных отношений приведены ниже.

Для примера, иллюстрирующего первый тип избыточности, полагаем, что набор проектных отношений имеет вид:

R1(A,B)

R2(B,C,Y,Z)

R3(A,B,K)

Отношение R1 является избыточным, так как все его атрибуты присутствуют в отношении R3. Для иллюстрации избыточности второго типа поло­жим, что предлагаемый проектный набор имеет вид:

R1(A,C,X)

R3(D,K,F)

R5(D,E,G,H)

R7(A,B,D)

R8(A,B,E,G)

Отношение R8 является избыточным, так как приме­нение операции JOIN над R5 и R7 (общим атрибутом является D) дает в результате отношение R9(A,B,D,E,G,H), которое содержит все атрибуты, присутствующие в R8.

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