Подсистема Диспетчерская служба такси

Содержание

Подсистема «Диспетчерская служба такси»

КУРСОВАЯ РАБОТА

V

Введение

1 Задание на проектирование

2 Разработка структуры БД

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

2. 2 Анализ информационных потоков

2. 3 Создание инфологической модели

2. 3. 1 Процедура нормализации сущностей

2. 4 Создание даталогической модели

2. 5 Выбор технических и программных средств реализации БД и клиентского приложения

3 Создание базы данных

3. 1 Описание структуры БД

3. 2 Описание свойств таблиц БД

3. 3 Описание связей между таблицами БД и условий целостности данных

4 Создание пользовательского интерфейса информационной системы

4. 1 Пользовательское меню

4. 2 Формы как средство добавления, удаления, просмотра, изменений данных в БД

4. 3 Формирование запросов к базе данных

4. 4 Формирование отчётов

4. 5 Формирование хранимых процедур

Заключение

Литература

1 Задание на проектирование

Вариант 45

Входная информация:

Подсистема «Диспетчерская служба такси»:

- Машины (Номер машины, код марки машины, код цвета) ; - Марка машины (Код марки, наименование марки) ; - Цвета (Код цвета, наименование) ; - Водители (Код водителя, ФИО) ; - Диспетчера (Код диспетчера, ФИО) ; - Клиенты (Код клиента, ФИО/наименование организации, код улицы, номер дома, квартиры, телефон) ; - Улицы (Код улицы, наименование) ; - Движение (дата, время заказа, код машины, код водителя, код клиента, код диспетчера, примечание, сумма заказа) ; - Касса (Код водителя, дата, код диспетчера, сумма прихода)

Запросы:

1. Какие марки машин и их количество работали «I-го» числа

2. ФИО диспетчеров, работавших в текущем месяце

3. Список клиентов, проживающих на «I-ой» улице

4. Список заказов, сумма заказов которых находится в диапазоне от … до … тенге

5. Список телефонов клиентов, заказывавших такси «I-го числа» в период от … до … часов

Отчёты:

1. Финансовый отчёт по приходу на «I-ю» дату «j-го» диспетчера

2. Наряд на «I-ый» заказ

3. Список машин, задействованных «j-го» числа

Хранимые процедуры:

1. Из таблицы Движение выбрать строки по условию: заказы «I-го» водителя на «j-ю» дату

(* код водителя и дату задавать как параметр) ;

2. Из таблицы Клиенты выбрать строки по условию: все заказы клиента с ФИО «…»

3. Вставить три новых строки в таблицу Цвета

2 Разработка структуры БД

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

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

Фирма осуществляет перевозку пассажиров. В рамках нашего проекта представляет интерес работа диспетчера.

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

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

2. 2 Анализ информационных потоков

БД «Диспетчерская служба такси» в качестве входных данных содержит: данные о диспетчерах, водителях, машинах, клиентах, месте проживания клиентов, заказах.

Данные о машинах включают в себя: Марку, Номер автомобиля и цвет.

Данные о водителях и диспетчерах включают в себя: ФИО

Данные о клиентах: ФИО, улица проживания, номер дома, номер квартиры, контактный телефон.

Выходные данные

- Финансовый отчёт.

- Список машин

- наряд на заказ

2. 3 Создание инфологической модели

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

1. Idclients (Уникальный идентификационный номер клиента) .

2. Full_name (ФИО клиента) .

3. Phone_number (Контактный номер телефона клиента)

4. House_number (Номер дома, где проживает клиент ) .

5. Apartment_number (Номер квартиры, где проживает клиент)

6. Idstreets (Название улицы, где проживает клиент )

Уникальный идентификационный номер записи используется для однозначного определения клиента.

К сведениям о цвете машины, можно отнести следующие атрибуты:

7. Idcolours (индивидуальный номер цвета)

8. Colour_name (Наименование цвета)

К сведениям о марке автомобиля можно отнести следующие атрибуты:

9. Idbrands (индивидуальный номер марки)

10. Brand_name (название марки)

К сведениям о машине можно отнести следующие атрибуты:

11. idcars (идентификационный номер машины)

12. Idcolours (цвет машины)

13. idbrands (марка машины)

К сведениям о заказе можно отнести следующие атрибуты:

14. idmovement (идентификационный номер заказа)

15. Idclients (Название клиента)

16. Iddrivers (ФИО водителя)

17. Idcars (Название машины)

18. Idtowermans (ФИО диспетчера)

19. Date (Дата заказа)

20. Order_time (Время заказа)

21. Order_price (Сумма заказа)

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

23. iddrivers (идентификационный номер водителя)

24. Full_name (ФИО водителя)

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

25. Idtowermans (идентификационный номер диспетчера)

26. Full_name (ФИО диспетчера)

К сведениям о кассе можно отнести следующие атрибуты:

27. Idcash (идентификационный номер платежа)

28. Idtowermans (ФИО диспетчера)

29. iddrivers (ФИО водителя)

30. Date (дата платежа)

31. Amount_received (Сумма прихода)

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

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

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

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

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1) : в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:

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

Второй тип - связь ОДИН-КО-МНОГИМ (1:М) : одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует ещё два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N) . Но в нашей работе такие типы связи нам не следует употреблять.

Язык ER-диаграмм. Виды связей:

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

Между двумя сущностям возможны четыре вида связей.

1. Связь ОДИН-К-ОДНОМУ (1:1) : в каждый момент времени каждому представителю (экземпляру) сущности соответствует 1 или 0 представителей другой сущности.

2. Связь ОДИН-КО-МНОГИМ (1:М) : одному представителю сущности

соответствуют 0, 1 или несколько представителей другой сущности.

3. Связь МНОГИЕ-К-ОДНОМУ (М:1)

