Курсовая работа (т): Автоматизированное рабочее место преподавателя. Учёт посещаемости и успеваемости студентов

Эти функции позволяют использовать существующий сертификат для шифрования данных (наиболее безопасный метод), простой ключ (пароль) или ассиметричный ключ (пару открытый/закрытый ключ). SQL Server может создавать и управлять своими сертификатами для обеспечения очень мощного шифрования данных, хранимых в базе данных. Transact - SQL в SQL Server был улучшен для поддержки управления сертификатами: Создание сертификата:

CERTIFICATE MyCertSUBJECT = ‘My Subject’,PASSWORD = ‘jfdsij380fukanfjcxvDJEOD#$fksdwr’,_DATE = ‘12/31/2009’;

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

@VAL nvarchar(8000)@VAL = EncryptByCert(Cert_ID(‘MyCert’), N’Some Message’)

Далее можно прочесть это значение из поля или переменной при помощи функции DecryptByCert:

SELECT CAST(DecryptByCert(Cert_ID(‘MyCert’), @VAL, N’ jfdsij380fukanfjcxvDJEOD#$fksdwr’) AS nvarchar)

1.11 Реализация доступа к серверу и базе данных

Итак, гораздо более удобным и эффективным является подход, когда доступ к SQL Server 2008 предоставляется целым группам пользователей. Как раз такой подход возможен при аутентификации средствами Windows NT/2000, когда на уровне домена создается несколько групп, каждая из которых предназначена для решения специфических задач. На уровне SQL Server 2008 такой группе разрешается доступ к серверу, предоставляются необходимые права доступа к базам данных и их объектам. Достаточно включить учетную запись Windows NT в одну из групп, и пользователь получит все права доступа, предоставленные этой группе. Более того, одна и та же учетная запись может быть включена во множество групп Windows NT, что даст этой учетной записи возможность пользоваться правами доступа, предоставленными всем этим группам. Администратор SQL Server 2008 должен сам решить, как удобнее предоставлять доступ к серверу: персонально каждой учетной записи или группе в целом.

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

Приложение запускается на некотором компьютере пользователя сети университета, если этот пользователь входит в домен организованный администраторами сети университета, то он успешно аутентифицируется в Windows. Чтобы он мог получить доступ к SQL серверу необходимо при установке SQL Server, и с помощью SQL Server Management studio настроить режим аутентификации - режим аутентификации средствами Windows NT\2000.

Теперь нужно завести в SQL Server учетные записи (логины) для пользователей которым необходимо получать доступ SQL Server, но сначала удобнее на уровне Windows средствами администрирования Active Directory объединить пользователей нуждающихся в доступе к SQL Server в группы, в зависимости от того какие цели преследуют данные пользователи. У нас будут три группы пользователей:

·        Преподаватели

·        Старосты

·        Студенты

Необходимо добавить соответствующие учетные записи. Таким образом будет организовано три доменные группы. Далее необходимо в SQL Server завести учетную запись для каждой группы и дать разрешение на присоединение к базе данных.

2. Описание предметной области

.1 Задачи Веб-приложения

Веб-приложение позволит разным категориям пользователей выполнять различные функции:

Для студента:

·   ознакомление с расписанием;

·        ознакомление со списком заданий, необходимых к сдаче по предмету;

·        ознакомление с результатами контрольных точек, с результатами сданных заданий, с посещаемостью.

Для преподавателя:

·   добавление заданий, необходимых к сдаче по дисциплине;

·        выставление оценок и учёт посещаемости студентов по его дисциплине;

·        выставление оценок за контрольную неделю;

·        изменение расписания.

Для старосты:

·   выставление оценок и учёт посещаемости студентов по дисциплинам;

·        выставление оценок за контрольную неделю.

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

·   пользователям не обязательно знать язык веб-программирования, управление посещаемостью и успеваемостью студентов производится через дружественный пользовательский веб-интерфейс;

2.2 Разработка базы данных

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

Подготовить проект базы данных, позволяющей хранить информацию:

·        о посещаемости студентов дисциплины;

·        об успеваемости студентов по дисциплине;

·        данные о представителях всех категорий пользователей,

·        информацию о доступах.

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

Разработать веб-интерфейс для трёх типов пользователей:

·        староста;

·        преподаватель.

.3 Выбор средств реализации

Выбор СУБД является одним из важнейших моментов в разработке проекта БД, так как он принципиальным образом влияет на весь процесс проектирования БД и реализацию информационной системы. При выборе СУБД необходимо учитывать десятки факторов. На практике же стараются выбрать такую СУБД, которая будет удовлетворять нескольким наиболее важным критериям:

·        стоимость СУБД и дополнительного программного обеспечения;

·        тип модели данных, которую поддерживает данная СУБД, её адекватность потребностям рассматриваемой предметной области;

·        характеристики производительности системы;

·        удобство и надежность СУБД в эксплуатации;

Выбор инструментальных средств базы данных начинается с выбора модели базы данных. Несомненно, выбор был сделан в пользу реляционной модели базы данных. Этот выбор обусловлен следующими факторами: во-первых, такая модель освобождает пользователя от знания особенностей файловой структуры, используемой для хранения данных, во-вторых, реляционная модель основывается на теории множеств, хорошо разработанной в математике, и, наконец, это самая распространенная модель, так как все ведущие производители СУБД поддерживают именно ее.

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

В отношении программных средств реализации серверной части выбор был сделан в пользу пакета Microsoft SQL Server 2008.

Особенности:

·        самая быстрая в изучении, создании и развёртывании простых приложений, работающих с данными;

·        наиболее доступное и простое в использовании решение для небольших отделов и развивающихся бизнесов;

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

Ко всему прочему, SQL Server - это комплексное, интегрированное, законченное решение обработки данных, предоставляющее всем пользователям организации наиболее безопасную, надежную и производительную платформу для данных предприятия. Server 2008 предоставляет как IT-профессионалам, так и информационным работникам знакомый инструментарий, снижая сложность создания, развертывания, управления и использования приложений обработки и анализа данных предприятия на целом ряде платформ, от мобильных устройств до систем хранения данных масштаба предприятия.

Обладая широким набором возможностей и поддерживая совместную работу с существующими системами и способностью автоматизировать рутинные задачи, SQL Server 2008 является законченным решением управления данными для предприятия любого масштаба.

Для реализации клиентской части комплекса выбрана технология “ASP.NET” как наиболее удобная и распространённая технология для создания web-приложений, работающих с базами данных.

При разработке использовались нестандартные компоненты Dxperience-9.1.4

3. Формирование концептуальной модели базы данных

.1 Диаграмма DFD

Контекстная диаграмма DFD (Data Flow Diagram - диаграммы потоков данных) (рис.2) показывает, какие существуют типы пользователей, и какие инструменты взаимодействия с системой они имеют.

Рис.2. DFD-диаграмма

.2 Инфологическое проектирование БД

Рис.3. Инфологическая модель.

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

.3 Физическое проектирование БД

На этапе физического проектирования БД происходит увязка логической структуры БД и физической среды хранения для обеспечения наиболее эффективного размещения данных. Диаграммы “сущность-связь” (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними.

Рис.4. Диаграмма “сущность-связь” (ER-Диаграмма).

Фактически с помощью ER-диаграмм осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). Ниже приведена ER-диаграмма, построенная стандартными средствами Microsoft SQL Server 2008 (10.0.1600.22).

.4 Описание базы данных

База данных состоит из 7 таблиц, опишем каждую таблицу.

Таблица «GRADES» содержит оценки студентов.

Поля:

·        StudentID (FK, bigint, not null): Внешний ключ, тип - целочисленный. Студент, которому выставлена оценка.

·        TaskID (FK, bigint, not null): Внешний ключ, тип - целочисленный, по умолчанию не 0. Задание, за которое выставлена оценка.

·        Grade (int, null): тип - целочисленный. Оценка.

·        IsPass (int, null): тип - целочисленный. Засчитано/не засчитано.

Таблица «OrgTree» содержит общую структуру, студентов, преподавателей, группы.

Поля:

·        ID (PK, bigint, not null): Первичный ключ, большое целое, по умолчанию не 0. Идентификатор.

·        ParentID (FK, bigint, null): Внешний ключ, большое целое. Группа для студентов.

·        OrgType(int, not null): тип - целочисленный, по умолчанию не 0. 0 - студент, 1 - староста, 2 - группа, 3 - преподаватель 4 - специальность, 5 - факультет.

·        LoginName(nvarchar(250), null): тип - символьный (250 символов). Логин, для преподавателей.

·        DisplayName(nvarchar(50), null): тип - символьный (50 символов). Имя и Отчество, для преподавателей.

·        GroupName(nvarchar(250), null): тип - символьный (250 символов) - Название группы, для групп.

·        Role(varchar(50), null): тип - символьный (50 символов). Не используется.

·        Name(nvarchar(250), null): тип - символьный (250 символов). Фамилия Имя Отчество, для студентов.

·        SpecialityName(varchar(100), null): тип - символьный (100 символов). Не используется.

·        FacultyName(varchar(100), null): тип - символьный (100 символов). Не используется.

Таблица «SHEDULE» отображает информацию о расписании.

Поля:

·        ID (PK, bigint, not null): Первичный ключ, тип - большое целое, по умолчанию не 0. Идентификатор.

·        GroupID (FK, bigint, not null): Внешний ключ, тип - большое целое, по умолчанию не 0. Группа, у которой занятие.

·        TeacherID (FK, bigint, not null): Внешний ключ, тип - большое целое, по умолчанию не 0. Преподаватель, ведущий занятие.

·        SubjectID (FK, bigint, not null): Внешний ключ, тип - большое целое, по умолчанию не 0. Предмет.

·        TimeID (FK, bigint, not null): Внешний ключ, тип - большое целое, по умолчанию не 0. Время (какая пара по счёту).

·        Date(datetime, not null): тип - дата, по умолчанию не 0. Дата.

·        Comment(varchar(500), null): тип - символьный (500 символов). Комментарий преподавателя к занятию.

·        AssignedFileURL(varchar(250), null): тип - символьный. Доп.файлы.

Таблица «SUBJECTS» отображает информацию о предметах.

Поля:

·        ID(PK, int, not null): Первичный ключ, тип - целочисленный, по умолчанию не 0. Идентификатор.

·        SubjectName(nvarchar(200), not null): тип - символьный (200 символов), по умолчанию не 0. Название предмета.

·        TeacherID(FK, bigint, not null): Внешний ключ, тип - большое целое, по умолчанию не 0. Идентификатор преподавателя.

·        SubjectType(int, null): тип - целочисленный. Лекция/практика.

Таблица «TASKS» хранит информацию о заданиях.

·        ID(PK, bigint, not null): Первичный ключ, тип - большое целое, по умолчанию не 0. Идентификатор.

·        ParentID(FK, bigint, null): Внешний ключ, тип - большое целое. Указывает на тему задания.

·        TaskName(nvarchar(150), not null): тип - символьный (150 символов), по умолчанию не 0. Название(Тема задания).

·        TaskText(nvarchar(max), null): тип - символьный. Формулировка задания.

·        Priority(int, null): тип - целочисленный. Приоритет задания.

·        StartDate(datetime, null): тип - дата и время. Время начала задания.

·        EndDate(datetime, null): тип - дата и время. Время конца задания.

·        GroupID(FK, bigint, not null): Вешний ключ, тип - большое целое, по умолчанию не 0. Идентификатор группы.

·        TeacherID(FK, bigint, not null): Внешний ключ, тип - большое целое, по умолчанию не 0. Идентификатор преподавателя.

·        SubjectID(FK, int, null): Внешний ключ, тип - целочисленный. Идентификатор предмета.

·        AssignedFileURL(varchar(250), null): тип - символьный (250 символов). Доп.файлы.

Таблица «VISITS» отображает информацию об успеваемости и посещаемости студентов.

Поля:

·        SheduleID(FK, bigint, not null): Внешний ключ, тип - большое целое, по умолчанию не 0. Идентификатор расписания.

·        StudentID(FK, bigint, not null): Внешний ключ, тип - большое целое, по умолчанию не 0. Идентификатор студента.

·        IsVisit(int, not null): тип - целочисленный, по умолчанию не 0. Был/не был.

·        Comment(varchar(500), null): тип - символьный (500 символов). Комментарий преподавателя.

Таблица «TIME» отображает информацию о времени проведения занятий.

Поля:

·        ID(PK, int, not null): Первичный ключ, тип - целочисленный, по умолчанию не 0. Идентификатор.

·        TimeName(varchar(150), not null): тип - символьный (150 символов), по умолчанию не 0. Название времени.

4. Описание интерфейса

.1 Описание интерфейса аутентификации и интерфейса администратора

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

Рис.5 Страница приветствия

После авторизации пользователь попадает на главную страницу в соответствии со своей ролью (преподаватель, староста, студент). В нашем случае это главная страница преподавателя.