Пример проектирования БД учебной части

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

Исходные данные

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

1. ФИО – фамилия, имя и отчество преподавателя (возможность полного совпадения исключается);
2. Должность – должность, которую занимает преподаватель;
3. Оклад;
4. Стаж;
5. Доп_Стаж – доплата за стаж;
6. Кафедра – шифр кафедры, где работает преподаватель;
7. Предмет – название предмета, который ведет преподаватель;
8. Группа – шифр группы, в которой проводит занятия преподаватель;
9. Вид_Занятий – вид занятий, которые проводит преподаватель в группе (в одной группе преподаватель проводит лишь один вид занятий).

1-й этап проектирования

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

Сущности:

• ПРЕПОДАВАТЕЛЬ с ключом ФИО;
• ЗАНЯТИЕ с ключом Группа и Предмет;
• СТАЖ с ключом Стаж;
• ДОЛЖНОСТЬ с ключом Должность.

Связи между указанными сущностями:

• ВЕДЕТ для сущностей ПРЕПОДАВАТЕЛЬ и ЗАНЯТИЕ;
• ИМЕЕТ для сущностей ПРЕПОДАВАТЕЛЬ и СТАЖ;
• ЗАНИМАЕТ для сущностей ПРЕПОДАВАТЕЛЬ и ДОЛЖНОСТЬ.

2-й этап проектирования

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

Несколько преподавателей могут иметь одинаковый стаж, поэтому связь ИМЕЕТ будет типа М:1.

У каждого преподавателя есть свой стаж, поэтому у сущности ПРЕПОДАВАТЕЛЬ обязательный класс принадлежности.

Значение стажа может быть таким, которого нет ни у одного из преподавателей, поэтому у сущности СТАЖ необязательный класс принадлежности.

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

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

3-й этап проектирования

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

Анализируя диаграмму (рисунок 2), используя 6 правил формирования отношений, получим набор предварительных отношений, которые представлены такими схемами отношений.

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

1. ПРЕПОДАВАТЕЛЬ (ФИО, Стаж...) – добавили ключ Стаж.
2. СТАЖ (Стаж...).

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

1. ПРЕПОДАВАТЕЛЬ (ФИО, Стаж ...)
2. ЗАНЯТИЕ (Группа, Предмет ...)
3. ВЕДЕТ (ФИО, Группа, Предмет ...).

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

1. ПРЕПОДАВАТЕЛЬ (ФИО, Стаж, Должность ...) – добавили ключ Должность.
2. ДОЛЖНОСТЬ (Должность ...).

4-й этап проектирования

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

В результате схемы отношений будут иметь такой вид:

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

Таким образом, отношение ЗАНЯТИЕ необходимо удалить из схемы базы данных.

5-й этап проектирования

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

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