Разработка БД "Деканат"

Автор работы: Пользователь скрыл имя, 04 Марта 2014 в 08:17, курсовая работа

Описание работы

Целью данного проекта является разработка СУБД «Деканат», включающую базу данных и пользовательское приложение.
Необходимо решить следующие задачи:
проанализировать предметную область
спроектировать логическую и физическую модель
реализовать пользовательское приложение

Содержание работы

ВВЕДЕНИЕ…………………………………………………………………..3
ТЕОРЕТИЧЕСКИЕ ОСНОВЫ БАЗ ДАННЫХ………………………..5
Основные понятия баз данных и системы управления базами данных………………………………………………………………5
Функции систем управления базами данных………………………7
Модели данных, поддерживаемые СУБД…………………………..8
ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ «ДЕКАНАТ»……………….11
Анализ и описание работы деканата………………………………..11
2.2. Логическое проектирование………………………………………..13
ЭТАПЫ РЕАЛИЗАЦИИ ПОЛЬЗОВАТЕЛЬСКОГО ПРИЛОЖЕНИЯ
3.1 Создание таблиц и схемы данных………………………………….15
3.2 Создание форм……………………………………………………….20
3.3 Создание запросов…………………………………………………..23
3.4 Создание отчетов…………………………………………………….26
ЗАКЛЮЧЕНИЕ…………………………………………………………….29
СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ……………………….31

Файлы: 1 файл

БД.docx

— 513.18 Кб (Скачать файл)

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

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

Далее, на протяжении всего периода обучения в личных делах фиксируются все факты о любых изменениях статуса студента (перевод с курса на курс, с дневного отделения на заочное, перевод в другую группу, справки об академическом отпуске и т.п.).

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

Из этих документов извлекается вся необходимая информация, касающаяся учебного процесса.

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

Исходя из основных назначений деканата, определяем, что основной вид его деятельности — это делопроизводственная деятельность. Основной функцией деканата является координация и административное обеспечение учебного процесса.

Исследуя предметную область деканатов, наблюдаем выполнение большого числа процессов, которые можно условно сгруппировать в несколько пунктов:

  1. Организация и управление учебным процессом.
  2. Заполнение учётных документов.
  3. Контроль успеваемости студентов.

Кроме того, за выполнение (или не выполнение) учебного плана студентов поощряют (или наказывают).

Организация и управление учебным процессом включает общий контроль над учебным процессом, что подразумевает распределение дисциплин по семестрам и специальностям для планирования расписаний и экзаменационных сессий; статистический учет студентов; организация учебной и производственной практики.

Основными документами, функционирующими в деканате, являются: матрикульная книга, карточка студента, сводная ведомость на каждого студента. Все эти документы требуют своевременного заполнения, для обеспечения учётной работы в деканате.

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

В результате контроля успеваемости становится возможным выявление лучших студентов и начисление им стипендии, материальной помощи, премии и т.п. (например, за успехи в учёбе, участие в соревнованиях, олимпиадах, написание научных работ и т.п.).

 

2.2 Логическое  проектирование

 

Между сущностями могут быть установлены связи – бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности. [4,c.89]

Кроме того, в ER-модели допускается принцип категоризации сущностей.

Представим предметную область «Учебный процесс» как взаимодействие следующих сущностей: каждый «Студент» сдает экзамен или зачет по некоторому «Предмету» согласно учебному плану. В учебном процессе участвует «Преподаватель», который осуществляет чтение учебного курса и контроль знаний «Студента». В учебном процессе также участвует «Кафедра», которая организовывает работу «Преподавателя». Обучение «Студента» ведется в «Группе» совместно с его одногруппниками.

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

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

Будем считать для простоты все связи обязательными. Между выделенными сущностями можно выделить, например, следующие связи:

1. «Студенты»  объединены в «Кафедры»(связь  М:1).

2. Работу  «Преподавателей» организуют «Кафедры» (связь М:1).

3. «Преподаватели»  имеют свои «Должности» (связь  М:1)

3. «Преподаватели»  преподают «Предметы» (связь 1:М).

5. «Кафедры»  выставляют свои «Предметы» (связь 1:М).

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3. ЭТАПЫ РЕАЛИЗАЦИИ ПОЛЬЗОВАТЕЛЬСКОГО  ПРИЛОЖЕНИЯ.

 

3.1 Создание  таблиц и  схемы данных.

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

Создание вспомогательных таблиц

  • Должность [Код_должности, Должность]
  • Кафедра [Код_ кафедры, Кафедра]
  • Форма отчетности [Код_ формы, Форма отчётности (зачет/экзамен)]
  1. Созданная таблица «Должность» для базы данных «Деканат » в режиме конструктора выглядит следующим образом (рис.1)

Рисунок 1. Таблица «Должность» в режиме Конструктора

Таблица Должность для базы данных «Деканат » в режиме таблицы выглядит следующим образом (рис.2):

