Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Разработка автоматизированной системы учета успеваемости студентов

Разработка автоматизированной системы учета успеваемости студентов

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 24.03.2014
Размер файла 1,0 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Страница:

100

Размещено на http://www.allbest.ru/

РАЗРАБОТКА АВТОМАТИЗИРОВАННОЙ СИСТЕМЫ УЧЕТА УСПЕВАЕМОСТИ СТУДЕНТОВ

Пояснительная записка к курсовому проекту по дисциплине

"Проектирование информационных систем"

2012

Содержание

  • Введение
  • 1. Анализ предметной области
  • 2. Техническое задание
  • 2.1 Основание для разработки
  • 2.2 Назначение разработки
  • 2.3 Требования к программе
  • 2.3.1 Требования к функциональным характеристикам
  • 2.3.2 Требования к надежности
  • 2.3.3 Требования к составу и параметрам технических средств
  • 2.3.4 Требования к информационной и программной совместимости
  • 2.4 Требования к программной документации
  • 2.5 Стадии и этапы разработки
  • 2.6 Порядок контроля и приемки
  • 3. Функциональное проектирование модели автоматизированной системы учета успеваемости студентов
  • 3.1 Описание CASE-средства AllFusion Erwin Process Modeler 7.3
  • 3.2 Описание функциональной модели системы
  • 4. Проектирование модели базы данных автоматизированной системы учета успеваемости студентов
  • 4.1 Описание CASE-средства AllFusion Erwin Data Modeler
  • 4.2 Логическое проектирование модели базы данных системы
  • 4.3 Разработка структуры связей
  • 4.4 Нормализация отношений
  • 4.5 Физическое проектирование базы данных
  • 5. Обоснование целесообразности использования заданных средств разработки
  • 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 Средства и порядок испытаний
  • 7.6 Методы испытаний
  • 8. Описание применения
  • 8.1 Назначение применения
  • 8.2 Условия применения
  • 8.3 Описание задачи
  • 8.4 Входные и выходные данные
  • Заключение
  • Список использованных источников
  • Приложение

Введение

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

Автоматизированные системы в настоящее время широко используются во всех звеньях жизнедеятельности человека. ГОСТ 24.003-84 следующим образом определяет АСУ: Автоматизированная система управления - система "человек - машина", обеспечивающая эффективное функционирование объекта, в которой сбор и переработка информации, необходимой для реализации функций управления, осуществляется с применением средств автоматизации и вычислительной техники.

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

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

1. Анализ предметной области

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

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

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

Различают следующие виды аттестации:

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

Текущая аттестация проводится по трем контрольным точкам в течение семестра. Отметка в контрольной точке аккумулирует в себе результат выполнения всех видов работ студентом за данный период в соответствии с учебно-методическим комплексом дисциплины. Данная система оценки знаний является базой для перехода вуза к зачету учебных единиц (кредитов) в соответствии с положениями Болонского соглашения в области образования.

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

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

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

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

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

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

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

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

2. Техническое задание

2.1 Основание для разработки

Разработка ведется на основании задания на выпускную квалификационную работу бакалавра. Задание выдано руководителем курсового проектирования, доцентом Бобрышевой Г.В.

2.2 Назначение разработки

Приложение предназначено для автоматизации учета успеваемости студентов

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

2.3.1 Требования к функциональным характеристикам

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

- учет сведений по студентам;

- учет сведений о преподавательском составе;

- учет сведений по кафедрам;

- учет сведений по дисциплинам;

- учет сведений по распределению учебной нагрузки;

- учет результатов аттестации студентов;

- формирование отчетной документации.

Входными данными программы должны быть:

- личные данные студентов;

- личные данные преподавателей;

- информация по кафедрам;

- информация по дисциплинам;

- информация по специальностям;

- информация по группам;

- информация по формам обучения;

- учебный план;

- экзаменационная ведомость;

- информация по формам обучения.

Выходными данными системы должны быть:

- отчет по текущей аттестации;

- отчет по промежуточной аттестации;

- отчет по итоговой аттестации.

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

2.3.2 Требования к надежности

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

2.3.3 Требования к составу и параметрам технических средств

Приложение должно быть предназначена для работы на IBM-совместимых персональных компьютерах, имеющих следующие минимальные технические характеристики:

- тактовая частота процессора - 1ГГц;

- оперативная память - 1024Мбайта;

- при установке приложения на жестком диске должно быть не менее 300Мбайт;

- при установке базы данных на жестком диске должно быть не менее 50Мбайт;

2.3.4 Требования к информационной и программной совместимости

