Разработка автоматизированной информационной системы "Электронный журнал"
Назначение создания информационной системы "Электронный журнал" для автоматизации контроля учебного процесса. Построение логической и реляционной моделей данных. Разработка клиент-серверного приложения для работы с базой данных; программная реализация.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 19.01.2017 |
Размер файла | 5,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
СОДЕРЖАНИЕ
- Введение
- 1. Современные методы автоматизации контроля учебного процесса
- 1.1 Понятие «Электронный журнал»
- 1.2 Обзор современных программных средств для решения задачи ведения электронного журнала
- 2. Постановка задачи
- 2.1 Назначение, цели создания информационной системы
- 2.2 Требования к информационной системе
- 3. Функционально-ориентированное проектирование информационной системы
- 3.1 Основные элементы модели
- 3.2 Построение контекстной диаграммы
- 3.3 Построение диаграмм декомпозиции IDEF0
- 4. Проектирование информационного обеспечения системы
- 4.1 Информационный анализ предметной области и выделение информационных объектов
- 4.2 Построение логической модели данных
- 5. Проектирование реляционной базы данных
- 5.1 Описание реляционной модели
- 5.2. Описание таблиц базы данных
- 5.3 Выбор СУБД
- 6. Разработка клиент-серверного приложения для работы с базой данных
- 6.1 Технология «клиент-сервер»
- 6.2 Средства программирования разрабатываемого приложения
- 6.3 Программная реализация модуля «Преподаватель»
- 6.4 Программная реализация модуля «Руководитель группы»
- 6.5 Программная реализация модуля «Администратор заведения»
- 6.6 Программная реализация модуля «Родитель»
- 6.7 Программная реализация модуля «Технический администратор системы»
- 7. Технико-экономическое обоснование проекта
- 7.1 Цель работы
- 7.2 Определение состава работ
- 7.3 Определение трудоемкости разработки
- 7.4 Расчёт сметной стоимости модуля
- 7.5 Оценка качества системы учета нагрузки преподавателей
- Заключение
- Список использованных источников
- Приложение А. Итоги рубежного контроля
- Приложение Б. Журнал учебных занятий
- Приложение В. Ведомость учета посещаемости
- Приложение Г.Установление функциональных зависимостей
- Приложение Д. Экономическая часть
ВВЕДЕНИЕ
Современные информационные технологии быстрыми темпами внедряются во все сферы человеческой деятельности, в том числе и в сферу образования. Уровень развития информационных ресурсов и характер их использования в значительной мере влияет на благосостояние общества и эффективность осуществления той или иной профессиональной деятельности. Лидирующие позиции любой организации определяются в первую очередь ее возможностями по грамотному использованию передовых достижений в сфере информационных технологий. Особую роль при этом играет сфера образования, где формируется интеллектуальный потенциал страны, потребляющий и создающий ее информационные ресурсы.
Информатизация -- это комплекс работ, направленный на разработку, внедрение, сопровождение, развитие и замену во всех сферах деятельности традиционных технологий на более эффективные информационно-телекоммуникационные технологии.
Внедрение АИС направлено на решение задач планирования, учета, контроля, обмена информацией, регистрации и хранения данных, на повышение эффективности делопроизводства, снижения доли бумажного документооборота, увеличения точности аналитических работ.
На сегодняшний день развитие Веб-технологий вносит новые преимущества в проектирование и разработку таких систем. Современные средства создания Веб-технологий сопоставимы и не уступают по скорости и удобству с обычными настольными приложениями, являясь при этом доступными в любое время и из любой точки мира, не требующими специализированного программного обеспечения и операционной системы. Эти достоинства наталкивают заказчиков, а, следовательно, и разработчиков, к созданию именно приложений с Веб-интерфейсом, как замены настольным решениям или локальным решениям.
Вологодский Государственный Университет уже долгие годы ведет активную и весьма успешную работу в направлении информатизации учебного процесса для повышения качества образования.
Одной из систем, часто внедряющейся, в связи с её необходимостью использования, является электронный журнал успеваемости, который автоматизирует процесс контроля за успеваемостью, дублирует записи традиционного, бумажного журнала, защищая его от искажений, даёт возможность контролировать накопляемость оценок по предметам и т.д.
Целью данной работы является построение модели информационной системы «Электронный журнал» и разработка web-приложения для автоматизации процесса ведения журнала успеваемости и посещаемости.
Основными задачами проекта являются:
— Разработка функциональной модели системы;
— Разработка логической модели системы;
— Разработка физической модели системы;
— Разработка базы данных;
— Разработка приложения для работы с БД.
1. Современные методы автоматизации контроля учебного процесса
1.1 Понятие «Электронный журнал»
Любое образовательное учреждение сталкивается с большим потоком документооборота. Преподаватели ежедневно выполняют десятки манипуляций по отбору нужной информации, заполняют классный журнал.
На сегодняшний день уровень информационных технологий достаточно высок, и все большее количество электронной документации приобретает официальный статус, заменяя физические источники. Таким образом, информационные технологии позволяют реализовать систему дополнительного контроля успеваемости учащихся, автоматизируя при этом данный процесс в учебном заведении.
Электронный журнал -- это удобный, мощный инструмент для создания единого информационно-образовательного пространства учебного заведения и взаимодействия образовательного учреждения с родителями учащихся.
Так как электронный журнал -- это информационная система, то все данные об учащихся и учебном процессе достаточно заполнить один раз, а в будущем только дополнять, или исправлять при необходимости.
1.2 Обзор современных программных средств для решения задачи ведения электронного журнала
На крупном уровне есть разные реализации схожих систем. В других странах автоматизация учебного процесса стоит на еще наиболее высочайшем уровне, нежели в учреждениях нашей страны. Наверное, связано как и с всеобщим отставанием наше страны в информационных технологиях, так и с широким развитием в западных государствах удаленного образования. Последнее, стимулирует автоматизации действий в образовании, введению web-интерфейсов доступа к средствам автоматизации. Учащийся ВУза, который учится дистанционно, имеет возможность иногда проверить положение дел лишь через интернет, потому доступ к собственной учетной записи чрез всемирную сеть обязателен для успешного введения удаленного образования.
В России степень развития дистанционного образования только начинает набирать обороты. Потому численность подобных сервисов еще не в такой мере, как за рубежом. При этом почти все из учреждений, которые вводят дистанционное обучение и сервисы успеваемости учащихся, считаются отделениями зарубежных институтов и средних учебных заведений. К схожим реализациям в России стоит отнести программное обеспечение контролирования успеваемости в средних школах, которое ориентировано на извещение родителей о положении дел детей. Такие решения разрабатываются частными компаниями. Так, во многих школах города внедрена система электронных дневников студентов, при помощи которых родители студентов имеют все шансы осуществлять контроль за собственными детьми. Но почти все из данных сервисов не дают доступа к данным по успеваемости подростков чрез сеть Интернет. Однако, не смотря на это, формирование таковых «электронных журналов» -- не плохая предпосылка большего развития схожих систем в гораздо больших масштабах.
Из планов, схожих разрабатываемому, следует выделить ресурс «Образовательный портал дистанционного обучения» Вологодского Государственного Университета, построенный на платформы MOODLE, который еще считается неплохим образцом веб-сервиса для учащихся в образовательных целях. Система нацелена, прежде всего, на организацию взаимодействия между педагогом и учащимися, но и подойдет для организации обычных дистанционных курсов, а так же помощи в очном обучении. Ресурс имеет возможность использоваться студентами при условии получении регистрационных данных у педагога, разместившего курс.
Наиболее удачные реализации системы «Электронный журнал» в России являются:
· www.antcol.ru/jur -- Журнал успеваемости студентов Международного Колледжа Туризма (рис. 1.2.1).
Рис. 1.2.1 -- Журнал успеваемости студентов Международного Колледжа Туризма
· www.emsy.org -- Независимый онлайн-cервис электронных журналов успеваемости, ориентированный на образовательные учреждения стран СНГ -- школы, дошкольные учреждения, лицеи, колледжи, техникумы, институты, центры сертификации и другие. Основная функция сервиса -- организация и ведение журналов оценок в сети Интернет (рис. 1.2.2).
· www.dnevnik.ru -- Всероссийская бесплатная школьная образовательная сеть (рис. 1.2.3).
Рис. 1.2.2 -- Независимый онлайн-cервис электронных журналов www.emsy.org
Рис. 1.2.3 -- Всероссийская бесплатная школьная образовательная сеть www.dnevnik.ru
Изучив имеющиеся решения сообразно теме, можно сделать вывод, что предоставленная проблема считается не до конца решенной, что дает большие возможности для будущего исследования и улучшения. Наверное, в особенности актуально для нашей страны в целом и для Вологды в частности. Осуществление web-обслуживания электронного журнала имеет принципиальное практическое значение для учащихся, т.к. позволит им следить за своим положение дел в учебном заведении в любое время и из любого места с доступностью всемирной паутины. Так же облегчает контроль родителей над своими детьми(успеваемости и посещаемости).
2. Постановка задачи
2.1 Назначение, цели создания информационной системы
Разрабатываемая информационная система должна вести автоматизированный учет успеваемости и посещаемости студентов.
Информационная система «Электронный журнал» предназначена для комплексного информационно-аналитического обеспечения процессов учебного заведения, в части исполнения следующих функций:
ввод и редактирование данных об успеваемости студентов;
ввод и редактирование данных о посещаемости студентов учебных занятий;
ввод и редактирование списка студентов, списка групп и списка специальностей;
ввод и редактирование учебного плана;
вывод успеваемости по заданным параметрам;
вывод посещаемости.
Информационную систему «Электронный журнал» предполагается использовать в учебных заведениях, которые решают описанные выше функции.
Основными целями создания информационной системы являются:
повышение эффективности исполнения процессов, перечисленных выше, путем сокращения непроизводительных и дублирующих операций, операций, выполняемых «вручную», оптимизации информационного взаимодействие участников процессов;
повышение качества принятия управленческих решений за счет оперативности представления, полноты, достоверности и удобства форматов отображения информации;
повышение информационной открытости и прозрачности деятельности учебного заведения;
повышение удобства и комфорта при получении информации о предоставляемых услугах потребителю.
2.2 Требования к информационной системе
Ключевыми требованиями к создаваемой системе являются:
— открытость, то есть она должна соответствовать всем современными стандартами, поддержка Веб-технологий, а также возможность добавления функционала как сторонних разработчиков, так и наработок учащихся;
— масштабируемость, как ключевое требование с точки зрения экономии. Не придется заново перестраивать систему при наращивании функционала;
— Кроссплатформенность, способность работать на различных устройствах, операционных системах, серверах;
— адаптируемость, то есть возможность простой настройки под нужды заказчика;
— расширяемость, то есть возможность наращивания функциональных возможностей системы, не изменяя принятого ранее метода развития и базы,
— локализация, то есть поддержка национальных требований и стандартов в области документооборота, организации процесса обучения, особенностей Российской системы образования.
Основные требования к разрабатываемой информационной системе относительно функциональных возможностей состоят в следующем:
— Система должна обеспечивать конфиденциальность информации таким образом, что персональные данные студента может просматривать только он сам, его родители и педагогический персонал техникума, а вносить изменения -- только соответствующие педагоги;
— Студент закреплен за одной из групп, а группа, в свою очередь, закреплена за одной из специальностей;
— Каждая дисциплина закреплена за одной из групп, а также за одним из преподавателей;
— Код студента является уникальным и неизменным;
— Номера дисциплин, групп, специальностей уникальны и неизменны, а их наименования могут изменяться.
3. Функционально-ориентированное проектирование информационной системы
3.1 Основные элементы модели
В таблице 3.1.1 приведены основные элементы модели информационной системы.
Таблица 3.1.1
Основные элементы модели предметной области
Название проекта: |
Проектирование информационной системы для ведения учета успеваемости и посещаемости студентов |
|
Цель проекта: |
Подготовить рабочую модель бизнес процесса ведения учета успеваемости и посещаемости студентов |
|
Технология моделирования: |
Метод функционального моделирования IDEF0. |
|
Инструментарий: |
Программный продукт BPWin 4.0 |
|
Список данных: |
Список специальностей; Список групп; Список дисциплин; Список студентов; Успеваемость; Посещаемость. |
|
Перечень функций: |
А0. Ведение электронного журнала успеваемости и посещаемости А1. Ввод и редактирование данных А1.1. Ввод специальностей А1.2. Ввод групп А1.3. Ввод дисциплин А1.4. Ввод студентов А1.5. Ввод успеваемости А1.6. Ввод посещаемости А2. Обработка запроса пользователя А2.1. Выбор параметров запроса А2.2. Обработка запроса |
В таблице 3.1.2 приведено описание функциональных блоков модели предметной области.
Таблица 3.1.2
Описание функциональных блоков
Наименование блока |
Описание решаемых задач |
|
А1. Ввод и редактирование данных |
Данный блок включает в себя все этапы ввода и редактирования данных |
|
А2. Обработка запроса пользователя |
Данный блок содержит все этапы обработки запроса пользователя |
3.2 Построение контекстной диаграммы
Самая верхняя диаграмма, на которой объект моделирования представлен единственным блоком с граничными стрелками. Эта диаграмма называется A-0. Стрелки на этой диаграмме отображают связи объекта моделирования с окружающей средой. Поскольку единственный блок представляет весь объект, его имя - общее для всего проекта. Это же справедливо и для всех стрелок диаграммы, поскольку они представляют полный комплект внешних интерфейсов объекта. Диаграмма A-0 устанавливает область моделирования и ее границу.
Контекстная диаграмма A-0 также должна содержать краткие утверждения, определяющие точку зрения должностного лица или подразделения, с позиций которого создается модель, и цель, для достижения которой ее разрабатывают. Эти утверждения помогают руководить разработкой модели и ввести этот процесс в определенные рамки. Точка зрения определяет, что и в каком разрезе можно увидеть в пределах контекста модели. Изменение точки зрения, приводит к рассмотрению других аспектов объекта. Аспекты, важные с одной точки зрения, могут не появиться в модели, разрабатываемой с другой точки зрения на тот же самый объект. Формулировка цели выражает причину создания модели, т.е. содержит перечень вопросов, на которые должна отвечать модель, что в значительной мере определяет ее структуру. Наиболее важные свойства объекта обычно выявляются на верхних уровнях иерархии; по мере декомпозиции функции верхнего уровня и разбиения ее на подфункции, эти свойства уточняются. Каждая подфункция, в свою очередь, декомпозируется на элементы следующего уровня, и так происходит до тех пор, пока не будет получена релевантная структура, позволяющая ответить на вопросы, сформулированные в цели моделирования. Каждая подфункция моделируется отдельным блоком. Каждый родительский блок подробно описывается дочерней диаграммой на более низком уровне. Все дочерние диаграммы должны быть в пределах области контекстной диаграммы верхнего уровня.
Работы (Activity) обозначают поименованные процессы, функции или задачи, которые происходят в течение определенного времени и имеют распознаваемые результаты. Работы изображаются в виде прямоугольников. Все работы должны быть названы и определены. Имя работы должно быть выражено отглагольным существительным, обозначающим действие (например, «Ведение электронного журнала успеваемости и посещаемости»). Работа «Ведение электронного журнала успеваемости и посещаемости» может иметь, например, следующее определение: «Это модель, которая описывает процесс многократного введения и редактирования персональных данных студентов и последующего их вывода пользователю». При создании новой модели автоматически создается контекстная диаграмма с единственной работой, изображающей систему в целом.
Взаимодействие работ с внешним миром и между собой описывается в виде стрелок. Стрелки представляют некоторую информацию и именуются существительными. Различают 4 вида стрелок:
— Входные. Они ставятся с левой стороны и описывают материал или информацию, которая преобразуется в данной работе;
— Выходные. Они ставятся с правой стороны и описывают материал или информацию, которая производится данной работой (обязательно должна присутствовать хотя бы одна стрелка этого вида);
— Управление -- правила, процедуры или стандарты, нормативные акты, на основе которых должна осуществляться данная работа (также должна присутствовать хотя бы одна стрелка);
— Ресурсы или механизмы (материальные, трудовые, финансовые ресурсы).
На рис. 3.2.1 представлена контекстная диаграмма «Ведение электронного журнала и посещаемости».
Рис. 3.2.1 -- Контекстная диаграмма «Ведение электронного журнала успеваемости и посещаемости»
3.3 Построение диаграмм декомпозиции IDEF0
После описания системы в целом ведется разбиение ее на большие фрагменты. Данный процесс именуется функциональной декомпозицией, а диаграммы, которые обрисовывают любой фрагмент и взаимодействие фрагментов, именуются диаграммами декомпозиции. После декомпозиции контекстной диаграммы ведется декомпозиция каждого большого фрагмента системы на наиболее маленькие и т.д., до достижения подходящего значения подробности описания. После каждого сеанса декомпозиции делаются сеансы экспертизы -- специалисты предметной области показывают на соотношение реальных бизнес-процессов сделанным диаграммам. Найденные несоответствия исправляются, и лишь после прохождения экспертизы в отсутствии замечаний разрешено приступать к последующему сеансу декомпозиции. Так достигается соотношение модели реальным бизнес-процессам на любом уровне модели. Синтаксис описания системы в целом и каждого ее фрагмента схож на протяжении построения всей модели.
Диаграммы декомпозиции содержат схожие работы, т.е. дочерние работы, имеющие единую родительскую работу. При разработке диаграммы декомпозиции надлежит указать нотацию новой диаграммы и численность работ на ней. Возможный перерыв количества работ -- 2-8. Декомпозировать работу на одну работу не имеет смысла: диаграммы с численностью работ больше 8 получаются сверх насыщенными и некорректно читаются. Для обеспечения наглядности и лучшего осмысливания имитируемых процессов рекомендовано применять от 3-х до 6 блоков на одной диаграмме. Если как оказалось, что количество работ недостаточно, то работу разрешено добавить в диаграмму, щелкнув поначалу по кнопочке на палитре инструментов, а потом по свободному месту на диаграмме.
Работы на диаграммах декомпозиции традиционно размещаются по диагонали от левого верхнего угла к правому нижнему. Таковой распорядок именуется в левом верхнем углу помещается самая принципиальная работа, исполняемая по времени первой. Дальше вправо книзу размещаются наименее принципиальные или исполняемые позже работы. Такое расположение упрощает чтение диаграмм, не считая того, на нем базируется понятие взаимосвязей работ (рис. 3.3.1).
Каждая из работ на диаграмме декомпозиции может быть в свою очередь декомпозирована (рис. 3.3.2). На диаграмме декомпозиции работы нумеруются автоматически слева направо. Номер работы показывается в правом нижнем углу.
Рис. 3.3.1 -- Декомпозиция первого уровня для процесса «Ведение электронного журнала успеваемости и посещаемости»
Рис. 3.3.2 -- Декомпозиция второго уровня для процесса «Ввод данных»
Диаграмма декомпозиции предназначена для детализации работы. В отличие от моделей, отображающих структуру организации, работа на диаграмме верхнего уровня в IDEF0 -- это не элемент управления нижестоящими работами. Работы нижнего уровня -- это то же самое, что работы верхнего уровня, но в более детальном изложении. Как следствие этого границы работы верхнего уровня -- это то же самое, что границы диаграммы декомпозиции.
При декомпозиции работы входящие в нее и исходящие из нее стрелки (кроме стрелки вызова) автоматически появляются на диаграмме декомпозиции (миграция стрелок), но при этом не касаются работ.
Для связывания стрелок входа, управления или механизма необходимо перейти в режим редактирования стрелок, щелкнуть по наконечнику стрелки и потом по соответствующему сегменту работы. Для связывания стрелки выхода необходимо перейти в режим редактирования стрелок, щелкнуть по сегменту выхода работы и затем по стрелке.
Для связи работ между собой используются внутренние стрелки, то есть стрелки, которые не касаются границы диаграммы, начинаются у одной и кончаются у другой работы.
Для рисования внутренней стрелки необходимо в режиме рисования стрелок щелкнуть по сегменту (например, выхода) одной работы и затем по сегменту (например, входа) другой. В IDEF0 различают следующие типы связей работ.
— Связь по входу (output-input), когда стрелка выхода вышестоящей работы направляется на вход нижестоящей (например, на рис. 2 стрелка «Ведомость учета продукции» связывает работы «Ввод и редактирование данных о выпуске продукции» и «Поиск данных о продукции»);
— Связь по управлению (output-control), когда выход вышестоящей работы направляется на управление нижестоящей. Связь по управлению показывает доминирование вышестоящей работы. Данные или объекты выхода вышестоящей работы не меняются в нижестоящей;
— Обратная связь по входу (output-input feedback), когда выход нижестоящей работы направляется на вход вышестоящей. Такая связь, как правило, используется для описания циклов;
— Обратная связь по управлению (output-control feedback), когда выход нижестоящей работы направляется на управление вышестоящей.
Явная стрелка имеет источником одну-единственную работу и назначением тоже одну-единственную работу.
Разветвляющиеся и сливающиеся стрелки. Одни и те же данные или объекты, порожденные одной работой, могут использоваться сразу в нескольких других работах. С другой стороны, стрелки, порожденные в разных работах, могут представлять собой одинаковые или однородные данные или объекты, которые в дальнейшем используются или перерабатываются в одном месте. Для моделирования таких ситуаций в IDEF0 используются разветвляющиеся и сливающиеся стрелки. Для разветвления стрелки нужно в режиме редактирования стрелки щелкнуть по фрагменту стрелки и по соответствующему сегменту работы. Для слияния двух стрелок выхода нужно в режиме редактирования стрелки сначала щелкнуть по сегменту выхода работы, а затем по соответствующему фрагменту стрелки.
Смысл разветвляющихся и сливающихся стрелок передается именованием каждой ветви стрелок. Существуют определенные правила именования таких стрелок. Рассмотрим их на примере разветвляющихся стрелок. Если стрелка именована до разветвления, а после разветвления ни одна из ветвей не именована, то подразумевается, что каждая ветвь моделирует те же данные или объекты, что и ветвь до разветвления.
Если стрелка именована до разветвления, а после разветвления какая-либо из ветвей тоже именована, то подразумевается, что эти ветви соответствуют именованию. Если при этом какая-либо ветвь после разветвления осталась неименованной, то подразумевается, что она моделирует те же данные или объекты, что и ветвь до разветвления.
Все работы модели нумеруются. Номер состоит из префикса и числа. Может быть использован префикс любой длины, но обычно используют префикс А. Контекстная (корневая) работа дерева имеет номер А0. Работы декомпозиции А0 имеют номера А1, А2, A3 и т.д. Работы декомпозиции нижнего уровня имеют номер родительской работы и очередной порядковый номер, например работы декомпозиции A3 будут иметь номера А31, А32, АЗЗ, А34 и т.д. Работы образуют иерархию, где каждая работа может иметь одну родительскую и несколько дочерних работ, образуя дерево. Такое дерево называют деревом узлов, а вышеописанную нумерацию -- нумерацией по узлам. Диаграммы IDEF0 имеют двойную нумерацию. Во-первых, диаграммы имеют номера по узлу. Контекстная диаграмма всегда имеет номер А-0, декомпозиция контекстной диаграммы -- номер А0, остальные диаграммы декомпозиции -- номера по соответствующему узлу (например, A1, A2, А21, А213 и т. д.). BPwin автоматически поддерживает нумерацию по узлам, т.е. при проведении декомпозиции создается новая диаграмма и ей автоматически присваивается соответствующий номер. В результате проведения экспертизы диаграммы могут уточняться и изменяться, следовательно, могут быть созданы различные версии одной и той же (с точки зрения ее расположения в дереве узлов) диаграммы декомпозиции. BPwin позволяет иметь в модели только одну диаграмму декомпозиции в данном узле.
4. Проектирование информационного обеспечения системы
4.1 Информационный анализ предметной области и выделение информационных объектов
При проектировании информационного обеспечения системы изучается предметная область, производится анализ данных, устанавливаются основные объекты предметной области [2].
Первым шагом при проектировании информационного обеспечения является выделение состава документов и их реквизитов на основе анализа предметной области. Так же на данном шаге производится анализ состава форм документов предметной области. На основании анализа предметной области можно выделить следующие входные документы: список специальностей, список групп, список студентов, список дисциплин, журналы с успеваемостью и посещаемостью студентов.
Формы данных документов предметной области рассмотрены в приложениях (см. приложения А, Б, В).
Следующим шагом при построении информационно-логической модели является установление функциональных зависимостей между реквизитами на основе анализа предметной области и анализе документов предметной области.
На данном шаге определяется зависимость одного реквизита от другого, и если такая зависимость есть, то между данными реквизитами строится связь.
Информацию, полученную в ходе выполнения данного шага, представим в виде следующей таблицы (см. приложение Г).
Далее необходимо разделить все реквизиты на описательные и ключевые и как ключевое требование с точки зрения экономии вложений, гарантирующее, что не придется перестраивать систему по мере роста объема обрабатываемой информации и увеличивать функциональные зависимости реквизитов.
Для анализа реквизитов составим таблицу (табл. 4.1.1).
Таблица 4.1.1
Определение типов реквизитов
Документ |
Описательный реквизит |
Ключевой реквизит |
Вид ключа |
Имя информационного объекта |
|
Список студентов |
name_student n_group password |
n_zbook |
П, У |
Студенты |
|
Список преподавателей |
name_teacher login password |
n_teacher |
П, У |
Преподаватели |
|
Список специальностей |
name_speciality term_study abbreviation |
n_speciality |
П, У |
Специальности |
|
Список групп |
n_spciality name_group n_teacher |
n_group |
П, У |
Группы |
|
Список дисциплин |
n_group name_discipline n_teacher sem_start sem_end |
n_discipline |
П, У |
Дисциплины |
|
Рубежная успеваемость |
mark |
n_zbook n_discipline mon |
С, У |
Успеваемость |
|
Семестровая успеваемость |
mark |
n_zbook n_discipline n_sem |
С, У |
Успеваемость |
|
Рубежная посещаемость |
no_reazon total |
n_zbook mon |
С, У |
Посещаемость |
|
Семестровая посещаемость |
no_reazon total |
n_zbook n_sem |
С, У |
Посещаемость |
Следующим шагом при построении информационно-логической модели является описание информационных объектов, т.е. выполняется структурирование описательных реквизитов, которые одинаково зависимы от одного или нескольких ключевых реквизитов. В каждую группу включим общие для этой группы ключевые реквизиты. Каждая такая группа и будет называться информационным объектов.
Для анализа реквизитов составим таблицу (табл. 4.1.2).
Таблица 4.1.2
Описание информационных объектов
Реквизиты ИО |
Признак ключа |
Имя ИО |
Семантика |
|
n_zbook name_student n_group password |
П, У |
Студенты |
Сведения о студентах |
|
n_teacher name_teacher login password |
П, У |
Преподаватели |
Сведения о преподавателях |
|
n_speciality name_speciality term_study abbreviation |
П, У |
Специальности |
Сведения о специальностях |
|
n_group n_spciality name_group n_teacher |
П, У |
Группы |
Сведения о группах |
|
n_discipline n_group name_discipline n_teacher sem_start sem_end |
П, У |
Дисциплины |
Сведения о дисциплинах |
|
n_zbook, n_discipline, mon, mark |
С, У |
Успеваемость |
Сведения о рубежной успеваемости студентов |
|
n_zbook, n_discipline, n_sem mark |
С, У |
Успеваемость |
Сведения о семестровой успеваемости студентов |
|
n_zbook, mon no_reazon, total |
С, У |
Посещаемость |
Сведения о рубежной посещаемости студентов |
|
n_zbook, n_sem no_reazon, total |
С, У |
Посещаемость |
Сведения о семестровой посещаемости студентов |
Информационные объекты должны отвечать всем требованиям нормализации:
— Информационный объект должен содержать уникальный идентификатор;
— Все остальные описательные реквизиты должны быть взаимно независимы;
— Все реквизиты, входящие в составной ключ должны быть взаимно независимы;
— Каждый описательный реквизит должен функционально-полно зависеть от ключа информационного объекта;
— При составном ключе описательные реквизиты должны полностью зависеть от реквизитов составляющих ключ;
— Каждый описательный реквизит не может зависеть от ключа транзитивно.
Согласно требованиям нормализации между информационными объектами допускаются связи 1:1 и 1:М. Определим тип связи между информационными объектами (табл. 4.1.3).
Таблица 4.1.3
Определение типов связей
Номер связи отношения |
Главный ИО |
Подчиненный ИО |
Тип отношения |
|
1 |
Специальности |
Группы |
1:М |
|
2 |
Группы |
Студенты |
1:М |
|
3 |
Преподаватели |
Группы |
1:1 |
|
4 |
Преподаватели |
Дисциплины |
1:М |
При составлении информационно-логической модели информационные объекты должны быть упорядочены по уровням (рис. 4.1.1).
Представленная информационно-логическая модель рассматриваемой предметной области, построена в соответствии с выявленными информационными объектами и связями между ними.
Размещено на http://www.allbest.ru/
Размещено на http://www.allbest.ru/
Рис. 4.1.1 -- Уровни информационных объектов
Информационно-логическая модель приведена в каноническом виде, и объекты в ней размещены по уровням. На нулевом уровне размещаются объекты, не подчиненные никаким другим объектам. Уровень остальных объектов определяется наиболее длинным путем к объекту от нулевого уровня.
Такое размещение объектов дает представление об их иерархической подчиненности, делает модель более наглядной и облегчает понимание одно-многозначных отношений между объектами.
4.2 Построение логической модели данных
Информационно-логическая модель отображает данные предметной области в виде совокупности информационных объектов и связей между ними. Эта модель представляет данные, подлежащие хранению в базе данных.
Создание реляционной базы [6] данных с помощью. ERwin начинается с введения в диаграмму сущностей, определенных на логической схеме. Определив сущности, необходимо ввести в схему и атрибуты этих сущностей. Каждый из атрибутов связывают с определенным типом данных. Задав атрибуты сущностей, мы определяем таблицы базы данных, соответствующие сущностям предметной области. На последнем этапе определяем связи между введенными таблицами.
После того как определены все сущности, необходимо задать связи между ними. Связь в ERwin трактуется как функциональная зависимость между двумя сущностями. Если рассматривать диаграмму как графическое изображение предметной области, то сущности являются существительными, а связи -- глаголами.
Рис. 4.2.1 -- Информационно-логическая модель «Электронный журнал успеваемости»
Связи между объектами модели данных реализуются одинаковыми реквизитами -- ключами связи в соответствующих таблицах. При этом ключом связи типа 1:М всегда является уникальный ключ главной таблицы. Ключом связи в подчиненной таблице является либо некоторая часть уникального ключа в ней, либо поле, не входящее в состав первичного ключа. Ключ связи в подчиненной таблице называется внешним ключом.
Все связи в полученной информационно-логической модели предметной области «Электронный журнал» характеризуются отношением типа 1:М.
На основе анализа предметной области может быть построена следующая информационно-логическая модель, приведенная на рис. 4.2.1.
5. Проектирование реляционной базы данных
5.1 Описание реляционной модели
В основе реляционных систем лежит реляционная модель данных. Принципы реляционной модели были заложены в 1969-1970 гг. американским ученым Е.Ф. Коддом (E.F. Codd), в то время работавшим в корпорации IBM. Будучи математиком по образованию, он привнес в область управления базами данных строгие математические принципы и точность, которых не хватало ранним системам. Хотя реляционный подход утвердился не сразу, можно отметить, что почти все созданные с конца 70-х гг. продукты баз данных основаны именно на реляционном подходе. Подавляющее большинство научных исследований в области баз данных в течение последних 35 лет также проводилось именно в этом направлении.
Рассматривая и постепенно уточняя основные понятия реляционной модели, будем иметь в виду три компоненты модели данных:
· структуры данных,
· операции, которые можно выполнять над данными, и
· ограничения, связанные с обеспечением целостности данных.
Основной структурой данных в реляционной модели являются таблицы, называемые в реляционной теории отношениями. Собственно от термина отношение (по-английски relation) и произошло само название модели - реляционная.
5.2 Описание таблиц базы данных
Логическая структура реляционной базы данных является адекватным отображением полученной информационно-логической модели предметной области. Для канонической модели не требуется дополнительных преобразований. Каждый информационный объект модели данных отображается соответствующей реляционной таблицей. Структура реляционной таблицы определяется реквизитным составом соответствующего информационного; объекта, где каждый столбец (поле) соответствует одному из реквизитов объекта. Ключевые реквизиты объекта образуют уникальный ключ реляционной таблицы. Для каждого столбца таблицы (поля) задается тип, размер данных и другие свойства. Строки (записи) таблицы соответствуют экземплярам объекта и формируются при загрузке таблицы.
В приведенных формах документов с нормативно-справочной и оперативной информацией представлены реквизиты, значения которых должны храниться в базе данных информационной системы. Эти значения вводятся с клавиатуры компьютера или выбираются из списков в экранных формах. Ниже приведены характеристики реквизитов документов предметной области. Проектировщик при необходимости может их изменить, а также добавить другие реквизиты.
Таблица 5.2.1
Таблица «Список студентов»
Атрибут |
Признак ключа |
Формат поля |
|||
Имя |
Название |
Тип |
Длина |
||
Id |
Автоматическое поле |
Первичный (Primary) |
Числовой (Long Integer) |
8 |
|
name_student |
ФИО студент |
Текстовый (Text) |
250 |
||
n_group |
Номер группы |
Числовой (Long Integer) |
8 |
||
password |
Пароль |
Текстовый (Text) |
32 |
Таблица 5.2.2
Таблица «Список преподавателей»
Атрибут |
Признак ключа |
Формат поля |
|||
Имя |
Название |
Тип |
Длина |
||
n_teacher |
Номер преподавателя |
Первичный (Primary) |
Числовой (Long Integer) |
8 |
|
name_teacher |
ФИО преподавателя |
Текстовый (Text) |
250 |
||
login |
Имя пользователя |
Текстовый (Text) |
10 |
||
password |
Пароль |
Текстовый (Text) |
32 |
Таблица 5.2.3
Таблица «Список специальностей»
Атрибут |
Признак ключа |
Формат поля |
|||
Имя |
Название |
Тип |
Длина |
||
n_speciality |
Номер специальности |
Первичный (Primary) |
Числовой (Long Integer) |
8 |
|
name_speciality |
Название специальности |
Текстовый (Text) |
250 |
||
term_study |
Время обучения |
Числовой (Long Integer) |
8 |
||
abbreviation |
Аббревиатура |
Числовой (Long Integer) |
10 |
Таблица 5.2.4
Таблица «Список групп»
Атрибут |
Признак ключа |
Формат поля |
|||
Имя |
Название |
Тип |
Длина |
||
n_group |
Номер группы |
Первичный (Primary) |
Числовой (Long Integer) |
8 |
|
n_spciality |
Номер специальности |
Числовой (Long Integer) |
8 |
||
name_group |
Название группы |
Текстовый (Text) |
250 |
||
n_teacher |
Классный руководитель |
Числовой (Long Integer) |
8 |
Таблица 5.2.5
Таблица «Список дисциплин»
Атрибут |
Признак ключа |
Формат поля |
|||
Имя |
Название |
Тип |
Длина |
||
n_discipline |
Номер дисциплины |
Первичный (Primary) |
Числовой (Long Integer) |
8 |
|
n_group |
Номер группы |
Числовой (Long Integer) |
8 |
||
name_discipline |
Название дисциплины |
Текстовый (Text) |
250 |
||
n_teacher |
Номер преподавателя |
Числовой (Long Integer) |
8 |
||
sem_start |
Семестр начала обуч. |
Числовой (Long Integer) |
2 |
||
sem_end |
Семестр конца обуч. |
Числовой (Long Integer) |
2 |
Таблица 5.2.6
Таблица «Рубежная успеваемость»
Атрибут |
Признак ключа |
Формат поля |
|||
Имя |
Название |
Тип |
Длина |
||
n_zbook |
Номер зачетной книжки |
Числовой (Long Integer) |
8 |
||
n_discipline |
Номер дисциплины |
Числовой (Long Integer) |
8 |
||
mon |
Месяц |
Числовой (Long Integer) |
2 |
||
mark |
Оценка |
Числовой (Long Integer) |
1 |
Таблица 5.2.7
Таблица «Семестровая успеваемость»
Атрибут |
Признак ключа |
Формат поля |
|||
Имя |
Название |
Тип |
Длина |
||
n_zbook |
Номер зачетной книжки |
Числовой (Long Integer) |
8 |
||
n_discipline |
Номер дисциплины |
Числовой (Long Integer) |
8 |
||
n_sem |
Семестр |
Числовой (Long Integer) |
2 |
||
mark |
Оценка |
Числовой (Long Integer) |
1 |
Таблица 5.2.8
Таблица «Рубежная посещаемость»
Атрибут |
Признак ключа |
Формат поля |
|||
Имя |
Название |
Тип |
Длина |
||
n_zbook |
Номер зачетной книжки |
Числовой (Long Integer) |
8 |
||
mon |
Месяц |
Числовой (Long Integer) |
2 |
||
no_reazon |
Без ув. причины |
Числовой (Long Integer) |
5 |
||
total |
Всего |
Числовой (Long Integer) |
5 |
Таблица 5.2.9
Таблица «Семестровая посещаемость»
Атрибут |
Признак ключа |
Формат поля |
|||
Имя |
Название |
Тип |
Длина |
||
n_zbook |
Номер зачетной книжки |
Числовой (Long Integer) |
8 |
||
n_sem |
Семестр |
Числовой (Long Integer) |
2 |
||
no_reazon |
Без ув. причины |
Числовой (Long Integer) |
5 |
||
total |
Всего |
Числовой (Long Integer) |
5 |
5.3 Выбор СУБД
Для принятия решения о выборе СУБД можно проанализировать наиболее популярные: Postgre, MySQL и MSSQL Server. Эти системы будут анализироваться по ряду признаков. На основе анализа результатов будет решен вопрос о приоритетности каждой конкретной СУБД для выбранной предметной области.
Перечень требований к СУБД, используемых при анализе той или иной информационной системы, может изменяться в зависимости от поставленных целей.
Для высоко нагруженных систем используется клиент-серверная архитектура, это значит, что для баз данных использует отдельно выделенный сервер.
Многие производители СУБД выпускают средства разработки приложений для своих систем, которые позволяют более тонко настроить сам сервер. Исходя из этого стоит выбирать СУБД, которая может настаиваться без специального ПО.
В MySQL в отличии от Microsoft SQL Server и Postgre нет триггеров и процедур, это считается недочетом. Из-за этого приходится организовывать все задачи в приложении, не использовать стандартные средства, тем самым усложняется создание приложения.
В таблице 5.3.1 приведен список операционных систем, под управлением которых способна работать система управления базами данных.
В таблице 5.3.2 приведены достоинства и недостатки СУБД
Таблица 5.3.1
Поддерживаемые операционные системы
СУБД |
Операционные системы |
|
Postgre |
Windows, Linux, Unix |
|
MS SQL Server |
Windows |
|
MySQL |
Linux, Unix, Windows |
Таблица 5.3.2
Достоинства и недостатки СУБД
СУБД |
Плюсы |
Минусы |
|
Postgre |
Высоко функциональная и бесплатная СУБД с открытым кодом, хорошая поддержка со стороны сообщества разработчиков |
Местами низкая производительность при обработки больших объёмов информации, малая популярность продукта |
|
MS SQL |
Высоко функциональная, удобна при использовании среды Windows |
Платная, сложна в администрировании, не кроссплатформенная |
|
MySQL |
Бесплатная СУБД, имеет открытый код, занимает мало места, лёгкое администрирование mysql с набором всего необходимого функционала, большое сообщество разработчиков, работает на множестве платформ |
незащищённость от потери данных, поддержка только малых баз данных |
Итак, рассмотренные СУБД имеют свои достоинства и недостатки, сопоставив их, было принято решение в пользу выбора MySQL.
база данный учебный электронный журнал
6. Разработка клиент-серверного приложения для работы с базой данных
6.1 Технология «клиент-сервер»
По мере развития представлений о распределенных вычислительных процессах и процессах обработки данных сформировалась теория архитектуры «клиент-сервер» - обобщенное понятие о взаимодействии 2-ух составляющих информационной технологии в вычислительных системах и сетях, посреди которых логически либо физически могут быть выделены: функциональная сторона (родник запросов, заказчик); пассивная сторона (сервер, сервис запросов, родник ответов):
— активная сторона;
— пассивная сторона.
Взаимодействие «клиент -- сервер» в сети осуществляется в соответствии с определенным протоколом.
В концепции «клиент-сервер» подразумевается, что помимо хранения централизованной базы данных центральная машина (сервер базы данных) должна обеспечивать выполнение основного объема обработки данных. Запрос на данные, выдаваемый клиентом, порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту. Спецификой архитектуры клиент-сервер является использование языка запросов SQL (Structured Query Language) [6].
Запрос к базе данных инициируется клиентом, однако выполняется на сервере. Клиенту возвращается по сети только результат. Этот процесс состоит из шести этапов:
1. Клиент запрашивает данные.
2. Запрос транслируется в SQL.
3. SQL-запрос передается по сети на сервер.
4. Сервер базы данных осуществляет поиск.
5. Требуемые записи возвращаются клиенту.
6. Данные предъявляются пользователю.
Технология «клиент-сервер» создает мощную среду, которая дает организациям множество реальных преимуществ. В частности, хорошо спланированная клиент-серверная система обеспечивает относительно недорогую платформу, которая обладает, в то же время, вычислительными возможностями мейнфреймов и легко настраивается для выполнения конкретных задач. Кроме того, при клиент-серверной обработке резко уменьшается сетевой трафик, так как через сеть посылаются только результаты запросов.
Груз файловых операций ложится в основном на компьютер-сервер, который намного мощнее клиентов и способен поэтому лучше обслуживать запросы.
Сеть модели «клиент-сервер» уменьшает потребность компьютеров-клиентов в оперативной памяти, поскольку вся работа с файлами выполняется на сервере. Серверы в клиент-серверных системах способны хранить большое количество данных. Благодаря этому на компьютерах-клиентах освобождается значительный объем дискового пространства.
Также в значительной степени упрощается резервное копирование данных.
Наконец, управление всей системой, включая контроль за ее безопасностью, становится намного проще, так как все файлы и данные централизованно размещаются на сервере или на небольшом числе серверов.
6.2 Средства программирования разрабатываемого приложения
Для создания приложения основным средством разработки являлся язык программирования python 2.5 [1], [9].
Высокоуровневый язык программирования общего назначения, ориентированный на повышение производительности разработчика и читаемости кода. Синтаксис ядра Python минималистичен. В то же время стандартная библиотека включает большой объём полезных функций.
Python поддерживает несколько парадигм программирования, в том числе структурное, объектно-ориентированное, функциональное, императивное и аспектно-ориентированное. Основные архитектурные черты -- динамическая типизация, автоматическое управление памятью, полная интроспекция, механизм обработки исключений, поддержка многопоточных вычислений и удобные высокоуровневые структуры данных. Код в Python организовывается в функции и классы, которые могут объединяться в модули (они в свою очередь могут быть объединены в пакеты).
Язык и его интерпретатор разрабатываются группой энтузиастов в рамках проекта с открытым кодом. Проект не является свободным и распространяется под собственной лицензией.
В области программирования для Сети python -- один из популярнейших скриптовых языков (наряду с JSP, Perl и языками, используемыми в ASP.NET) благодаря своей простоте, скорости выполнения, богатой функциональности, кроссплатформенности и распространению исходных кодов.
Популярность в области построения web-сайтов определяется наличием большого набора встроенных средств для разработки web-приложений. Основные из них:
— Автоматическое извлечение POST и GET-параметров, а также переменных окружения web-сервера в предопределенные массивы;
— Файловые функции успешно обрабатывают как локальные, так и удаленные файлы;
— Автоматическая отправка HTTP-заголовков;
— Работа с cookies и сессиями;
— Обработка файлов, загружаемых на сервер;
— Работа с HTTP заголовками и HTTP авторизацией;
— Работа с XForms;
— Работа с удаленными файлами и сокетами.
В настоящее время python используется разработчиками для высоконагруженных проектов. Согласно рейтингу Tiobe, базирующемся на данных поисковых систем, в декабре 2009 года python находится на 3 месте среди языков программирования (уступая Java и C), поднявшись за год на две позиции.
В настоящий момент существует единственная реализация python, ни одна сторонняя компания не поддерживает исполняемых модулей, отличных от официальной сборки. Такое положение вещей, с одной стороны, позволяет быстро внедрять и распространять нововведения среди сообщества разработчиков, с другой стороны, разрабатывать язык программирования в условиях отсутствия стандарта, так как единая реализация обеспечивает его по факту. В таких условиях большое значение приобретает версия интерпретатора, определяющая текущую функциональность (обратная совместимость между версиями интерпретатора не соблюдается строго).
В 1994 году датский программист Расмус Лердорф создал набор скриптов на Perl/CGI для вывода и учёта посетителей его онлайн-резюме, обрабатывающий шаблоны HTML-документов. Лердорф назвал набор Personal Home Page (Личная Домашняя Страница). Вскоре функциональности и быстроты Perl -- интерпретатора скриптов -- перестало хватать, и Лердорф разработал с использованием языка C новый интерпретатор шаблонов PHP/FI.
6.3 Программная реализация модуля «Преподаватель»
Для работы с автоматизированной информационной системой «Электронный журнал» необходимо ввести URL в адресную строку браузера. После загрузки данных в окне браузера появится страница с которой начинается работа в информационной системе -- это страница аутентификации пользователя в системе (рис. 6.3.1).
Рис. 6.3.1 -- Страница аутентификации пользователя
В центре экрана расположена форма аутентификации пользователя, но если пользователь еще не зарегистрирован в системе, то ниже приводится ссылка на страницу регистрации.
После успешной аутентификации преподаватель попадает на страницу выбора отображения нужного ему предмета, где он может выставлять оценки, отмечать посещаемость и редактировать тему урока и домашнее задание (рис. 6.3.2).
Рис. 6.3.2 -- Страница выбора отображения информации
На протяжении всей работы с системой отображается персональная информация о преподавателе: ФИО преподавателя, доступные предметы, также рядом с этой информации расположена гиперссылка для выхода пользователя из системы, на приложение технической поддержки или ссылку на нее, а так же смену пароля.
После нажатия на дату преподаватель может заполнить тему урока и домашнее задание (рис. 6.3.3).
Рис. 6.3.3 -- Страница текущей успеваемости студента
Для выставления отметок, необходимо просто выбрать ячейку и поставить туда отметку, либо «Н», если студент отсутствовал на уроке.
6.4 Программная реализация модуля «Руководитель группы»
Работа с системой для руководителя группы также начинается со страницы аутентификации (рис. 6.4.1).
Рис. 6.4.1 -- Страница аутентификации руководителя
После успешной аутентификации руководитель попадает на страницу выбора нужного действия: Добавление или исключение студентов, просматривать отметки и посещаемость своей группы, создавать отчеты по социальным группам, и группам здоровья и оценкам (рис. 6.4.2).
Рис. 6.4.2 -- Страница составления отчета успеваемости
После нажатия на гиперссылку из меню «Руководство» руководитель увидит страницу, на которой расположено меню для выбора действия, там он может выбрать добавлять связи или управлять студентами своей группы (рис. 6.4.3).
Рис. 6.4.3 -- Страница управления студентами
Руководитель может редактировать связи по всем дисциплинам выбранной группы только в том случае, если он является руководителем этой группы. Если он не является руководителем выбранной группы, то возможность редактирования связей будет только по тем дисциплинам, которые преподаются в этой группе.
После ввода изменений руководитель должен нажать кнопку «Сохранить» для того чтобы новые данные были записаны в базу данных или перейти на другую страницу чтобы отказаться от внесенных изменений.
На рис. 6.4.5 изображена страница редактирования связей.
Рис. 6.4.5 -- Страница редактирования связей
6.5 Программная реализация модуля «Администратор заведения»
Работа с системой начинается аналогично предыдущим модулям. После успешной авторизации администратор заведения увидит страницу, на которой расположено меню для выбора действия: управление предметами, управление группами, управление преподавателями, работа с расписанием, назначение итоговых периодов, назначение преподавателям предметов, назначение руководителя группы.
Рис. 6.5.1 -- Страница управления заведением
После выбора нужного пункта меню откроется соответствующая страница.
На рисунке 6.5.2 изображено управление группами учебного заведения
Разработка автоматизированной информационной системы Электронный журнал
Рис. 6.5.2 -- Страница управления группами
Управление преподавателями изображено на рисунке 6.5.3. Так же можно добавить рол преподавателя к ранее созданному аккаунту или импортировать из .csv файла, параметры импорта будут указаны при переходе на соответствующую страницу.
Рис. 6.5.3 -- Страница управления преподавателями
Аналогично предыдущему пункту осуществляется управление предметами учебного заведения. (Рис. 6.5.4)
Рис. 6.5.4 -- Страница управления преподавателями
Отличительной чертой данного модуля является работа с расписанием. Для этого нужно выбрать в пункте меню «Расписание», откроется страница управления расписанием, после чего выбрать группу и расставить предметы в соответствии с планом занятий, так же отметить кабинеты, в которых они будут проходить. (Рис. 6.5.5)
Рис. 6.5.5 -- Страница управления расписанием
6.6 Программная реализация модуля «Родитель»
Работа с системой начинается аналогично предыдущим модулям. После успешной авторизации родитель увидит страницу, на которой расположено меню для выбора действия: просмотр расписания, предметы по семестрам, контроль посещаемости и успеваемости, прикрепление ребенка, просмотр информации о группе, просмотр преподавателей относящихся к данной группе.
Подобные документы
Основные подходы к решению проблем управления электронным документооборотом. Разработка информационной системы для работы с базой данных (БД). Проектирование логической структуры БД, программная реализация. Тестирование и отладка программного средства.
курсовая работа [1,3 M], добавлен 06.01.2013Общие сведения о проектировании базы данных и разборка приложений для взаимодействия с БД. Разработка проекта клиентского приложения "Электронный классный журнал" с помощью языка программирования Delphi 7. Просмотр и изменение информации базы данных.
курсовая работа [403,6 K], добавлен 24.06.2011Понятие автоматизированной информационной системы. Построение функционально-ориентированных моделей "как есть" (as-is) и "как должно быть" (to-be). Описание базы данных, разработка приложения, руководство пользователя. Счет-фактура, платежное поручение.
дипломная работа [3,5 M], добавлен 23.04.2013Анализ входной информации и процессов, уровня автоматизации на предприятии. Выявление объекта и задачи автоматизации. Разработка концепции построения информационной модели информационной системы. Разработка структуры базы данных и клиентского приложения.
дипломная работа [2,0 M], добавлен 22.11.2015Разработка информационной системы для отдела учета приема пациентов и медицинского секретариата. Описание исходной (входной) информации и пользовательского интерфейса, логической структуры и технических средств. Построение реляционной базы данных.
дипломная работа [1,9 M], добавлен 16.04.2012Проектирование физической и логической моделей удаленной базы данных для АЗС. Разработка базы данных в СУБД Firebird с помощью утилиты IBExpert. Создание клиентского приложения для Windows с использованием клиент-серверной технологии в среде C++ Builder.
курсовая работа [3,9 M], добавлен 18.01.2017Разработка клиент-серверного приложения, позволяющего взаимодействовать друг с другом с использованием доступа к базам данных. Проектирование связи сервера с базой данных с помощью технологии ODBC. Разработка интерфейса программы, ее тестирование.
курсовая работа [352,0 K], добавлен 24.08.2016Угрозы безопасности баз данных. Политика информационной безопасности предприятия в области использования сетевых ресурсов. Разработка и введение в эксплуатацию защищенного клиент-серверного приложения. Средства аутентификации объектов базы данных.
дипломная работа [4,6 M], добавлен 21.02.2013Разработка информационной системы на платформе "1С:Предприятие 8.0" для автоматизации документооборота и учета по приему аварийных автомобилей и составлению заказ-нарядов. Проектирование интерфейса. Построение логической и физической моделей данных.
дипломная работа [640,5 K], добавлен 14.02.2015Выявление сущностей и связей, атрибутов сущностей и назначение первичных ключей при разработке базы данных. Реляционная модель данных. Описание стадий жизненного цикла информационной системы: анализ, проектирование, реализация, внедрение, сопровождение.
курсовая работа [152,2 K], добавлен 11.05.2014