МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙКОЙ ФЕДЕРАЦИИ

ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК

Кафедра информационных систем

Курсовая работа

по дисциплине «Базы данных»

Учет нагрузки преподавателей.

Выполнил: Солецкий Д.А.

385 группа

Проверил: Моор А.П.

Старший преподаватель кафедры ИС

Тюмень 2011

Оглавление

1.Описание задачи. 3

1.1.Предметная область. 3

1.2.Функции приложения. 3

1.3.Первичный документ. 4

2.Нормализация. 5

3.Разработка модели «сущность-связь». 8

4.Описание (диаграмма) БД.. 13

4.1.Таблицы БД.. 13

4.2.Диаграмма БД.. 14

5.Описание приложения. 15

5.1.Требования к приложению.. 15

5.2.Реализация. 15

Заключение. 17

1. Описание задачи

1.1. Предметная област ь

Учет нагрузки преподавателей — область, без которой не возможна нормальная работа учебного заведения.

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

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

1.2. Функции приложения

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

1. Добавление, редактирование, удаление данных о преподавателях, предметах, специальностях, факультетах, кафедрах, должностях и учебных часах;

2. Оформление учета преподавателей по семестрам, специальностям и предметам;

3. Сортировка данных;

4. Формирование отчетов и экспорт данных в MSExcel.

1.3. Первичный документ

2. Нормализация

При проведении нормализации были учтены все столбы, указанные в первичном документе. Первичный документ «Заказ» можно представить в виде таблицы.

1НФ:

Повторяющаяся группа: Код факультета (Id_fak), Факультет (name_fak), Код специальности (Id_spec), Специальность (name_spec), Код предмета (Id_pred), Предмет (name_pred), Часы лекций (lek), Часы практик (prak). Для того чтобы в отношении на пересечении каждой строки и каждого столбца содержалось только одно значение, продублируем значения атрибутов, не входящих в повторяющуюся группу:

Выберем потенциальные ключи:

id_prep, semestr, id_spec, id_pred - однозначно определяет строку в 1НФ

Единственный ключ он же первичный

Частичные функциональные зависимости: id_prep -> prep, id_kaf, name_kaf,id_dol, name_dol

id_spec -> name_spec, id_fak, name_fak

id_pred -> name_pred

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

Итог 2 НФ :

А (id_prep, semestr, id_pred, id_spec ,lek,prak)

Б(id_spec , name_spec, id_fak, name_fak)

В(id_prep , prep, id_kaf, name_kaf, id_dol, name_dol)

Г(id_pred , name_pred)

Транзитивные зависимости:

В А транзитивных зависимостей нет

В Б : id_spec -> id_fak, id_fak -> name_fak

Отношение Б разбивается на два отношения:

Б1(id_spec , name_spec, id_fak)

Б2(id_fak , name_fak)

В В : id_prep -> id_kaf, id_kaf -> name -> kaf; id_prep -> id_dol, id_dol -> name_dol

Отношение В разбивается на 3 отношения:

В1(id_prep , prep, id_kaf,id_dol)

В2( id_kaf, name_kaf)

B3(id_dol, name_dol)

В Г Транзитивных зависимостей нет

Итог 3 НФ

А (id_prep, semestr, id_pred, id_spec , lek, prak)

Б1(id_spec , name_spec, id_fak)

Б2(id_fak , name_fak)

В1(id_prep , prep, id_kaf, id_dol)

В2( id_kaf, name_kaf)

B3(id_dol, name_dol)

Г(id_pred , name_pred)

НФБК

Отношения Б1, Б2, В1, B2, B3, Г: не имеют составных потенциальных ключей, следовательно они в НФБК