Программа должна быть написана в среде программирования Borland Developer Studio 2006, а база данных реализована средствами утилиты IBExpert 2010.03.23, СУБД Firebird 2.5.

Программа должна работать в операционных системах Windows XP/7 и выше.

2.4 Требования к программной документации

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

- описание программы;

- программу и методику испытаний;

- описание применения.

Программная документация по своему содержанию должна соответствовать требованиям стандартов ЕСПД.

2.5 Стадии и этапы разработки

Разработка автоматизированной информационной системы должна соответствовать стадиям и этапам разработки, согласно стандарту ГОСТ34.601-90:

а) анализ предметной области

б) техническое задание

в) функциональное проектирование модели системы

г) проектирование модели базы данных системы

д) обоснование целесообразности использования средств разработки

е) описание программы

ж) программа и методика испытаний

з) описание применения

2.6 Порядок контроля и приемки

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

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

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

3.1 Описание CASE-средства AllFusion Erwin Process Modeler 7.3

AllFusion Erwin Process Modeler 7.3 - это средство, позволяющее создавать и разрабатывать функциональную модель.

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

В AllFusion Erwin Process Modeler 7.3 возможно построение смешанных моделей, т. с. модель может содержать одновременно как диаграммы IDEF0 (функциональная модель), так и DFD (DataFlow Diagram), и IDEF3 (WorkFlow Diagram) /1/.

В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы. Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель /1/.

Основу методологии DFD (Data Flow Diagramming) составляет графический язык описания бизнес-процессов. Диаграмма DFD используется для описания документооборота и обработки информации. Данная диаграмма представляет моделируемую систему как совокупность связанных между собой работ для более наглядного отображения текущих операций документооборота. DFD включает в себя:

- логические функции (активности);

- потоки данных;

- внешние ссылки (внешние источники и адресаты данных, которых находятся за границами моделируемой системы);

- хранилища данных - место, где объекты ожидают обработки.

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

Как и в методе IDEF0, основной единицей модели IDEF3 является диафамма. Другой важный компонент модели - действие, или в терминах IDEF3 "единица работы" (Unit of Work - UOW).

Диаграммы IDEF3 отображают действие в виде прямоугольника. Действия именуются с использованием глаголов или отглагольных существительных, каждому из действий присваивается уникальный идентификационный номер. Этот номер не используется вновь даже в том случае, если в процессе построения модели действие удаляется /1/.

Для разработки функциональной модели использовалось CASE-средство AllFusion Erwin Process Modeler 7.3.

3.2 Описание функциональной модели системы

Диаграмма верхнего уровня системы учета успеваемости студентов разработана на основе методологии IDEF0. В качестве компоненты модели процесса выступает "Учет успеваемости студентов". Контекстная диаграмма модели системы представлена на рисунке А.1.

Входными данными для системы являются:

а) сведения по кафедре;

б) учебный план;

в) сведения по специальности;

г) сведения по студенту;

д) сведения по дисциплине;

е) сведения по группе;

ж) сведения по преподавателю;

з) сведения по форме обучения;

Выходными данными для системы являются:

а) отчет по текущей аттестации

б) отчет по промежуточной аттестации

в) отчет по итоговой аттестации

Учет успеваемости студентов ведется в соответствии с уставом университета (стрелка управления) сотрудник деканата (механизм).

Функциональная декомпозиция процесса "Учет успеваемости студентов " проведена на основе результатов анализа предметной области с помощью методологии DFD (рисунок А.2). В результате декомпозиции выделено 7 бизнес-процессов (работ):

а) учет сведений по форме обучения;

в) учет сведений по специальности;

г) формирование студенческих групп;

д) учет сведений по распределению учебной нагрузки;

е) учет сведений по дисциплине;

ж) учет сведений по кафедре;

з) учет сведений по успеваемости;

Для хранения данных определены следующие хранилища:

а) форма обучения;

б) учебный план.

в) специальность;

г) группа;

д) студент;

е) дисциплина;

ж) кафедра;

з) преподаватель;

и) ведомость;

Процесс "Учет сведений по форме обучения" предназначен для учета сведений по форме обучения.

Входными данными процесса "Учет сведений по форме обучения" являются: информация о форме обучения.

Выходными данными процесса "Учет сведений по форме обучения" являются: сведения по формам обучения, которые поступают в хранилище "Форма обучения".

Процесс "Учет сведений по специальности" предназначен для учета сведений по специальности.

Входными данными процесса "Учет сведений по специальности" являются: - информация по специальности.

Выходными данными процесса "Учет сведений по специальности" являются: сведения по специальности, которые поступают в хранилище "Специальность".

