Пример проектирования базы данных учебной части

Рассмотрим базу данных, содержащую следующие сведения:

ФИО (возможность совпадения значений ФИО исключена), Должность, Оклад, Стаж, Надбавка за стаж, Кафедра, Предметы, Группа, Вид занятий (преподаватель в одной группе ведет только один вид занятий).

Исходное отношение ПРЕПОДАВАТЕЛЬ приводилось на рис. 6.4., однако для удобства приведем его здесь (рис. 7.25).

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

ФИО	Долж	Оклад	Стаж	Надб	Каф	Предм	Группа	ВидЗан
Иванов И.М.	преп					СУБД		Лабор
Иванов И.М.	Преп					Информ		Лабор
Петров М.И.	Ст.преп					СУБД		Лекция
Петров М.И.	Ст.преп					Графика		Лабор
Сидоров Н.Г.	Преп					Информ		Лекция
Сидоров Н.Г.	Преп					Графика		Лекция
Егоров В.В.	Преп					ПЭВМ		Лекция

Рис. 7.25. Исходное отношение

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

Определим основные сущности:

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

ЗАНЯТИЕ (Ключ – Группа, Предм);

СТАЖ (ключ - Стаж);

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

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

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

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

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

Второй этап проектирования – построение диаграммы ER-типа с учетом следующих предположений: 1) каждый преподаватель имеет свой стаж; 2) возможны такие значения стажа, которые не имеет ни один из преподавателей; 3) один преподаватель может вести несколько занятий; 4) один вид занятий может проводится несколькими преподавателями; 5) один преподаватель в одной группе проводит занятие по одной из дисциплин либо лекцию, либо лабораторные работы; 6) нет преподавателей, которые не проводят занятия; 7) нет занятий, которые не обеспечены преподавателями; 8) каждый преподаватель занимает определенную должность; 9) одинаковые должности могут занимать несколько преподавателей; 10) возможны такие должности, которые не занимает ни один преподаватель кафедры.

Н

О М Стаж, …

О

М М

М Группа, Предм, …

ФИО, … 1 Н

Долж, …

Рис. 7.26. Диаграмма ER-типа и отношения

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

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

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

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

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

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

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

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

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

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

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

2. ДОЛЖНОСТЬ (Должность, …)

Четвертый этап проектирования – добавление в отношения неключевых атрибутов. При этом отношения должны отвечать условиям нормальной формы Бойса-Кодда. После добавления неключевых атрибутов схемы отношений имеют вид:

1. ПРЕПОДАВАТЕЛЬ (ФИО, Стаж, Должность, Кафедра)

2. СТАЖ (Стаж, Надбавка )

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

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

5. ДОЛЖНОСТЬ (Должность, Оклад )

Схема полученной базы данных имеет те же отношения, что и при проектировании БД методом нормальных форм, и имеет вид (рис.7.27):

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

ПРЕПОДАВ. ДОЛЖНОСТЬ СТАЖ

ВЕДЕТ ЗАНЯТИЕ

Рис. 7.27. Схема базы данныхучебной части

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

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

Дата добавления: 2014-01-06