- •Введение.
- •Анализ предметной области
- •Характеристика комплекса задач, задачи и обоснование необходимости автоматизации
- •Организация текущего документооборота в учебно-методическом дюсш №5.
- •Выбор комплекса задач автоматизации и характеристика существующих бизнес процессов
- •Определение места проектируемой задачи в комплексе задач и ее описание
- •Анализ системы обеспечения информационной безопасности и защиты информации
- •Анализ существующих разработок и выбор стратегии автоматизации «как должно быть»
- •Анализ существующих разработок для автоматизации задачи
- •Выбор и обоснование стратегии автоматизации задачи
- •Выбор и обоснование способа приобретения ис для автоматизации задачи
- •Обоснование проектных решений
- •Обоснование проектных решений по техническому обеспечению
- •Обоснование проектных решений по информационному обеспечению
- •Обоснование проектных решений по программному обеспечению
- •Проектная часть.
- •Разработка логической модели данных
- •Разработка физической модели данных
- •Инструкция пользователя
- •Характеристика результатной информации
- •Инструкция администратора
- •Структурная схема пакета (дерево вызова программных модулей)
- •Описание программных модулей
- •Тестирование программы
- •Заключение
- •Список использованных источников
- •Приложение а. Листинг программного кода
Проектная часть.
Разработка логической модели данных
Исходя из предметной области ДЮСШ №5, описанной ранее, можно выделить 3 основные сущности модели данных:
Учащиеся – представляет информацию о каждом клиенте, заключившим договор на дополнительное образование со школой;
Сотрудники – представляет информацию о сотрудниках (преподавателях и тренерах, работающих в школе);
Договор на обучение – представляет информацию о всех договорах между школой и учащимися.
Для каждой сущности необходимо определить атрибуты. Для сущности Учащийся определены следующие атрибуты:
регистрационный номер учащегося (ключевой атрибут) – идентификатор учащегося;
фамилия – фамилия учащегося;
имя – имя учащегося;
отчество - учащегося;
документ- серия и номер свидетельства о рождении или основные паспортные данные;
дата регистрации учащегося – дата заключения договора на обучение с школой;
адрес по прописке– адрес учащегося по прописке;
фактический адрес – адрес фактического места проживания учащегося;
контактный телефон – телефонный номер, по которому можно связаться с учащимся;
Для сущности Группы определены следующие атрибуты:
код группы (ключевой атрибут) – идентификатор группы;
Дата открытия – дата открытия Группы;
Дата закрытия – дата открытия Группы;
Специализация- вид спорта, которым занимаются учащиеся в группе;
Куратор – имя сотрудника, являющегося классным руководителем в группе;
Для сущности Договор определены следующие атрибуты:
номер договора (ключевой атрибут) – идентификатор договора;
дата заключения договора – дата подписания договора учащимся;
Учащийся-код учащегося, с которым заключен договор;
сумма оплаты за обучение – денежная сумма, подлежащая оплате за обучение за месяц;
Теперь необходимо определить связи между сущностями.
Учащийся может заключать несколько договоров, но один договор не может быть заключен несколькими учащимися. Поэтому связь от учащегося к договору – 1:М. Имя связи – «заключает».
Группа может быть прикреплена к нескольким договорам, но к одному договору не может быть прикреплено несколько групп. Поэтому связь от группы к договору – 1:М. Имя связи – «прикреплен к».
Рисунок 32 – ER-диаграмма модели данных
Для экономии памяти выделенной под БД в модель данных можно ввести справочники:
справочник сотрудники – для определения классного руководителя группы по ее коду;
справочник Здоровье- для определения параметров здоровья учащегося по его коду.
Составленная логическая модель данных выглядит следующим образом:
Рисунок 33 – Логическая модель данных
Таким образом логическая модель данных состоит из трех основных сущностей и трех сущностей-справочников.
Разработка физической модели данных
Из логической модели данных средствами среды сгенерирована физическая модель. Теперь Учащийся, Договор и Группа являются таблицами, а не сущностями.
Рисунок 34 – Физическая модель данных
Все атрибуты сущностей стали полями таблицы. Каждое из полей должно иметь определенный тип. Поля таблицы Учащиеся имеют следующие типы:
Код_учащегося (ключевое поле)– INTEGER;
фамилия – VARCHAR(20);
имя – VARCHAR(20);
отчество - VARCHAR(20);
документ – VARCHAR(10);
дата_регистрации_клиента – DATE;
адрес по прописке – VARCHAR(100);
фактический_адрес – VARCHAR(100);
контактный_телефон – VARCHAR(11);
код_параметра_здоровья (FK) – INTEGER;
код_группы(FK) - INTEGER.
Поля таблицы Группа имеют следующие типы:
код_группы (ключевое поле) – INTEGER;
дата_открытия – DATE;
дата_закрытия – DATE;
дата_покупки – DATE;
специализация – VARCHAR(100);
код_сотрудника (FK) – INTEGER;
Поля таблицы Договор имеют следующие типы:
номер_договора (ключевое поле) – INTEGER;
дата_заключения_договора – DATE;
сумма_оплаты_за_обучение – FLOAT;
код_учащегося(FK) – INTEGER;
Спаравочники в программе будут представлены в виде выпадающих списков для полей добавления записей в базу данных.