Процесс "Формирование студенческих групп" предназначен для формирования студенческих групп.

Входными данными процесса "Формирование студенческих групп" являются:

информация по группе;

информация по студенту.

Выходными данными процесса "Формирование студенческих групп" являются:

сведения по группе, которые поступают в хранилище "Группа";

сведения по студентам, которые поступают в хранилище "Студент".

Процесс "Учет сведений по дисциплине" предназначен для учета сведений по дисциплине.

Входными данными процесса "Учет сведений по дисциплине" являются: информация по дисциплине.

Выходными данными процесса "Учет сведений по дисциплине" являются: сведения по дисциплине, которые поступают в хранилище "Дисциплина".

Процесс "Учет сведений по кафедре" предназначен для учета сведений по кафедре.

Входными данными процесса "Учет сведений по кафедре" являются: информация о кафедре.

Выходными данными процесса "Учет сведений о кафедре " являются: сведения по кафедре, которые поступают в хранилище "Кафедра".

Процесс "Учет сведений по распределению учебной нагрузки" предназначен для учета сведений по распределению учебной нагрузки.

Входными данными процесса "Учет сведений по распеределению учебной нагрузки" являются:

информация о преподавателе;

учебный план.

Выходными данными процесса "Учет сведений по распеределению учебной нагрузки" являются:

сведения по преподавателю, которые поступают в хранилище "Преподаватель";

сведения по учебному плану, которые поступают в хранилище "Учебный план";

Процесс "Учет сведений по успеваемости" предназначен для учета сведений по успеваемости.

Входными данными процесса "Учет сведений по успеваемости" являются: экзаменационная ведомость.

Выходными данными процесса "Учет сведений по успеваемости" являются: сведения по успеваемости, которые поступают в хранилище " экзаменационная ведомость".

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

4. Проектирование модели базы данных автоматизированной системы учета успеваемости студентов

4.1 Описание CASE-средства AllFusion Erwin Data Modeler

Семейство продуктов ERwin относится к мощным персональным CASE-продуктам, предназначенным для моделирования баз данных самого различного типа. Отличительной чертой продуктов ERwin является высокая степень обеспечения согласованного взаимодействия между средствами создания баз данных и средствами разработки приложений в технологии клиент-сервер/2/.

CASE-средство ERwin предназначено для разработчиков, проектировщиков БД, системных аналитиков для построения модели данных в процессе разработки технического проекта информационной системы. С помощью ERwin разработчик может, используя визуальные средства, описать логическую модель данных. На основе логической модели создается физическая модель для конкретной СУБД с использованием хранимых процедур и триггеров. Результатом работы по созданию физической модели может стать генерация структуры базы данных/2/.

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

Методологическую основу ERwin составляет технология IDEF1X (моделирование данных для реляционных СУБД). Результатом построения является ER-диаграмма ("сущность-связь"). Графический подход к созданию моделей значительно упрощает процесс разработки/2/.

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) - модель данных, позволяющая описывать концептуальные схемы. Предоставляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных /3/.

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

4.2 Логическое проектирование модели базы данных системы

Логическое проектирование базы данных системы проведено с помощью CASE-средства AllFusion ERwin Data Modeler 7.3.

На основе анализа предметной области выделено 10 сущностей:

сущность "Форма обучения" определяется следующими атрибутами: номер формы обучения, название;

сущность "Студент" определяется следующими атрибутами: номер зачетки, номер формы обучения, ФИО, номер группы, год поступления, адрес, телефон;

сущность "Семестр" определяется следующими атрибутами: номер семестра, название;

сущность "Кафедра" определяется следующими атрибутами: номер кафедры, название, телефон, ФИО заведущего кафедры;

сущность "Преподаватель" определяется следующими атрибутами: номер преподавателя, ФИО, номер кафедры;

сущность "Специальность" определяется следующими атрибутами: номер специальности, название;

сущность "Группа" определяется следующими атрибутами: номер группы, номер специальност, ФИО старосты, количество человек;

сущность "Дисциплина" определяется следующими атрибутами: номер дисциплины, название;

сущность "Ведомость" определяется следующими атрибутами: номер ведомости, номер зачетки, номер семестра, номер дисциплины, оценка, Вид аттестации;

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

Однозначно идентифицируем каждый экземпляр сущности - выделим первичные ключи.

Сущность "Форма обучения" - первичный ключ "Номер формы обучения".

Сущность "Ведомость" - составной первичный ключ:

"номер ведомости"

"номер дисциплины"

"номер зачетки"

Сущность "Группа" - первичный ключ "Номер группы".

