Программное обеспечение для автоматизации процесса учета успеваемости и посещаемости студентов
Курсовой проект - Компьютеры, программирование
Другие курсовые по предмету Компьютеры, программирование
пов СУБД MySQL Migration Toolkit и несколько вспомогательных утилит.
Кроме того существуют сторонние разработки, такие как упоминавшийся выше phpMyAdmin, развивающийся достаточно давно и имеющий функциональностью достаточную для работы со структурой и наполнением БД и базового ее администрирования.
Развертывание системы аналогично развертыванию MS SQL Server и достаточно простое, заключается в установке сервера, создании на нем БД необходимой структуры и установки на каждый клиент необходимых библиотек для доступа к нему и настройки DSN.существует как в версии для Windows, так и для многих других платформ, многие Unix-системы имеют в своем дистрибутиве какую-либо версию MySQL.
5. ЛОГИЧЕСКАЯ МОДЕЛЬ БАЗЫ ДАННЫХ
.1 Представление модели
Программное обеспечение или автоматизированная система учета успеваемости может использоваться многими преподавателями одной кафедры, факультета, института, учебного заведения, тогда база данных такой системы сможет аккумулировать сводную информацию о посещаемости и успеваемости и может быть использована для оценки рейтинга студента.
Моделирование связано с представлением семантики предметной области в модели базы данных, т.е. моделирование структур данных, опираясь на смысл этих данных. Наиболее распространена модель сущность-связь.
Модель сущность-связь является концептуальной моделью, т.е. не учитывает особенности конкретной СУБД. Из нее могут быть получены все основные фактографические модели данных.
Модели сущность-связь удобны тем, что процесс создания модели является итерационным. Разработав первый приближенный вариант модели, можно уточнять ее, опрашивая экспертов предметной области. При этом документацией, в которой фиксируются результаты бесед, является сама модель сущность-связь.
Основными понятиями модели сущность-связь являются: сущность, связь и атрибут.
Так для рассматриваемой задачи для разработки модели необходимы следующие сущности:
дисциплина - сущность необходимая для хранения перечня названий предметов и краткого описания данного предмета;
преподаватель - сущность необходимая для хранения списка преподавателей;
студент - сущность необходимая для хранения списка студентов;
группа - сущность необходимая для хранения списков учебных групп.
Между сущностями Преподаватель и Дисциплина существует связь многие ко многим, так как теоретически любой преподаватель может вести любую дисциплину (предмет), с другой стороны одну и ту же дисциплину может вести любой преподаватель.
Рис. 1. Концептуальная модель предметной области
Не смотря на то, что предложенная модель достаточно полно описывает поставленную задачу, в ней есть некоторые недостатки. Эти недостатки заключаются в том, что модель не учитывают группирование некоторых видов данных. Так все преподаватели работают на определенных кафедрах, учебные группы так же закреплены за определенными кафедрами, кроме кафедр присутствует более крупные единицы группировки - факультеты и институты.
С учетом вышесказанного и обеспечения возможности детального проектирования базы данных используется детализированная концептуальная модель предметной области. Эта модель учитывает возможность объединения учебных групп по кафедрам, как административным единицам. Кафедры так же в себя включают преподавателей, при этом связь между сущностями Преподаватель и Кафедра установлена многие ко многим, так как один и тот же преподаватель может работать на одной и более кафедрах. Кроме этого сущность Учебный план предполагает наличие четко сформулированного плана изучения дисциплины. При этом учебный план достаточно сильно зависит от преподавателя, преподающего ту или иную дисциплину.
Дальнейшее развитие инфологической модели на данном этапе не целесообразно, так как оно приведет к проектированию логической модели конкретной СУБД.
Рис. 2. Концептуальная модель предметной области
Построенная модель позволяет достаточно хорошо представить взаимодействие между сущностями рассматриваемой предметной области и перейти к этапу функционального проектирования автоматизированной
системы.
6. ПРЕДСТАВЛЕНИЕ МАКЕТА ИНТЕРФЕЙСА
.1 Архитектура
Данное программное средство может иметь следующую архитектуру:
Рис. 3. Архитектура программного средства
Для работы с системой каждый преподаватель должен быть зарегистрирован в БД. Вход в систему осуществляется стандартным для web приложений способом, т.е. вводом логина и пароля, который выдает администратор.
Примерный макет страницы выглядит следующим образом:
Рис. 4. Главная страница
Одной из особенностью данного модуля будет является переход на главную страницу. При перемещении попадаем не в саму базу данных, а на страницу с оригинальным дизайном, содержащим много графической информации. Далее всю работу выполняет меню, в котором и содержатся ссылки для перехода к нужным данным: факультеты, кафедры и далее группы.
Дизайну страницы отводится немаловажное значение. Хотя можно сказать, что для подобных систем это не так важно, а важен сам доступ к информации и малый объем системы для корректной работы. Однако разработчиками сделан большой акцент на оформление, что, как предполагается, сделает переход между страниц