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

Тип работы: Курсовая работа
Бесплатно: Антиплагиат
Объем: 21 страниц
В избранное:

Подсистема Диспетчерская служба такси
КУРСОВАЯ РАБОТАVПодсистема Диспетчерская служба такси
КУРСОВАЯ РАБОТА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. Инфологическая модель базы данных диспетчера службы такси

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

2.3.1 Процедура нормализации сущностей

Теперь следует проверить, не нарушены ли в данном проекте какие-либо принципы нормализации, то есть что любое неключевое поле каждой таблицы:
- функционально зависит от полного первичного ключа, а не от его части (если ключ составной);
- не имеет функциональной зависимости от другого неключевого поля.
Нормализация - это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных.
Функциональная зависимость. Поле В таблицы функционально зависит от поля А той же таблицы в том и только в том случае, когда в любой заданный момент времени для каждого из различных значений поля А обязательно существует только одно из различных значений поля В. Отметим, что здесь допускается, что поля А и В могут быть составными.
Как уже говорилось, нормализация - это разбиение таблицы на несколько, обладающих лучшими свойствами при обновлении, включении и удалении данных. Проверка показала, что:
Все таблицы нормализованы, потому что имеет несоставной первичный ключ и не одно из его неключевых полей функционально не зависит от других неключевых полей.

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

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

СОЗДАТЬ ТАБЛИЦУ
Марка * (Стержневая сущность)
ПЕРВИЧНЫЙ КЛЮЧ
(КодМарки)
ПОЛЯ
(КодМарки Целое, Название Текст 50)
ОГРАНИЧЕНИЯ

(Значение КодМарки должно быть уникальным)
СОЗДАТЬ ТАБЛИЦУ
Цвет* (Стержневая сущность)
ПОЛЯ
(КодЦвета Целое, Название Текст 50)
ОГРАНИЧЕНИЯ
(Значение КодЦвета должно быть уникальным)

СОЗДАТЬ ТАБЛИЦУ
Улица* (Стержневая сущность)
ПЕРВИЧНЫЙ КЛЮЧ
(КодУлицы)
ПОЛЯ
(КодУлицы Целое, Название Текст 50)
ОГРАНИЧЕНИЯ

(Значение КодУлицы должно быть уникальным)
СОЗДАТЬ ТАБЛИЦУ
Диспетчер* (Стержневая сущность)
ПЕРВИЧНЫЙ КЛЮЧ
(КодДиспетчера)
ПОЛЯ
(КодДиспетчера Целое, ФИО Текст 50)
ОГРАНИЧЕНИЯ
(Значение КодДиспетчера должно быть уникальным)

СОЗДАТЬ ТАБЛИЦУ
Водители* (Стержневая сущность)
ПЕРВИЧНЫЙ КЛЮЧ
(КодВодителя)
ПОЛЯ
(КодВодителя Целое, ФИО Текст 50)
ОГРАНИЧЕНИЯ
(Значение КодВодителя должно быть уникальным)

СОЗДАТЬ ТАБЛИЦУ
Клиент* (Ассоциативная сущность)
ПЕРВИЧНЫЙ КЛЮЧ
ВНЕШНИЙ КЛЮЧ
(КодКлиента)
КодУлицы
Null - значения не допустимы
Удаление из Улица ОГРАНИЧИВАЕТСЯ
Обновление в Улица КАСКАДИРУЕТСЯ
ПОЛЯ
(КодКлиента Целое, КодУлицы Целое, ФИО_организация Текст 50,Номер_дома Целое, Номер_квартиры Целое, Телефон Текст 20)
ОГРАНИЧЕНИЯ
(Значение КодКлиента должно быть уникальным)

СОЗДАТЬ ТАБЛИЦУ
Машины * (Ассоциативная сущность)
ПЕРВИЧНЫЙ КЛЮЧ
ВНЕШНИЙ КЛЮЧ
(КодМашины)
Код_цвета
Null - значения не допустимы
Удаление из Цвет ОГРАНИЧИВАЕТСЯ
Обновление в Цвет КАСКАДИРУЕТСЯ
Код_марки
Null - значения не допустимы
Удаление из Марка ОГРАНИЧИВАЕТСЯ
Обновление в Марка КАСКАДИРУЕТСЯ
ПОЛЯ
(КодМашины Текст 10, Код_цвета Целое, Код_марки
Целое)
ОГРАНИЧЕНИЯ

(Значение КодМашины должно быть уникальным)

СОЗДАТЬ ТАБЛИЦУ
Движение * (Ассоциативная сущность)
ПЕРВИЧНЫЙ КЛЮЧ
ВНЕШНИЙ КЛЮЧ
(КодЗаказа)
КодКлиента
Null - значения не допустимы
Удаление из Клиент ОГРАНИЧИВАЕТСЯ
Обновление в Клиент КАСКАДИРУЕТСЯ
КодДиспетчера
Null - значения не допустимы
Удаление из Диспетчера ОГРАНИЧИВАЕТСЯ
Обновление в Диспетчера КАСКАДИРУЕТСЯ
КодМашины
Null - значения не допустимы
Удаление из Машины ОГРАНИЧИВАЕТСЯ
Обновление в Машины КАСКАДИРУЕТСЯ
КодВодителя
Null - значения не допустимы
Удаление из Водители ОГРАНИЧИВАЕТСЯ
Обновление в Водители КАСКАДИРУЕТСЯ
ПОЛЯ
(КодЗаказа Целое, КодКлиента Целое, КодДиспетчера
Целое, КодМашины Целое, КодВодителя Целое, Дата ДатаВремя, Время Текст 5, Сумма заказа Денежный)
ОГРАНИЧЕНИЯ

(Значение КодЗаказа должно быть уникальным)

СОЗДАТЬ ТАБЛИЦУ
Касса* (Ассоциативная сущность)
ПЕРВИЧНЫЙ КЛЮЧ
ВНЕШНИЙ КЛЮЧ
(КодПлатежа)
КодВодителя
Null - значения не допустимы
Удаление из Водители ОГРАНИЧИВАЕТСЯ
Обновление в Водители КАСКАДИРУЕТСЯ
КодДиспетчера
Null - значения не допустимы
Удаление из Диспетчера ОГРАНИЧИВАЕТСЯ
Обновление в Диспетчера КАСКАДИРУЕТСЯ
ПОЛЯ
(КодПлатежа Целое, КодВодителя Целое, КодДиспетчера Целое, Дата ДатаВремя, Сумма_платежа Денежный)
ОГРАНИЧЕНИЯ
(Значение КодПлатежа должно быть уникальным)

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 - запросов.
:: Просмотр и модификация ... продолжение

Вы можете абсолютно на бесплатной основе полностью просмотреть эту работу через наше приложение.