Сущность "Специальность" - первичный ключ "Номер специальности".

Сущность "Учебный план" - составной первичный ключ:

"Номер учебного плана";

"Номер группы"

"Номер дисциплины"

Сущность "Дисциплина" - первичный ключ "Номер дисциплины".

Сущность "Семестр" - первичный ключ "Номер семестра".

Сущность "Преподаватель" - первичный ключ "Номер преподавателя".

Сущность "Кафедра" - первичный ключ "Номер кафедры".

Сущность "Студент" - первичный ключ "Номер зачетки".

4.3 Разработка структуры связей

Все сущности модели связаны через внешние ключи идентифицирующими и неидентифицирующими связями.

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

Сущности "Группа" и "Студент" связаны через внешний ключ по полю "Номер группы" неидентифицирующей связью "один-ко-многим". Т.к. в одной группе могу обучаться много несколько студентов, но один студент обучается толко в одной группе.

Сущности "Специальность" и "Группа" связаны через внешний ключ по полю "Номер специальности" неидентифицирующей связью "один-ко-многим". Т.к. на одной специальности могу обучаться несколько групп, но одна группа обучается только на одной специальности.

Сущности "Студент" и "Ведомость" связаны через внешний ключ по полю "Номер зачетки" идентифицирующей связью "один-ко-многим". Т.к. один студент сдает несколько предметов. но один предмет сдается только одним студентом.

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

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

Сущности "Семестр" и "Учебный план" связаны через внешний ключ по полю "Номер семестра" идентифицирующей связью "один-ко-многим". Т.к. в одном семестре могут преподаваться несколько дисциплин, но одна дисциплина в данном семестре преподается один преподавателем.

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

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

Сущности "Семестр" и Ведомость" связаны через внешний ключ по полю "Номер семестра" идентифицирующей связью "один-ко-многим". Т.к. в одном семестре могут сдают зачеты и экзамены мног студентов. но один студент в каждом семестре по одной дисциплине сдает зачет или экзамен один раз.

Сущности "Группа" и "Учебный план" связаны через внешний ключ по полю "Номергруппы" неидентифицирующей связью "один-ко-многим". Т.к. у одной группы могут преподаваться несколько предметов несколькими преподвателями, но один предмет преподается только одной группе.

Логическая структура базы данных (ER - диаграмма) представлена на рисунке Б.1.

4.4 Нормализация отношений

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

При работе с реляционными базами данных обязательным является удовлетворение только требованиям первой нормальной формы (1НФ). Все остальные формы нормализации могут использоваться по желанию проектировщиков. Однако, рекомендуется выполнять нормализацию как минимум до 3НФ, чтобы получить хорошее качество отношений (приемлемую избыточность отношений).

Атрибут, значения которого атомарны (неделимы) называется простым атрибутом. Сложный атрибут получается соединением нескольких атомарных атрибутов, которые могут быть определены на одном или разных доменах (его также называют вектор или агрегат данных) /4/.

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

Отношение, в котором каждый атрибут содержит атомарное (или единственное) значение, находится в 1НФ. При этом необходимо, чтобы отношение имело первичный ключ. Для преобразования ненормализованного отношения в первую нормальную форму следует устранить все повторяющиеся группы данных, используя декомпозицию этой таблицы /4/.

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

Неключевой атрибут функционально полно зависит от составного ключа если он функционально зависит от всего ключа в целом, но не находится в функциональной зависимости от какого-либо из входящих в него атрибутов /4/.

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

Нормализация 2НФ-отношения с образованием 3НФ-отношения осуществляется путем устранения транзитивных зависимостей - транзитивно-зависимые атрибуты удаляются из отношения и помещаются в новое отношение вместе с их детерминантом /4/.

Все атрибуты всех двенадцати сущностей в данной проектируемой системе атомарны и находятся в 1 НФ. Рассмотрим для подтверждения данного факта сущность "Кафедра". Атрибуты данной сущности "Название", "Телефон", "ФИО заведущего кафедры" являются простыми и неделимыми.

2НФ требует, чтобы неключевые атрибуты отношений зависели от первичного ключа в целом, но не от его части.2НФ применяется к отношениям с составными ключами, т.е. к таким отношениям, первичный ключ которых состоит из двух и более атрибутов.

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

Примером служит сущность "Группа". Неключевой атрибут "ФИО старосты" не зависит от неключевого атрибута "Количество человек" и "Номер специальности". Поэтому можно сделать вывод, что данное отношение находится во 3НФ.

4.5 Физическое проектирование базы данных

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

Физическая модель данных системы разработана на утилите "IBE-Expert" под СУБД "Firebird 2.5".

