Автоматизированная работа школы

Автор работы: Пользователь скрыл имя, 20 Января 2015 в 11:03, курсовая работа

Краткое описание

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

Вложенные файлы: 1 файл

Работа школы.doc

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

1. Введение

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

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

максимально возможная независимость прикладных программ от данных.

Выполнение этих требований привело к появлению единого блока данных (базы данных (БД) и разработке одной управляющей программы для манипулирования данными на физическом уровне (системы управления данными СУБД).

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

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

Процесс проектирования БД представляет собой последовательность перехода от неформального словесного описания информационной структуры  предметной области к формальному описанию объектов предметной области  в терминах некоторой модели.

В общем случае можно выделить следующие этапы проектирования:

    • системный анализ и словесное описание информационных объектов предметной области;
    • проектирование инфологической модели предметной области  - частично формализованное описание  объектов предметной области  в терминах некоторой семантической модели;
    • даталогическое или логическое проектирование БД, т.е. описание БД в терминах принятой даталогической  модели данных;
    • физическое проектирование БД, т.е. выбор эффективного размещения БД на внешних носителях для обеспечения наиболее эффективной работы приложения.

В качестве системы управления базой данных в данной курсовой работе используется СУБД MS Access.

 

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

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

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

Завучу могут потребоваться следующие сведения:

    • какой предмет будет в заданном классе, например, во вторник на заданном уроке;
    • кто из учителей преподает в заданном классе;
    • в коком кабинете будет 5-й урок в среду у некоторого класса;
    • в каких классах преподает учитель заданный предмет;
    • расписание на заданный день недели для класса.

Завуч может вносить следующие изменения:

    • вносить  информацию о новом учителе;
    • удалять запись об ученике;
    • изменить оценку ученику.

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

 

3. Схема данных

Для определения схемы данных проектируемой базы данных, то есть построения ее инфологической модели, необходимо определить сущности и связи БД. С помощью сущности моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Сущность соответствует некоторому классу однотипных объектов, поэтому предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов – характеристик, определяющих свойства данного представителя класса. Между сущностями могут быть установлены связи – бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют друг с другом. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).

 

 

 

 

 

Рис. Инфологическая модель БД школы

 

4. Нормализация БД

Проектирование схемы БД может быть выполнено двумя путями:

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

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

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

В теории реляционных БД обычно выделяется следующая последовательность нормальных форм:

    • 1-я (1NF);
    • 2-я (2 NF);
    • 3-я (3 NF);
    • Бойса-Кодда (ВС-NF);
    • 4-я (4 NF);
    • 5-я (5 NF) или форма проекции-соединения (PJNF).

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

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

В проектируемой БД имеется отношение расписание, которое имеет вид:

День

Класс

№ урока

Предмет

Id преподавателя

Кабинет

Понедельник

1

Русский язык

1

12

2

Математика

2

3

Физкультура

4

1


 

Теперь приведем данное отношение к первой нормальной форме:

 

День

Класс

№ урока

Предмет

Id преподавателя

Кабинет

Понедельник

1

Русский язык

1

12

Понедельник

2

Математика

2

12

Понедельник

3

Физкультура

4

1


 

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

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

ID

ФИО

Класс

Предмет

I четверть

II

III

IV

Годовая


 

Первичным ключом данного отношения могут атрибуты «ID ученика» и «Предмет». С другой стороны, атрибуты «ФИО» и «Класс» зависят только от части первичного ключа – от значения атрибута «ID», поэтому необходимо констатировать наличие неполных функциональных зависимостей в данном отношении. Для приведения данного отношения ко второй нормальной форме следует  разбить его на проекции, при этом должно быть соблюдено условие восстановления исходного отношения без потерь.

Такими проекциями могут быть два отношения:

- (ID, ФИО, класс),

- (ID, предмет, I четверть, II, III, IV, Годовая оценка).

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

Отношение находится в 3-й нормальной форме тогда и только тогда, когда оно находится во 2-й нормальной форме и не содержит транзитивных зависимостей.

Отношение находится в нормальной форме Бойса-Кодда, если оно находится в 3-й нормальной форме и каждый детерминант отношения является возможным ключом отношения.

Отношение R находится в 4-й нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости А->>В все остальные атрибуты R функционально зависят от А.

Все отношения проектируемой БД, которые представлены в пункте 3. Схема данных являются приведенными к четвертой нормальной форме.

 

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

5.1 Создание таблиц

 

В спроектированной базе данных школы созданы следующие таблицы:

    • Кабинеты
    • Классы
    • Оценки
    • Предметы
    • Преподаватели
    • Расписание
    • Ученики

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

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

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

Таблица Ученики состоит из следующих полей: ID (ключевое, счетчик), ФИО (текстовое), Класс (текстовое).

Рис. Таблица Ученики в режиме конструктора

В таблице Оценки хранятся оценки, полученные учениками. Таблица состоит из следующих полей: ID (ID ученика, числовое), Предмет (текстовое, источник строк - таблица Предметы), I четверть (числовое), II четверть, III четверть, IV четверть, Годовая.

 

Рис. Связи между таблицами Классы - Ученики – Оценки

В таблице Преподаватели хранится список преподавателей. Таблица состоит из следующих полей: id_преп (ID преподавателя, ключевое, счетчик), Преподаватель (ФИО, текстовое), каб_закр (закрепленный кабинет - необязательное поле, источник строк – таблица Кабинеты, числовое).

Преподаватель может вести несколько предметов. В таблице Предметы хранятся данные, какие предметы ведет тот или иной преподаватель. Таблица состоит из полей id_преп (ID преподавателя) и поля Предмет (текстовое). Поля id_преп и Предмет являются ключевыми.

Рис. Связь между таблицами Преподаватели и Предметы

В таблице Расписание хранится расписание занятий школы. Таблица состоит из следующих полей: День (текстовое поле, источник строк – список значений, дни недели), Класс, Номер_урока (числовое поле),  Предмет, id_преп (ID преподавателя), Кабинет.

 

5.2 Запросы

 

Для вывода отчета о работе школы созданы следующие запросы:

- Количество кабинетов;

SELECT Count(Кабинеты.Кабинет) AS [Count-Кабинет] FROM Кабинеты;

- Ученики в классах  (количество учеников в каждом классе);

Рис. Запрос Ученики в классах

- Учителя по предметам;

Рис. Запрос Учителя по предметам в режиме конструктора

-Статистика оценок (показывает минимальную оценку каждого ученика по четвертям и за год);

Рис. Запрос Статистика оценок в режиме конструктора

-Запросы I_Двоечники, I_Троечники, I_Ударники, I_Отличники подсчитывают количество соответственно двоечников, троечников, ударников, отличников за первую четверть. Существуют аналогичные запросы для других четвертей и для годовой оценки. Такое деление запросов оценок на подзапросы выбрано для упрощения создания отчета.

Рис. Запрос I_Отличники в режиме конструктора

- Запрос Ученики в данном классе создан для выдачи справки о количестве учеников в заданном классе.

Рис. Запрос Ученики в данном классе в режиме конструктора

 

 

 

5.3 Отчеты

В базе данных имеются следующие отчеты:

- Отчет по количеству кабинетов;

 

Рис. Отчет по количеству кабинетов в режиме конструктора

- Ученики по классам;

- Отчет об успеваемости;

Информация о работе Автоматизированная работа школы