2.Этапы проектирования

Процесс проектирования базы данных является итерационным – допускающим возврат к предыдущим этапам для пересмотра ранее принятых решений и включает следующие этапы:

1. Выделение сущностей и связей между ними.

2. Построение диаграмм ER –типа с учетом всех сущностей и их связей.

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

4. Добавление неключевых атрибутов в отношения.

5. Приведение предварительных отношений к нормальной форме Бойса–Кодда, например, с помощью метода нормальных форм.

6. Пересмотр ER- диаграмм в следующих случаях:

• некоторые отношения не приводятся к нормальной форме Бойса-Кодда;

• некоторым атрибутам не находится логически обоснованных мест в предварительных отношениях.

После преобразования ER-диаграмм осуществляется повторное выполнение предыдущих этапов проектирования (возврат к этапу1).

Одним из узловых этапов проектирования является этап формирования отношений.

3.Пример проектирования бд учебной части.

Применим описанные правила к примеру, рассмотренному при изучении метода нормальных форм.

БД для учебной части, содержащей следующие сведения:

ФИО - фамилия и инициалы преподавателя (возможность совпадения фамилии и инициалов у преподавателей исключена).

Должн - должность, занимаемая преподавателем.

Оклад - оклад преподавателя.

Стаж - преподавательский стаж.

Д_Стаж - надбавка за стаж.

Каф - номер кафедры, на которой работает преподаватель.

Предм - название дисциплины (предмета), ведомой преподавателем.

Группа - номер группы, в которой преподаватель проводит занятия.

ВидЗан - вид занятий, проводимых преподавателем в учебной группе (преподаватель в одной группе ведет только один вид занятий).

Исходное отношение ПРЕПОДАВАТЕЛЬ приведено на рис. 6.

ПРЕПОДАВАТЕЛЬ

Ф.И.О.	Должн.	Оклад	Стаж	Д_Стаж	Каф	Предм.	Группа	ВидЗан
Иванов И.М.	Препод.	500	5	100	25	СУБД	256	Практ.
Иванов И.М.	Препод.	500	5	100	25	ПЛ/1	123	Практ
Петров М.И.	Ст.препод.	800	7	100	25	СУБД	256	Лекция
Петров М.И.	Ст.препод.	800	7	100	25	Паскаль	256	Практ.
Сидоров Н.Г.	Препод.	500	10	150	25	ПЛ/1	123	Лекция
Сидоров Н.Г.	Препод.	500	10	150	25	Паскаль	256	Лекция
Егоров В.В.	Препод.	500	5	100	24	ПЭВМ	244	Лекция

Рис.6. Исходное отношение Преподаватель

Первый этап проектирования - выделение сущностей и связей между ними.

Выделим следующие сущности:

• ПРЕПОДАВАТЕЛЬ (Ключ - ФИО).

• ЗАНЯТИЕ (Ключ - Группа. Предм).

• СТАЖ (Ключ - Стаж).

• ДОЛЖНОСТЬ (Ключ - Должн).

Выделим связи между сущностями:

• ПРЕПОДАВАТЕЛЬ ИМЕЕТ СТАЖ,

• ПРЕПОДАВАТЕЛЬ ВЕДЕТ ЗАНЯТИЕ,

• ПРЕПОДАВАТЕЛЬ ЗАНИМАЕТ ДОЛЖНОСТЬ.

Второй этап проектирования - построение диаграммы ER-типа с учетом всех сущностей и связей между ними.

Р ис.7. Диаграмма ER-типа

Связь ИМЕЕТ является связью типа М:1, т. к. одинаковый стаж могут иметь несколько преподавателей. Сущность ПРЕПОДАВАТЕЛЬ имеет обязательный класс принадлежности, поскольку каждый преподаватель имеет свой стаж. Сущность СТАЖ имеет необязательный класс принадлежности, так как возможны такие значения стажа, которые не имеет ни один из преподавателей.

Связь ВЕДЕТ имеет тип М:М, так как преподаватель может вести несколько занятий, а каждое занятие может проводиться несколькими преподавателями. Занятие может быть лекционным или практическим, проводимым преподавателем в учебной группе по одной из дисциплин. Обе сущности в данной связи имеют КП обязательный, в предположении, что нет преподавателей, которые не проводят занятий, и нет занятий, которые не обеспечены преподавателями.

Связь ЗАНИМАЕТ имеет: тип М:1, так как каждый преподаватель занимает определенную должность и одинаковые должности могут занимать несколько преподавателей. Сущность ПРЕПОДАВАТЕЛЬ имеет обязательный класс принадлежности, так как предполагаем, что каждый преподаватель занимает должность. Сущность ДОЛЖНОСТЬ имеет необязательный КП, так как не исключаем, например, отсутствие должности профессора на кафедре, а значит, и преподавателя, который ее занимает.

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

На основе анализа диаграммы ER-типа (рис. 7) с помощью шести сформулированных выше правил получаем набор предварительных отношений, представленных следующими схемами отношений.

Связь ИМЕЕТ удовлетворяет условиям правила 4, в соответствии с которым получаем два отношения:

1. ПРЕПОДАВАТЕЛЬ (ФИО. Стаж....) - добавился ключевой атрибут Стаж.

2. СТАЖ (Стаж....).

Связь ВЕДЕТ удовлетворяет условиям правила 6, в соответствии с которым получаем три отношения:

1. ПРЕПОДАВАТЕЛЬ (ФИО. Стаж....).

2. ЗАНЯТИЕ (Группа. Предм. ...У

3. ВЕДЕТ (ФИО. Группа. Предм. ...У

Связь ЗАНИМАЕТ аналогично связи ИМЕЕТ удовлетворяет условиям правила 4, поэтому имеем следующие два отношения

1. ПРЕПОДАВАТЕЛЬ (ФИО. Стаж. Должн. ...) добавился ключевой атрибут Должн.

2. ДОЛЖНОСТЬ (Должн....).

Этот этап проектирования включает добавление неключевых атрибутов, которые не были выбраны в качестве ключевых раньше, и назначение их одному из предварительных отношений с тем условием, чтобы отношения отвечали требованиям нормальной формы Бойса-Кодда.

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

ПРЕПОДАВАТЕЛЬ (ФИО. Стаж. Должн. Каф)

СТАЖ (Стаж. Д_Стаж),

ЗАНЯТИЕ (Группа. Предм)

ВЕДЕТ (ФИО. Группа. Предм. ВидЗан)

ДОЛЖНОСТЬ (Должн. Оклад).

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

Рис.8 Схема базы данных

Итак,

• В нашем примере отношение ЗАНЯТИЕ, кроме ключевых атрибутов (Группа. Предм), других атрибутов не имеет. Поэтому оно не несет дополнительной информации, кроме содержащейся в отношении ВЕДЕТ.

• Действительно, это отношение включает в себя атрибуты Группа. Предм. Поэтому отношение ЗАНЯТИЕ нужно исключить из формируемой схемы БД (на рис. 8 оно перечеркнуто). Если бы имелись другие атрибуты, например, атрибут Семестр, в котором некоторая группа изучает конкретную дисциплину, то получили бы отношение ЗАНЯТИЕ (Группа.Предм. Семестр), которое вошло бы в БД.

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