4. Связь МНОГИЕ-КО-МНОГИМ (М:N) .

Инфологическую модель на языке ER-диаграмм можно изобразить следующим образом: (см. Приложение A) .

Рисунок 1. Инфологическая модель базы данных диспетчера службы такси

2. 3. 1 Процедура нормализации сущностей

Теперь следует проверить, не нарушены ли в данном проекте какие-либо принципы нормализации, то есть что любое неключевое поле каждой таблицы:

- функционально зависит от полного первичного ключа, а не от его части (если ключ составной) ;

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

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

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

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

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

2. 4 Создание даталогической модели

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

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

2. 5 Выбор технических и программных средств реализации БД и клиентского приложения

MySQL - свободная реляционная система управления базами данных. Разработку и поддержку MySQL осуществляет корпорация Oracle, получившая права на торговую марку вместе с поглощённой Sun Microsystems, которая ранее приобрела шведскую компанию MySQL AB. Продукт распространяется как под GNU General Public License, так и под собственной коммерческой лицензией. Помимо этого, разработчики создают функциональность по заказу лицензионных пользователей. Именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

Входит в состав серверов WAMP, AppServ, LAMP и в портативные сборки серверов Денвер, XAMPP, VertrigoServ. Обычно MySQL используется в качестве сервера, к которому обращаются локальные или удалённые клиенты, однако в дистрибутив входит библиотека внутреннего сервера, позволяющая включать MySQL в автономные программы. Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

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

Java Database Connectivity - это стандартный API для независимого соединения языка программирования Java с различными базами данных (далее - БД) .

JDBC решает следующие задачи:

• Создание соединения с БД.

• Создание SQL выражений.

• Выполнение SQL - запросов.

• Просмотр и модификация полученных записей.

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

JDBC поддерживает как 2-звенную, так и 3-звенную модель работы с БД, но в общем виде, JDBC состоит из двух слоёв.

1. JDBC API

Обеспечивает соединение “приложение - JDBC Manager”.

2. JDBC Driver API

Обеспечивает соединение “JDBC Manager - драйвер”.

JDBC API использует менеджер драйверов и специальные драйверы БД для обеспечения подключения к различным базам данных.

JBDC Manager проверяет соответствие драйвера и конкретной БД. Он поддерживает возможность использования нескольких драйверов одновременно для одновременной работы с несколькими видами БД.

Схематично, JDBC можно представить в таком виде:

Элементы JDBC

JDBC API состоит из следующих элементов:

• Менеджер драйверов (Driver Manager)

Этот элемент управляет списком драйверов БД. Каждой запрос на соединение требует соответствующего драйвера. Первое совпадение даёт нам соединение.

• Драйвер (Driver)

Этот элемент отвечает за связь с БД. Работать с ним нам приходится крайне редко. Вместо этого мы чаще используем объекты DriverManager, которые управляют объектами этого типа.

• Соединение (Connection)

Этот интерфейс обеспечивает нас методами для работы с БД. Все взаимодействия с БД происходят исключительно через Connection.

• Выражение (Statement)

Для подтверждения SQL-запросов мы используем объекты, созданные с использованием этого интерфейса.

• Результат (ResultSet)

Экземпляры этого элемента содержат данные, которые были получены в результате выполнения SQL - запроса. Он работает как итератор и “пробегает” по полученным данным.

• Исключения (SQL Exception)

Этот класс обрабатывает все ошибки, которые могут возникнуть при работе с БД.

3 Создание базы данных

3. 1 Описание структуры БД

3. 2 Описание свойств таблиц БД

-Таблица 1-Сущность - streets

-Таблица 2-Сущность - brands

-Таблица 3- Сущность - colours

-Таблица 4- Сущность - cars

-Таблица 5- Сущность - clients

-Таблица 6-Сущность - towermans

-Таблица 7-Сущность - drivers

-Таблица 8-Сущность - cash

... продолжение

Правила перевозки пассажиров такси в Республике Казахстан: требования, порядок организации и осуществления перевозок

Вопросы улучшения пассажирских перевозок на городском маршруте 519 подвижными составами АТП 6г. Алматы

Структура Управления Предприятием: Теоретические Аспекты и Практическое Применение в Гостиничном Бизнесе

Организация и функционирование системы гражданской защиты Республики Казахстан в чрезвычайных ситуациях

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

Коммуникационный процесс в организации: эффективное общение как ключевой фактор успешного руководства

Проектирование и монтаж электрооборудования 220 кВ для АТС, включая заземляющее устройство, молниеотражатели и водно-энергетическую инфраструктуру

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

Развитие транспортной инфраструктуры и туризма в Карагандинской области Республики Казахстан

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

• Информатика
• Банковское дело
• Оценка бизнеса
• Бухгалтерское дело
• Валеология
• География
• Геология, Геофизика, Геодезия
• Религия
• Общая история
• Журналистика
• Таможенное дело
• История Казахстана
• Финансы
• Законодательство и Право, Криминалистика
• Маркетинг
• Культурология
• Медицина
• Менеджмент
• Нефть, Газ
• Искуство, музыка
• Педагогика
• Психология
• Страхование
• Налоги
• Политология
• Сертификация, стандартизация
• Социология, Демография
• Статистика
• Туризм
• Физика
• Философия
• Химия
• Делопроизводсто
• Экология, Охрана природы, Природопользование
• Экономика
• Литература
• Биология
• Мясо, молочно, вино-водочные продукты
• Земельный кадастр, Недвижимость
• Математика, Геометрия
• Государственное управление
• Архивное дело
• Полиграфия
• Горное дело
• Языковедение, Филология
• Исторические личности
• Автоматизация, Техника
• Экономическая география
• Международные отношения
• ОБЖ (Основы безопасности жизнедеятельности), Защита труда