Описание таблиц физической модели системы приведено в таблицах 1-10.

Таблица 1 - Описание таблицы "Студент"

Поле

Тип данных

Номер зачетки

Varchar (10)

ФИО

Varchar (50)

Номер формы обучения

Integer

Номер группы

Varchar (10)

Год поступления

Integer

Адрес

Varchar (50)

Телефон

Integer

Таблица 2 - Описание таблицы "Форма обучения "

Поле

Тип данных

Номер формы обучения

Integer

Название

Varchar (10)

Таблица 3 - Описание таблицы "Группа"

Поле

Тип данных

Номер группы

Varchar (10)

Номер специальности

Integer

ФИО старосты

Varchar (50)

Количество человек

Integer

Таблица 4 - Описание таблицы "Ведомости"

Поле

Тип данных

Номер зачетки

Varchar (10)

Номер семестра

Integer

Номер дисциплины

Integer

Оценка

Varchar (10)

Вид аттестации

Varchar (40)

Таблица 5 - Описание таблицы "Специальность"

Поле

Тип данных

Номер специальности

Varchar (10)

Название

Varchar (50)

Таблица 6 - Описание таблицы "Дисциплина"

Поле

Тип данных

Номер дисциплины

Integer

Название

Varchar (50)

Таблица 7 - Описание таблицы "Семестр"

Поле

Тип данных

Номер семестра

Integer

Название

Varchar (10)

Таблица 8 - Описание таблицы "Учебный план"

Поле

Тип данных

Номер нагрузки

Integer

Номер семестра

Integer

Номер преподавателя

Integer

Номер дисциплины

Integer

Номер группы

Varchar (10)

Таблица 9 - Описание таблицы "Преподаватель"

Поле

Тип данных

Номер преподавателя

Integer

ФИО

Varchar (50)

Номер кафедры

Integer

Таблица 10 - Описание таблицы "Кафедра"

Поле

Тип данных

Номер кафедры

Integer

Название

Varchar (30)

Телефон

Integer

ФИО заведующего кафедрой

Varchar (50)

ER - диаграмма физической структуры базы данных представлена на рисунке Б.2.

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

Разработка системы осуществлена с использованием среды программирования Borland Developer Studio 2006. База данных реализована с помощью СУБД Firebird2.5.

Borland Developer Studio 2006 позволяет создавать приложения для Windows в пять раз быстрее, чем другие решения для разработки, или тратить на это в пять раз меньше ресурсов, не жертвуя производительностью и возможностями. Применение Borland Developer Studio 2006уменьшает затраты времени и ресурсов на создание приложений, поскольку все функции среды разработки Borland Developer Studio 2006 - от средств создания настольных приложений до средств работы с веб-приложениями и серверами - подчинены одной цели: ускорить создание программ. А среда быстрой разработки позволяет уменьшить объем кода, необходимого для решения задач, стоящих перед разработчиками. Таким образом, использование среды программирования Borland Developer Studio 2006 достаточно для проектирования автоматизированной системы /2/.

Преимущества Borland Developer Studio 2006 по сравнению с аналогичными программными продуктами:

- быстрота разработки приложения;

- высокая производительность разработанного приложения;

- низкие требования разработанного приложения к ресурсам компьютера;

- наращиваемость за счет встраивания новых компонент и инструментов в среду Borland Developer Studio 2006;

- возможность разработки новых компонент и инструментов собственными средствами Borland Developer Studio 2006 (существующие компоненты и инструменты доступны в исходниках);

- удачная проработка иерархии объектов;

- доступно огромное количество визуальных компонентов третьих фирм, часть из которых freeware, часть shareware, часть - коммерческие.

Таким образом, Borland Developer Studio 2006 идеально подходит в качестве среды разработки для автоматизации учета успеваемости студентов.

Firebird 2.5 (FirebirdSQL) - компактная, кроссплатформенная, свободная система управления базами данных (СУБД), работающая на GNU/Linux, Microsoft Windows и разнообразных Unix платформах.

В качестве преимуществ Firebird 2.5 можно отметить многоверсионную архитектуру, обеспечивающую параллельную обработку оперативных и аналитических запросов (это возможно потому, что читающие пользователи не блокируют пишущих), компактность (дистрибутив 5Mb), высокую эффективность и мощную языковую поддержку для хранимых процедур и триггеров /5/.

Таким образом, использование СУБД Firebird 2.5 достаточно для создания базы данных. Её функциональные возможности позволяют полностью спроектировать базу данных со множеством нюансов.

6. Описание программы

6.1 Общие сведения

