1.6.5. Последовательность проектирования бд при использовании er- метода

1. Определение используемых сущностей и связей между ними.

2. Определение исходных и ролевых сущностей, если таковые имеются.

3. Построение диаграммы ER- типа, включающей в себя все сущности и связи, важные с точки зрения интересов пользователя.

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

5. Подготовка списка всех представлявших интерес атрибутов (тех из них, которые не были уже перечислены в диаграмме ER- типа в качестве ключей сущности) и назначения каждого из этих атрибутов одному из предварительных отношений.

6. Определение для каждого отношения межатрибутных ФЗ, с помощью которых проверяется соответствие отношений НФБК.

7. Отношения не находящиеся в НФБК подвергаются декомпозиции с последующей проверкой их на нахождение в НФБК.

8. П.7 повторяется до тех пор пока все отношения не будут находится в НФБК.

9. Если некоторым атрибутам не находится логически обоснованных мест в предварительных отношениях, то в этом случае необходимо пересмотреть ER - диаграммы на предмет устранения возникших затруднений.

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

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

1. Составляются списки ФЗ для каждого отношения. Одна и та же ФЗ не должна появляться более чем в одном отношении. Если таковые имеются, то их необходимо удалить.

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

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

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 является избыточным, т.к. применение операции СОЕДИНЕНИЕ к R5 и R7 (общим атрибутом является D) даст отношение R9(A,B,E,D,G,H), которое содержит все атрибуты, присутствующие в R8.

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

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