Отношения А имеет только один составной потенциальный (он же первичный ключ, следовательно оно в НФБК

Итог нормализации совпадает с итогом 3НФ

3. Разработка модели «сущность-связь»

Итерация 1

Требования к программе:

· Хранить информацию о преподавателях ведущих учебную деятельность;

· Хранить информацию о предметах;

· Хранить информацию о специальностях;

Определение сущностей:

· Преподаватель;

· Предмет;

· Специальность

Может преподавать

Может преподаваться

Может

преподавать

Могут

учиться

Итерация 2

Уточнение сущностей:

Преподавателю определяют учебную нагрузку;

Преподаватель может вести несколько предметов у нескольких специальностей;

Должна содержать Должна содержать

Должна содержать

Итерация 3

Уточнение сущностей:

Специальность характеризуется факультетом;
Преподаватель имеет должность и относиться к какой-либо кафедре;

Определение атрибутов:

· Преподаватель содержит уникальный код, ФИО, Должность, Кафедру;

· Карточка учета содержит уникальный код, код преподавателя, код предмета, код специальности, семестр и часы нагрузки;

· Специальность содержит уникальный код, наименование специальности и код факультета;

· Факультет содержит код факультета, название;

· Кафедра содержит код кафедры, название;

· Должность содержит код должности, название;

· Предмет содержит код предмета, название;

Концептуальная модель

Кафедра

Код кафедры

Название кафедры

Учет нагрузки преподавателя

Код преподавателя

Код специальности

Семестр

Код предмета

Часов лекций

Часов практики

Преподаватель

Код преподавателя

ФИО преподавателя

Код кафедры

Код должности

Должность

Код должности

Название должности

Предмет

Код предмета

Название предмета

Факультет

Код факультета

Название факультета

Физическая модель

Table Kaf

Id_kaf(int)

name_kaf( varchar30)

Table Itog

Id_prep(int)

Id_spec(int)

Semester(int)

Id_pred(int)

Lek(int)

Prak(int)

Table Prep

Id_prep(int)

Name_prep( varchar30)

Id_kaf(int)

Id_dol(int)

Table Dol

Id_dol(int)

Name_dol(varchar20)

Table Pred

Id_pred(int)

Name_pred(varchar30)

Table Fak

Id_fak(int)

Name_fak(varchar30)

4. Описание (диаграмма) БД

4.1. Таблицы БД

Id_itog

int

№

4.2. Диаграмма БД

5. Описание приложения

5.1. Требования к приложению

Приложение должно обеспечивать:

· Ввод, модификацию и удаление любых данных из БД

· Отображение данных с фильтрами и сортировкой

· Отображение не менее трех форм обобщенной информации (отчетов) с обязательным подведением итогов. По крайней мере, два отчета должны строиться на основе сложных выборок (три и более таблицы).

· Стабильную работу без ошибок в коде, ведущих к потере функциональности.

· Функциональный и интуитивно понятный интерфейс (интуитивно понятный интерфейс – это когда пользователь может работать с программой без вопросов к разработчику)

5.2. Реализация

В приложении содержатся справочные таблицы в которые можно добавлять данные.

Рис.1. Справочная таблица «Преподаватели».

Рис. 2. Главная таблица и 3 запроса в выпадающем списке.

Так же в приложении содержится 3 запроса:

· Итоговый (обобщающий)

· Суммарная нагрузка преподавателей

· Нагрузка по кафедрам

Рис.3. Запрос «Итоговый» с демонстрацией фильтра по семестрам.

Информацию из запросов можно вывести в Exсel. Для этого необходимо нажать кнопку “Вывести в Exсel”.

В итоговом отчете предусмотрены сортировки по столбцам: «№», «Преподаватель» и «Специальность».

Рис.4. Сортировка по столбцу «Преподаватель»

Заключение

В результате работы была разработана база данных для учета нагрузки преподавателей. Проект базы данных включает нормализацию и модель сущность связь, на их основе была разработана серверная часть в MicrosoftSQlServer 2008. Нормализация проводилась на основании первичного документа и доведена, до нормальной формы Бойса-Кодда, модель сущность связь так же включает концептуальную и физическую модели.

Разработанное клиентское приложение обеспечивает все необходимые функции, такие как: ввод, модификация, удаление данных базы данных, сортировка данных, создание отчетов. При разработке были созданы представления в базе данных на сервере.