Программное обеспечение автоматизированной информационной системы "Автоматизация учета успеваемости студентов" реализовано в среде программирования Borland Developer Studio 2006, база данных реализована средствами утилиты IBExpert 2010.03.23, СУБД Firebird 2.5.

Текст программы приведен в приложении Г.

6.2 Функциональное назначение

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

6.3 Описание логической структуры

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

Все данные по системе хранятся в БД, для обеспечения доступа к данным разработаны SQL-запросы.

Текст SQL-запросов приведен в приложении В.

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

База данных создана с помощью инструмента IBExpert. При этом в качестве сервера базы данных использовался удаленный сервер с именем sqledu03.

Файл базы данных имеет имя C: \\DK. FDB. При создании базы данных были заполнены поля: сервер - удалённый, имя сервера - sqledu03, файл БД - DEK. fdb, клиентская библиотека - fbclient. dll, имя пользователя - TEAM001, пароль - 12345, диалект БД - 3.

База данных зарегистрирована под именем Деканат (значение поля "Описание базы данных"). При этом использован сервер Firebird версии 2.5.

Таблицы "FORMAOB" и "STUDENT" соединены между собой внешним ключом N_FO. Для этого был написан обработчик:

ALTER TABLE STUDENT ADD CONSTRAINT FK_STUDENT_1 FOREIGN KEY (N_FO) REFERENCES FORMAOB (N_FO)

Таблицы "GRUPPA" и "STUDENT" соединены между собой внешним ключом NGRUP. Для этого был написан обработчик:

ALTER TABLE STUDENT ADD CONSTRAINT FK_STUDENT_2 FOREIGN KEY (NGRUP) REFERENCES GROUP (NGRUP)

Таблицы "GRUPPA" и "NAGRUZKA" соединены между собой внешним ключом NGRUP. Для этого был написан обработчик:

ALTER TABLE NAGRUZKA ADD CONSTRAINT FK_NAGRUZKA_4 FOREIGN KEY (NGRUP) REFERENCES GRUPPA (NGRUP)

Таблицы "SPECIAL" и "GRUPPA" соединены между собой внешним ключом FK_GRUPPA_1. Для этого был написан обработчик:

ALTER TABLE GRUPPA ADD CONSTRAINT FK_GRUPPA_1 FOREIGN KEY (NSPEC) REFERENCES SPECIAL (NSPEC);

Таблицы "DISCIPLINA" и "VEDOMOST" соединены между собой внешним ключом NDISC. Для этого был написан обработчик:

ALTER TABLE VEDOMOST ADD CONSTRAINT FK_VEDOMOST_3 FOREIGN KEY (NDISC) REFERENCES DISCIPLINA (NDISC);

Таблицы "DISCIPLINA" и "NAGRUZKA" соединены между собой внешним ключом NDISC. Для этого был написан обработчик:

ALTER TABLE NAGRUZKA ADD CONSTRAINT FK_NAGRUZKA_3 FOREIGN KEY (NDISC) REFERENCES DISCIPLINA (NDISC);

Таблицы "SEMESTR" и "NAGRUZKA" соединены между собой внешним ключом NSEM. Для этого был написан обработчик:

ALTER TABLE NAGRUZKA ADD CONSTRAINT FK_NAGRUZKA_1 FOREIGN KEY (NSEM) REFERENCES SEMESTR (NSEM);

Таблицы "PREPOD" и "NAGRUZKA" соединены между собой внешним ключом NPRED. Для этого был написан обработчик:

ALTER TABLE NAGRUZKA ADD CONSTRAINT FK_NAGRUZKA_2 FOREIGN KEY (NPRED) REFERENCES PREPOD (NPRED);

Таблицы "CAFEDRA" и "PREPOD" соединены между собой внешним ключом NCAF. Для этого был написан обработчик:

ALTER TABLE PREPOD ADD CONSTRAINT FK_PREPOD_1 FOREIGN KEY (NCAF) REFERENCES CAFEDRA (NCAF);

Программа разработана в среде Borland Developer Studio 2006.

На модуле данных приложения размещены следующие компоненты для работой с БД: TIBDatabase, TIBTransaction, TIBDataSet, TIBQuery с вкладки InterBase и компонент DataSource с вкладки DataAccess. И присвоить этим компонентам соответствующие имена: dbFO (Для связи с БД), WriteTansaction, ReadTransaction (для совершения транзакций), dstGr, dsGr (для связи с таблицей "Группа"), dstFO, dsfO (для связи с таблицей "Форма обучения ”), dstSpc, dsSpc (для связи с таблицей "Специальность”), dstdis, dsdis (для связи с таблицей "Дисциплина”), dstved, dsved (для связи с таблицей " ведомости”), dstPre, dsPre (для связи с таблицей "Преподаватель”), dstcaf, dscaf (для ввода данных в таблицу "Кафедра”), dstNag, dsNag (для ввода данных в таблицу "Учебный план ”), dstSem, dsSem (для ввода данных в таблицу "Семестр”), dstRep1, dstRep22, dstRep23, dstRep2, dstRep3 (для создания отчетов),

