- •Расчетно-пояснительная записка к курсовому проекту на тему:
- •Введение
- •Аналитический раздел
- •Описание предметной области
- •1 Рисунок 1.1. Карта дорог .2 Требования к по
- •Определение бизнес-правил
- •1.4 Определение сущностей, связей между сущностями и атрибутов сущностей
- •Конструкторская часть
- •2.1. Обоснование выбора субд
- •3 Технологическая часть
- •3.1 Обоснование выбора языка и среды разработки
- •3.2 Взаимодействие с базой данных
- •3.3 Запросы к базе данных
- •3.4 Технологические особенности проекта
- •3.4.1. Класс iMap
- •3.4.2. Класс iDataHandler
- •3.5 Пользовательский интерфейс
- •4 Руководство пользователя
- •4.1 Анализ опасности
- •4.2 Заполнение путевого листа
- •4.3 Добавление
- •4.4 Удаление
- •4.4 Поиск информации
- •Заключение
- •Список литературы
1 Рисунок 1.1. Карта дорог .2 Требования к по
По результатам анализа предметной области можно определить следующий необходимый функционал приложения:
предоставление формы для заполнения путевых листов;
определение приблизительного времени нахождения водителя в каждом городе;
определение местоположения водителя в любое указанное время в рамках зарегистрированной на это время перевозки (в том числе текущее местоположение) по данным базы;
удаление завершённых перевозок и перевозок, зарегистрированных ранее указанного времени;
возможность изменения данных в базе;
расчёт маршрутов.
Пользователями базы данных являются операторы МЧС. При регистрации новой перевозки на водителя его предыдущие перевозки не удаляются автоматически ввиду возможности их последующей надобности. При удалении водителя удаляется вся информация о его перевозках.
Основной задачей базы данных является хранение оценок времени, на основании которых производится определение местонахождения водителя. Каждый водитель перед отправлением подаёт путевой лист, на основании которого производится расчёт и заполнение базы данными о новой перевозке. Основными типами информации в базе данных являются текст и время.
Определение бизнес-правил
Чтобы определить структуру базы данных, контролировать и влиять на операции с ней, необходимо определить бизнес-правила.
Каждый водитель должен иметь имя, фамилию и номер мобильного телефона, эти поля являются обязательными.
Водитель может не иметь отчества.
На водителя может быть не зарегистрирована ни одна перевозка.
Груз должен иметь название, уровень опасности и описание действий при аварии.
Количество посещаемых водителем городов равно как минимум двум.
Водитель может в рамках одной перевозки посетить один и тот же город несколько раз.
Маршрут может быть «специфическим» (например, из Воронежа в Москву через Курск).
Множество перевозок может быть зарегистрировано на одного водителя.
Несколько водителей не могут иметь один и тот же номер телефона.
Водители могут быть полными тёзками.
Водители не могут обмениваться номерами телефонов.
1.4 Определение сущностей, связей между сущностями и атрибутов сущностей
Для определения количества таблиц в базе данных обратимся к результатам изучения предметной области.
Создадим таблицу Transits как базовую таблицу о каждой перевозке, содержащую основной ID водителя и груза. Для определения параметров перевозки (время, города), создадим таблицу Routes. Связь между таблицами Transits и Routes «один к одному». Кроме того, для хранения рассчитанных оценок создадим таблицу TransitStadies, которая имеет связь с таблицей Transits «многие к одному». Для разбиения карты на области создадим таблицу Regions. Города хранятся в таблице Cities и имеют связь с таблицей Regions «многие к одному». Для хранения информации о водителе создадим таблицу Drivers, содержащую ID водителя и его ФИО. Все контакты хранятся в таблице Contacts, связанной с Drivers отношением «многие к одному». Для хранения информации о грузах создадим таблицу Consignments.
ER-диаграмма
ER-диаграмма
базы данных, составленная в результате
анализа предметной области и определения
целей создания приложения, показана на
рис. 1.2.
Рисунок 1.2. ER-диаграмма
