Разработка структурной схемы проекта и структуры программного обеспечения, Проектирование базы данных - Разработка и тестирование автоматизированной системы контроля успеваемости студентов

При работе над проектом разрабатывались два основных компонента системы: база данных (далее - БД) и интерфейс клиентского приложения. Затем необходимо было обеспечить связь между ними. Таким образом, изначально следовало спроектировать структуру базы данных и реализовать ее из MySQL, и параллельно с этим разрабатывать интерфейс и клиент-серверную связь.

Проектирование базы данных

Для начала необходимо было определить сущности будущей базы данных вместе с соответствующими им атрибутами. Удалось выделить следующие сущности:

    1. Преподаватель. Атрибуты: ID преподавателя, Ф. И.О., логин, пароль. 2. Группа. Атрибуты: название группы. 3. Студент. Атрибуты: студенческий билет, Ф. И.О., название группы, вариант, логин, пароль. 4. Предмет. Атрибуты: ID предмета, название предмета, модуль. 5. Занятие. Атрибуты: ID занятия, ID предмета, тип занятия, дата deadline, процент понижения, вид контроля знания, вес оценки. 6. Оценка. Атрибуты: ID студента, ID занятия, оценка, дата сдачи, ID преподавателя. 7. Виды занятий. Атрибуты: Название. 8. Годы обучения. Атрибуты: Учебный год. 9. Модуль. Атрибуты: ID модуля, год обучения, номер модуля, дата начала, дата окончания, дата начала сессии.

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

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

Рис. 1. ER-диаграмма базы данных

Следующим шагом следовало построить ER-диаграмму. Результат представлен на рис. 1.

Далее необходимо перевести ER-диаграмму в схему БД, используя стандартные правила. При этом требуется провести несколько шагов нормализации.

Перевод в схему баз данных осуществляется по следующим правилам:

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

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

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

При первом шаге нормализации сложные атрибуты "Ф. И.О." у таблиц "Студенты" и "Преподаватели" разделяются на простые поля "Фамилия", "Имя", "Отчество". Других сложных полей в структуре нет.

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

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

В результате получается итоговая схема базы данных для разрабатываемого проекта (рис. 2).

схема базы данных

Рис. 2. Схема базы данных

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

- Под количество учебных годов отводится 10 мест типа char(9), тогда

.

- Под количество типов занятий отводится 8 мест типа char(20), тогда

.

- Количество модулей зависит от количества учебных годов, на 10 лет это:

.

- Под 50 названий групп типа char(8) требуется:

.

    - Под одного студента: - В группе по 40 студентов

.

- В штате департамента около 200 преподавателей, тогда:

.

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

.

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

- В модуле максимум 11 недель, то есть возможно провести11 лабораторных работ, 2 курсовых/рефератов/эссе и около 11 домашних работ. У каждого такого занятия может быть 3 deadline, тогда для одного года потребуется объем:

    - Формулы хранятся для каждого вида занятия отдельно для каждого модуля, в таком случае для каждого учебного года память рассчитывается по формуле: - Для хранения оценок потребуется объем памяти, вычисляемый по формуле: - Для хранения базы данных по каждому учебному году необходимо выделить объем памяти, который можно вычислить по формуле:
    - Благодаря округлению и тому, что типы занятий и все учебные годы требуют для хранения данных одинакового объема памяти для каждого года, их можно не учитывать в расчетах. - Архив необходимо хранить около 9 лет: 10*1,5= 15 Гб. - Под дополнительные файлы необходимо столько же места, сколько под всю информацию БД: 15 * 2 = 30 Гб.

Итого для хранения информации об оценках на сервере необходимо около 30 Гб постоянной памяти.

На данном этапе процесс проектирования базы данных может считаться завершенным.

Похожие статьи




Разработка структурной схемы проекта и структуры программного обеспечения, Проектирование базы данных - Разработка и тестирование автоматизированной системы контроля успеваемости студентов

Предыдущая | Следующая