Рисунок 2. Таблица «Должность» в режиме таблицы.

  1. Созданная таблица Кафедра для базы данных «Деканат» в режиме конструктора выглядит следующим образом (рис.3)

Рисунок 3. Таблица «Кафедра» в режиме Конструктора

Таблица Кафедра для базы данных «Деканат» в режиме таблицы выглядит следующим образом (рис.4)

Рисунок 4. Таблица «Кафедра» в режиме таблицы

  1. Созданная таблица «Форма отчетности» для базы данных «Деканат» в режиме конструктора выглядит следующим образом (рис.5)

 

Рисунок 5. Таблица «Форма отчетности» в режиме Конструктора

Таблица Форма отчетности для базы данных «Деканат» в режиме таблицы выглядит следующим образом (рис.6)

Рисунок 6. Таблица «Форма отчетности» в режиме таблицы

Создание основных таблиц

  • Студенты [Код_ студента, ФИО, Адрес, Дата зачисления, Код_кафедры, Группа, Задолженность (да/нет)]
  • Преподаватели [Код_препод, ФИО, Фото, Код_должности, Код_кафедры, Телефон, Код_предмета]
  • Предмет [Код_предмета, Код_предмета, Код_кафедры, Группа, Семестр, Код_формы, Число часов]

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

      1. Созданная таблица Студенты в режиме конструктора выглядит следующим образом (рис. 7).

Рисунок 7. Таблица «Студенты» в режиме Конструктора

Созданная таблица Студенты в режиме таблицы выглядит следующим образом (рис. 8).

Рисунок 8. Таблица «Студенты» в режиме таблицы

 

  1. Созданная таблица Преподаватели в режиме конструктора выглядит следующим образом (рис. 9).

Рисунок 9. Таблица «Преподаватели» в режиме Конструктора

Созданная таблица Преподаватели в режиме таблицы выглядит следующим образом (рис. 10).

Рисунок 10. Таблица «Преподаватели» в режиме таблицы

  1. Созданная таблица Предмет в режиме конструктора выглядит следующим образом (рис. 11).

Рисунок 11. Таблица «Предмет» в режиме Конструктора

Созданная таблица Предмет в режиме таблицы выглядит следующим образом (рис. 12).

Рисунок 12. Таблица «Предмет» в режиме таблицы

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

Таким образом были созданы таблицы для хранения информации о составляющих деканата.

Создание схемы данных.

Структура реляционной базы данных в Access задается схемой данных, которая имеет иерархическую структуру и называется канонической реляционной моделью предметной области.

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

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

Рисунок 13. Схема данных БД Деканат.

    1. Создание формы.

 

Форма - это объект базы данных, который можно использовать для создания интерфейса пользователя для приложения базы данных. "Привязанная" форма напрямую соединена с источником данных, например к таблице или запросу, и может использоваться для ввода, изменения или отображения данных из источника данных. Как вариант, можно создать "свободную" форму, которая не связана напрямую с источником данных, но которая все равно может содержать кнопки, надписи и другие элементы управления, необходимые для работы приложения. [1,c.48]

Формы являются наиболее удобным средством отображения данных в ACCESS. Они используются для ввода и редактирования данных.

Форму удобнее создать в режиме Мастер форм. В диалоговом окне данного режима необходимо выбрать поля таблиц, включаемых в форму.

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

  1. Форма Должность, рис. 14

Рисунок 14. Форма «Должность» в режиме формы

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

  1. Форма Студент, рис 15.

Рисунок 15. Форма «Студент» в режиме формы

Форма "Студент" выдает весь список студентов всех групп. Данный список можно преобразовывать, добавляя или удаляя студентов.

  1. Форма Кафедра, рис. 16

Форма "Кафедра" представляет информацию о кафедрах и их составляющих- это группы, студенты, адреса  и задолженности студентов. Также можно добавлять новые данные.

    1. Создание запросов.

 

Запросы - это возможность выбора определенного типа информации из существующей базы данных. Создание запросов Access  может происходить как с помощью мастера, так и вручную. Запросы делятся на два вида: запрос по образцу и структурированный. Они создаются пользователем для выборки необходимых ему данных из одной или нескольких связанных таблиц и представления выбранных данных также в виде таблицы. [1,c.54]

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

Запросы должны является параметрически универсальными и не должны содержать ошибки. Условия отбора записей должны задаваться в запросе параметрами, например,  >= [Минимальное значение] AND< [Максимальное значение], а не значениями этих параметров.

  1. Запрос «Задолжники» представлен на рис 17.

Рисунок 17. Запрос «Задолжники» в режиме Конструктора

Рисунок18. Результат выполнения запроса «Задолжники»

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

  1. Запрос «Зачисленные в 2011г» представлен на рис 19.

Рисунок 19. Запрос «Зачисленные в 2011г» в режиме Конструктора

Рисунок 20. Результат выполнения запроса «Зачисленные в 2011г»

  1. Запрос «Зачисленные в 2012» представлен на рис 21.

Информация о работе Разработка БД "Деканат"