Форма модуля данных представлена на рисунке Ж 2.

Текст модулей разработанной программы (Unit1. pas, Unit2. pas, Unit3. pas, Unit4. pas, Unit5. pas, Unit6. pas, Unit7. pas, Unit8. pas, Unit9. pas, Unit10. pas, Unit11. pas, Unit12. pas, Unit13. pas,) приведен в приложении Г.

Проект сохранен в отдельном каталоге Dekanat на локальном диске D: \ под именем Dekanat. dpr. Исполняемый файл - Dekanat. exe.

Описание процедур и функций разработанной программы представленны в таблице 14.

Таблица 14 - Структура программы

Модули

Процедуры и функции

Назначение

Unit1

procedure TFormObuchForm. Button4Click (Sender: TObject);

Обработчик события нажатия на кнопку "Выход"

Unit1

procedure TFormObuchForm. Button3Click (Sender: TObject);

Обработчик события нажатия на кнопку "Удалить"

procedure TFormObuchForm. Button2Click (Sender: TObject);

Обработчик события нажатия на кнопку "Изменить"

procedure TFormObuchForm. Button1Click (Sender: TObject);

Обработчик события нажатия на кнопку "Добавить"

procedure TFormObuchForm. DBGrid1CellClick (Column: TColumn);

Обработчик события onCellClick компонента DBGrid1

procedure TFormObuchForm. DBGrid1TitleClick (Column: TColumn);

Обработчик события onTitleClick компонента DBGrid1

Unit3

procedure TGroupForm. Button4Click (Sender: TObject);

Обработчик события нажатия на кнопку "Выход"

procedure TGroupForm. Button3Click (Sender: TObject);

Обработчик события нажатия на кнопку "Удалить"

procedure TGroupForm. Button2Click (Sender: TObject);

Обработчик события нажатия на кнопку "Изменить"

procedure TGroupForm. Button1Click (Sender: TObject);

Обработчик события нажатия на кнопку "Добавить"

procedure TGroupForm. DBGrid1CellClick (Column: TColumn);

Обработчик события onCellClick компонента DBGrid1

procedure TGroupForm. DBGrid1TitleClick (Column: TColumn);

Обработчик события onTitleClick компонента DBGrid1

Unit4

procedure TJurnalForm. Button4Click (Sender: TObject);

Обработчик события нажатия на кнопку "Выход"

procedure TJurnalForm. Button3Click (Sender: TObject);

Обработчик события нажатия на кнопку "Удалить"

Procedure TJurnalForm. Button2Click (Sender: TObject);

Обработчик события нажатия на кнопку "Изменить"

Unit4

Procedure TJurnalForm. Button1Click (Sender: TObject);

Обработчик события нажатия на кнопку "Добавить"

Procedure TJurnalForm. DBGrid1CellClick (Column: TColumn);

Обработчик события onCellClick компонента DBGrid1

Procedure TJurnalForm. DBGrid1TitleClick (Column: TColumn);

Обработчик события onTitleClick компонента DBGrid1

Unit5

procedure TKafForm. Button4Click (Sender: TObject);

Обработчик события нажатия на кнопку "Выход"

Procedure TKafForm. Button2Click (Sender: TObject);

Обработчик события нажатия на кнопку "Изменить"

Procedure TKafForm. Button1Click (Sender: TObject);

Обработчик события нажатия на кнопку "Добавить"

Procedure TKafForm. DBGrid1CellClick (Column: TColumn);

Обработчик события onCellClick компонента DBGrid1

procedure TKafForm. DBGrid1TitleClick (Column: TColumn);

Обработчик события onTitleClick компонента DBGrid1

procedure TKafForm. Button3Click (Sender: TObject);

Обработчик события нажатия на кнопку "Удалить"

Unit6

procedure TNagForm. Button4Click (Sender: TObject);

Обработчик события нажатия на кнопку "Выход"

procedure TNagForm. Button2Click (Sender: TObject)

обработчик события нажатия на кнопку "Изменить"

procedure TNagForm. Button1Click (Sender: TObject)

обработчик события нажатия на кнопку "Добавить"

procedure TNagForm. DBGrid1CellClick (Column: TColumn)

обработчик события onCellClick компонента DBGrid1

procedure TNagForm. DBGrid1TitleClick (Column: TColumn)

обработчик события onTitleClick компонента DBGrid1

Unit6

procedure TNagForm. Button3Click (Sender: TObject)

обработчик события нажатия на кнопку "Удалить"

Unit7

procedure TPredmForm. Button4Click (Sender: TObject)

обработчик события нажатия на кнопку "Выход"

procedure TPredmForm. Button2Click (Sender: TObject)

обработчик события нажатия на кнопку "Изменить"

procedure TPredmForm. Button1Click (Sender: TObject)

обработчик события нажатия на кнопку "Добавить"

procedure TPredmForm. DBGrid1CellClick (Column: TColumn)

обработчик события onCellClick компонента DBGrid1

procedure TPredmForm. DBGrid1TitleClick (Column: TColumn)

обработчик события onTitleClick компонента DBGrid1

procedure TPredmForm. Button3Click (Sender: TObject)

обработчик события нажатия на кнопку "Удалить"

Unit8

procedure TPrepodForm. Button4Click (Sender: TObject)

обработчик события нажатия на кнопку "Выход"

procedure TPrepodForm. Button2Click (Sender: TObject)

обработчик события нажатия на кнопку "Изменить"

Procedure TPrepodForm. Button1Click (Sender: TObject);

Обработчик события нажатия на кнопку "Добавить"

Procedure TPrepodForm. DBGrid1CellClick (Column: TColumn);

Обработчик события onCellClick компонента DBGrid1

Procedure TPrepodForm. DBGrid1TitleClick (Column: TColumn);

Обработчик события onTitleClick компонента DBGrid1

procedure TPrepodForm. Button3Click (Sender: TObject);

Обработчик события нажатия на кнопку "Удалить"

Unit9

procedure TSemForm. Button4Click (Sender: TObject);

Обработчик события нажатия на кнопку "Выход"

Procedure TSemForm. Button2Click (Sender: TObject);

Обработчик события нажатия на кнопку "Изменить"

Unit9

Procedure TSemForm. Button1Click (Sender: TObject);

Обработчик события нажатия на кнопку "Добавить"

Procedure TSemForm. DBGrid1CellClick (Column: TColumn);

Обработчик события onCellClick компонента DBGrid1

Procedure TSemForm. DBGrid1TitleClick (Column: TColumn);

Обработчик события onTitleClick компонента DBGrid1

procedure TSemForm. Button3Click (Sender: TObject);

Обработчик события нажатия на кнопку "Удалить"

Unit10

procedure TSpecForm. Button4Click (Sender: TObject);

Обработчик события нажатия на кнопку "Выход"

Procedure TSemForm. Button2Click (Sender: TObject);

Обработчик события нажатия на кнопку "Изменить"

Procedure TSemForm. Button1Click (Sender: TObject);

Обработчик события нажатия на кнопку "Добавить"

Procedure TSemForm. DBGrid1CellClick (Column: TColumn);

Обработчик события onCellClick компонента DBGrid1

Procedure TSemForm. DBGrid1TitleClick (Column: TColumn);

Обработчик события onTitleClick компонента DBGrid1

procedure TSemForm. Button3Click (Sender: TObject);

Обработчик события нажатия на кнопку "Удалить"

Unit11

procedure TStudentsForm. Button4Click (Sender: TObject);

Обработчик события нажатия на кнопку "Выход"

Procedure TStudentsForm. Button2Click (Sender: TObject);

Обработчик события нажатия на кнопку "Изменить"

Procedure TStudentsForm. Button1Click (Sender: TObject);

Обработчик события нажатия на кнопку "Добавить"

Procedure TStudentsForm. DBGrid1CellClick (Column: TColumn);

Обработчик события onCellClick компонента DBGrid1

Procedure TStudentsForm. DBGrid1TitleClick (Column: TColumn);

Обработчик события onTitleClick компонента DBGrid1

Unit11

procedure

TStudentsForm. Button3Click (Sender: TObject);

Обработчик события нажатия на кнопку "Удалить"

Unit12

Procedure TView. N13Click (Sender: TObject);

Обработчик события нажатия на кнопку меню "Файл"-"Выход"

Procedure TView. N2Click (Sender: TObject);

Обработчик события нажатия на кнопку меню "Справочник" - "Студенты"

Procedure TView. N3Click (Sender: TObject);

Обработчик события нажатия на кнопку меню "Справочник" - "Группы"

Procedure TView. N7Click (Sender: T...

Страница:


Подобные документы

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены