База данных для хранения информации о перевозках пассажиров и грузов

КУРСОВАЯ РАБОТА По дисциплине «Базы данных»

На тему: База данных для хранения информации о перевозках пассажиров и грузов

1. ВВЕДЕНИЕ

2. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

3. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

3.1 Проектирование декомпозиционным методом

3.1.1 Построение универсального отношения

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

3.1.3 Получение нормализованного набора отношений из минимального покрытия

3.2 Проектирование с использованием ER-метода

3.2.1 Определение сущностей и связей между ними

3.2.2 Построение ER-диаграмм

3.2.3 Построение набора предварительных отношений

3.2.4 Распределение оставшихся атрибутов по полученным отношениям

3.2.5 Проверка нахождения полученных отношений в НФБК

3.3 Проверка отношений на завершающей фазе проектирования

3.4 Составление модели базы данных

3.5 Расчёт требуемой памяти для размещения данных БД

4. ВЫБОР СУБД

5. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5.1 Создание таблиц

5.2 Разработка экранных форм

5.3 Создание запросов

5.4 Создание макросов

5.5 Создание отчетов

6. ИНСТРУКЦИЯ ПОЛЬЗОВАТЕЛЯ Заключение Литература ПРИЛОЖЕНИЕ программное обеспечение база данных перевозка

1. ВВЕДЕНИЕ

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

В ходе выполнения курсовой работы должны быть решены следующие задачи:

— системный анализ предметной области;

— проектирование базы данных;

— выбор системы управления базой данных;

— разработка программного обеспечения.

Заданием данной курсовой работы является разработка автоматизированной информационной системы учёта деятельности службы такси.

База данных должна содержать информацию о диспетчерах, занимающихся распределением заявок; водителях, обслуживающих клиентов. При этом необходимо вести учет количества заявок принятых диспетчером и количества заявок выполненных водителем с указанием тарифа, времени начала работы; принадлежащих водителям автомобилей и их технических данных; используемых раций и их характеристик.

Проектирование произвести с помощью декомпозиционного и ER-методов.

2. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

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

Далее приведём атрибуты и обозначения атрибутов, которые будут использоваться при создании данной БД.

Водитель характеризуется следующими сведениями:

§ Табельный номер (Таб№)

§ Позывной водителя (Позывной)

§ Регистрационный номер автомобиля (Рег№)

§ Номер рации (№Рац)

§ Место стоянки (МС)

§ Состояние водителя (Сост)

§ Время выхода в эфир (ВрВыхЭ)

Регистрационный номер автомобиля определяет:

§ Номер двигателя (№Дв)

§ Номер кузова (№Куз)

§ Цвет автомобиля (Цвет)

§ Марка автомобиля (Марка)

§ Место регистрации автомобиля (МРег)

Марка автомобиля определяет:

§ Расход топлива (РасТоп)

§ Количество мест в салоне (КолМест)

Табельный номер водителя определяет его следующие данные:

§ Фамилия водителя (ФВод)

§ Имя водителя (ИВод)

§ Отчество водителя (ОВод)

§ Домашний адрес водителя (АдрВод)

§ Домашний телефон водителя (ДомТелВод)

§ Мобильный телефон (МТел)

§ Дата рождения водителя (ДРождВод)

§ Дата приёма на работу водителя (ДПрВод)

Номер рации характеризуется следующими параметрами:

§ Используемый канал (ИспКан)

§ Радиус действия (РДейст)

§ Количество часов в эфире (КолЧЭ)

Дата смены определяет:

§ Рабочее имя диспетчера, работающего в это смену (РИДисп)

§ Дата заявки (ДЗ)

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

§ Фамилия диспетчера (ФДисп)

§ Имя диспетчера (ИДисп)

§ Отчество диспетчера (ОДисп)

§ Домашний адрес диспетчера (АдрДисп)

§ Домашний телефон диспетчера (ДомТелДисп)

§ Дата рождения диспетчера (ДРождДисп)

§ Дата приёма на работу диспетчера (ДПрДисп)

Заявка характеризуется следующими данными:

§ Позывной (Позывной)

§ Номер заявки (№Заявки)

§ Время заявки (ВрЗаявки)

§ Дата заявки (ДатаЗаявки)

§ Пункт отправления (ПО)

§ Пункт назначения (ПН)

§ Телефонный номер клиента (ТелКл)

§ Код тарифа (КодТар)

Код тарифа определяет следующие данные:

§ Район отправления (РайО)

§ Район назначения (РайН)

§ Тариф (Тариф) Предусмотрим следующие ограничения на информацию в системе:

1. Программа должна предотвращать появление «пустых» значений;

2. Предотвратить ввод значений в подчиненной таблице, которые отсутствуют в главной, удаления значений в главной таблице, если есть связанные записи. Обеспечить безошибочный и обязательный ввод данных при своевременной подсказке оператору о происхождении ошибки;

3. Заработная плата водителя в сутки определяется с учетом вычета 20% от общей суммы диспетчеру и 5% за прокат рации;

4. Заработная плата диспетчеру в сутки начисляется размером в 10% от общей прибыли.

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

6. Данные заполняются диспетчером по мере поступления заявок.

При работе с базой данных администратор должен иметь возможность решать следующие задачи:

1. Вносить и изменять данные о водителях.

2. Вносить и изменять данные о диспетчерах.

3. Вносить и изменять данные о заявках.

4. Вносить и изменять данные о марке автомобиля, регистрационные данные и характеристики автомобиля.

5. Вносить и изменять данные о типах и характеристиках раций.

6. Вносить и изменять данные о тарифах

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

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

9. Получать информацию о суточной заработной плате водителей и диспетчеров.

10.Получать информацию о числящихся водителях в компании.

Данную базу данных ведут администратор и диспетчер.

Администратор имеет возможность добавлять/изменять данные о водителях, диспетчерах.

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

Заявку получает водитель, место стоянки которого будет ближайшим к месту отправления, в соответствии с очередью.

В данной базе данных будет храниться следующее количество данных:

§ 50 водителей

§ 6 диспетчеров

§ 15 мест стоянок

§ 20 кодов тарифа

§ 1000 заявок в день

§ 3 типа рации

§ 5 марок автомобилей

3. ПРОЕКТИРОВАНИЕ БАЗЫ ДАННЫХ

3.1 Проектирование декомпозиционным методом

3.1.1 Построение универсального отношения

Универсальное отношение есть такое отношение, в котором каждый элемент кортежа имеет атомарное значение. Атомарным называется неделимое значение, а не множество значений.

Составим универсальное отношение таблица 1.

Таблица 1.

Продолжение табл.1

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

Проведём анализ атрибутов, которые должны храниться в базе данных:

Позывной — позывной водителя. Каждый водитель имеет только один позывной, один и тот же позывной не могут иметь несколько водителей. Позывной уникален для каждого водителя.

Таб№ - табельный номер водителя. Целое значение, являющееся уникальным для личных данных каждого водителя.

ФВод — фамилия водителя. Каждый водитель имеет только одну фамилию, но возможно, что одну и ту же фамилию имеют несколько водителей.

ИВод — имя водителя. Каждый водитель имеет только одно имя, но возможно, что одно и то же имя имеют несколько водителей.

ОВод — отчество водителя. Каждый водитель имеет только одно отчество, но возможно, что одно и то же отчество имеют несколько водителей.

АдрВод — домашний адрес водителя. Каждый водитель может иметь только один домашний адрес, но по одному и тому же адресу могут проживать несколько водителей.

ДомТелВод — домашний телефон водителя. Каждый водитель может иметь только один номер телефона, но один и тот же номер телефона могут иметь несколько водителей.

МТел — мобильный телефон водителя. Каждый водитель может иметь несколько мобильных номеров телефона, но один и тот же мобильный номер телефона не может одновременно принадлежать нескольким водителям.

ДРождВод — дата рождения водителя. Водитель может иметь только одну дату рождения, но эту дату рождения могут иметь несколько водителей.

ДПрВод — дата приема на работу водителя. Водитель может иметь только одну дату приема, но такую же дату приема могут иметь несколько водителей.

МС — место стоянки. Каждый водитель в одно и то же время может иметь только одно место стоянки, но в это же время на одном и том же месте могут находиться несколько водителей.

ВрВыхЭ — время выхода в эфир. Каждый водитель имеет своё время выхода рации в эфир, соответствующее времени включения рации, но одно и то же время выхода в эфир могут иметь несколько водителей.

№Рац — номер рации. Каждая рация может иметь только один номер рации, являющийся уникальным для характеристик рации.

ИспКан — используемый канал. Каждый водитель имеет возможность пользоваться только одним каналом рации, но на одном и том же канале находится определённое количество водителей.

РДейст — радиус действия рации. Каждая рация имеет свой радиус действия, но один и тот же радиус действия могут иметь несколько раций.

КолЧЭ — количество часов в эфире. Каждая рация может работать только определённое количество часов без подзарядки, но одно и то же количество часов может иметь несколько раций.

Сост — состояние водителя. В один момент времени водитель может иметь только одно состояние (занят/свободен), но в этот же момент времени в таком же состоянии могут находиться несколько водителей.

Рег№ - регистрационный номер автомобиля. Каждый автомобиль имеет свой регистрационный номер, являющийся уникальным для характеристик автомобиля.

№Дв — номер двигателя. Каждый автомобиль имеет только один номер двигателя.

№Куз — номер кузова. Каждый автомобиль имеет только один номер кузова.

МРег — место регистрации. Каждый автомобиль имеет только одно место регистрации, но такое же место регистрации могут иметь несколько автомобилей.

Марка — марка автомобиля. Каждый автомобиль имеет только одну марку, но одну и ту же марку могут иметь несколько автомобилей.

РасТоп — расход топлива. У каждой марки автомобиля есть свой расход топлива, но такой же расход могут иметь другие автомобили.

КолМест — количество мест в салоне. У каждой марки автомобиля есть своё количество мест, но такое же количество мест могут иметь и другие марки автомобилей.

Цвет — цвет автомобиля. Каждый автомобиль имеет свой цвет, но такой же цвет могут иметь и другие автомобили.

ДатаЗаявки — дата заявки. Каждая заявка имеет свою дату приёма, но такую же дату приема могут иметь и другие заявки.

ВремяЗаявки — время заявки. Каждая заявка имеет своё время приёма, но такое же время приема могут иметь заявки, полученные в другой день.

№Заявки — номер заявки. Каждая заявка имеет свой номер, но один и тот же номер могут иметь заявки, принятые в разные дни.

ПО — пункт отправления. Каждая заявка имеет свой пункт отправления, но один и тот же пункт отправления могут иметь и другие заявки.

ПН — пункт назначения. Каждая заявка имеет свой пункт назначения, но этот же пункт назначения могут иметь и другие заявки.

ТелКл — телефонный номер клиента. У каждой заявки есть свой телефонный номер клиента, но этот же телефонный номер может быть и в других заявках.

КодТар — код тарифа. Каждая заявка имеет только один код тарифа, но один и тот же код тарифа могут иметь несколько заявок. Код тарифа является уникальным для тарифа.

РайО — район отправления. У каждой заявки есть свой район отправления, но такой же район отправления могут иметь несколько заявок.

РайН — район назначения. Каждая заявка имеет только один район назначения, но этот же район назначения может быть и в других заявках.

Тариф — тариф. Каждая заявка имеет только один тариф, но этот же тариф могут иметь и другие заявки.

РИДисп — рабочее имя диспетчера. Рабочее имя диспетчера является уникальным для каждого диспетчера.

ФДисп — фамилия диспетчера. Каждый диспетчер имеет только одну фамилию, но возможно, что одну и ту же фамилию имеют несколько диспетчеров.

ИДисп — имя диспетчера. Каждый диспетчер имеет только одно имя, но возможно, что одно и то же имя имеют несколько диспетчеров.

ОДисп — отчество диспетчера. Каждый диспетчер имеет только одно отчество, но возможно, что одно и то же отчество имеют несколько диспетчеров.

АдрДисп — домашний адрес диспетчера. Каждый диспетчер имеет свой адрес, но по одному и тому же адресу могут проживать несколько диспетчеров.

ДомТелДисп — домашний телефон диспетчера. Каждый диспетчер имеет свой номер домашнего телефона, но один и тот же номер телефона могут иметь несколько диспетчеров.

ДРождДисп — дата рождения диспетчера. Диспетчер может иметь только одну дату рождения, но эту дату рождения могут иметь несколько диспетчеров.

ДПрДисп — дата приема на работу диспетчера. Диспетчер может иметь только одну дату приема, но такую же дату приема могут иметь несколько диспетчеров.

На основе проведенного анализа определим функциональные зависимости, существующие между атрибутами, и изобразим диаграмму ФЗ.

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

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

3. Номер рации является уникальным, то есть по нему можно определить характеристики рации: используемый канал радиосвязи, радиус действия, количество часов в эфире.

4. Регистрационный номер автомобиля является уникальным для каждого автомобиля. Зная регистрационный номер автомобиля, мы можем определить: марку, номер двигателя, номер кузова, место регистрации, цвет.

5. Зная марку можно определить расход топлива и количество мест в салоне.

6. Код тарифа является уникальным, то есть, зная код тарифа, мы можем определить район отправления, район назначения и тариф.

7. Зная текущую дату и время можно определить рабочее имя диспетчера, работающего в эту смену.

8. Рабочее имя диспетчера является уникальным, то есть по нему можно определить данные диспетчера: ФИО диспетчера, домашний телефон диспетчера и т. д.

C учетом проведенного анализа диаграмма ФЗ имеет вид:

рис. 1 Диаграмма ФЗ

В рассматриваемой задаче избыточные ФЗ отсутствуют.

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

3.1.3 Получение нормализованного набора отношений из минимального покрытия

Определим возможные ключи и детерминанты рассматриваемого универсального отношения (при отсутствии избыточных ФЗ).

Учитывая, что не каждый первичный ключ является детерминантом, рассматриваемое универсальное отношение не находится в нормальной форме Бойса — Кодда (НФБК), требуется декомпозиция отношений.

Для декомпозиции по правилу цепочек выделяем ФЗ следующего вида:

В результате получим два отношения:

Марка (Марка, РасТоп, КолМест)

R1 (№Заявки, ДатаЗаявки, ВремяЗаявки, Позывной, ПО, ПН, ТелКл, КодТар, РИДисп, Рег№, МС, №Рац, ВрВыхЭ, Сост, Таб№, РайО, РайН, Тариф, ФДисп, ИДисп, ОДисп, АдрДисп, ДомТелДисп, ДРождДисп, ДПрДисп, Марка, Цвет, №Дв, №Куз, МРег, ИспКан, РДейст, КолЧЭ, ФВод, ИВод, ОВод, АдрВод, ДомТелВод, МТел, ДРождВод, ДПрВод)

В отношении Марка первичный ключ Марка является возможным ключом и детерминантом, следовательно, оно находится в НФБК и дальнейшей декомпозиции не требует.

Рассмотрим оставшееся отношение R1, представленное на рис. 2.

рис. 2 Диаграмма ФЗ

Отношение R1 не находится в НФБК, и требуется его дальнейшая декомпозиция.

Для декомпозиции по правилу цепочек выделяем ФЗ следующего вида:

В результате получим два отношения:

ТехДанные (Рег№, Марка, Цвет, №Дв, №Куз, МРег)

R2 (№Заявки, ДатаЗаявки, ВремяЗаявки, Позывной, ПО, ПН, ТелКл, КодТар, РИДисп, Рег№, МС, №Рац, ВрВыхЭ, Сост, Таб№, РайО, РайН, Тариф, ФДисп, ИДисп, ОДисп, АдрДисп, ДомТелДисп, ДРождДисп, ДПрДисп, ИспКан, РДейст, КолЧЭ, ФВод, ИВод, ОВод, АдрВод, ДомТелВод, МТел, ДРождВод, ДПрВод)

В отношении ТехДанные первичный ключ Рег№ является возможным ключом и детерминантом, следовательно, оно находится в НФБК и дальнейшей декомпозиции не требует.

Рассмотрим отношение R2, представленное на рис.3:

рис. 3 Диаграмма ФЗ

Т.е. отношение R2 не находится в НФБК, и требуется его дальнейшая декомпозиция.

Для декомпозиции по правилу цепочек выделяем ФЗ следующего вида:

В результате получим 2 отношения:

Рация (№Рац, ИспКан, РДейст, КолЧЭ).

R3 (№Заявки, ДатаЗаявки, ВремяЗаявки, Позывной, ПО, ПН, ТелКл, КодТар, РИДисп, Рег№, МС, №Рац, ВрВыхЭ, Сост, Таб№, РайО, РайН, Тариф, ФДисп, ИДисп, ОДисп, АдрДисп, ДомТелДисп, ДРождДисп, ДПрДисп, ФВод, ИВод, ОВод, АдрВод, ДомТелВод, МТел, ДРождВод, ДПрВод) В отношении Рация первичный ключ №Рац является возможным ключом и детерминантом, следовательно, оно находится в НФБК и дальнейшей декомпозиции не требует.

Рассмотрим отношение R3, представленное на рис.4:

рис. 4 Диаграмма ФЗ

Т.е. отношение R3 не находится в НФБК, и требуется его дальнейшая декомпозиция.

Для декомпозиции по правилу цепочек выделяем ФЗ следующего вида:

В результате получим 2 отношения:

Характеристики_Водителя (Таб№, ФВод, ИВод, ОВод, АдрВод, ДомТелВод, МТел, ДРождВод, ДПрВод).

R4 (№Заявки, ДатаЗаявки, ВремяЗаявки, Позывной, ПО, ПН, ТелКл, КодТар, РИДисп, Рег№, МС, №Рац, ВрВыхЭ, Сост, Таб№, РайО, РайН, Тариф, ФДисп, ИДисп, ОДисп, АдрДисп, ДомТелДисп, ДРождДисп, ДПрДисп)

В отношении Характеристики_Водителя первичный ключ Таб№ является возможным ключом и детерминантом, следовательно, оно находится в НФБК и дальнейшей декомпозиции не требует.

Рассмотрим отношение R4, представленное на рис.5:

рис. 5 Диаграмма ФЗ

Выделяем ФЗ следующего вида:

В результате получим 2 отношения:

Характеристики_Диспетчера (РИДисп, ФДисп, ИДисп, ОДисп, АдрДисп, ДомТелДисп, ДРождДисп, ДПрДисп).

R5 (№Заявки, ДатаЗаявки, ВремяЗаявки, Позывной, ПО, ПН, ТелКл, КодТар, РИДисп, Рег№, МС, №Рац, ВрВыхЭ, Сост, Таб№, РайО, РайН, Тариф)

В отношении Характеристики_Диспетчера первичный ключ РИДисп является возможным ключом и детерминантом, следовательно, оно находится в НФБК и дальнейшей декомпозиции не требует.

Рассмотрим отношение R5, представленное на рис.6:

рис. 6 Диаграмма ФЗ

Т.е. отношение R5 не находится в НФБК, и требуется его дальнейшая декомпозиция.

Для декомпозиции по правилу цепочек выделяем ФЗ следующего вида:

Диспетчер (ДатаЗаявки, РИДисп).

R6 (№Заявки, ДатаЗаявки, ВремяЗаявки, Позывной, ПО, ПН, ТелКл, КодТар, Рег№, МС, №Рац, ВрВыхЭ, Сост, Таб№)

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

Рассмотрим отношение R6, представленное на рис.7:

рис. 7 Диаграмма ФЗ

Т.е. отношение R6 не находится в НФБК, и требуется его дальнейшая декомпозиция.

Для декомпозиции по правилу цепочек выделяем ФЗ следующего вида:

В результате получим 2 отношения:

Тариф (КодТар, РайО, РайН, Тариф).

R7 (№Заявки, ДатаЗаявки, ВремяЗаявки, Позывной, ПО, ПН, ТелКл, КодТар, Рег№, МС, №Рац, ВрВыхЭ, Сост, Таб№)

В отношении Тариф первичный ключ КодТар является возможным ключом и детерминантом, следовательно, оно находится в НФБК и дальнейшей декомпозиции не требует.

Рассмотрим отношение R7, представленное на рис 8:

рис.8 Диаграмма ФЗ

Т.е. отношение R7 не находится в НФБК, и требуется его дальнейшая декомпозиция.

Для декомпозиции по правилу цепочек выделяем ФЗ следующего вида:

В результате получим 2 отношения:

Водитель: (Позывной, Рег№, МС, №Рац, ВрВыхЭ, Сост, Таб№).

R8: (№Заявки, ДатаЗаявки, ВремяЗаявки, Позывной, ПО, ПН, ТелКл, КодТар) В отношении Водитель первичный ключ Позывной является возможным ключом и детерминантом, следовательно, оно находится в НФБК и дальнейшей декомпозиции не требует.

Рассмотрим отношение R8, представленное на рис.9:

рис.9 Диаграмма ФЗ

В отношении R8 набор атрибутов (№Заявки, ДатаЗаявки, ВремяЗаявки) является возможным ключом и детерминантом, следовательно, оно находится в НФБК и дальнейшей декомпозиции не требует. Назовем отношение R8 Заявка, тогда получим отношение вида:

Заявка: (№Заявки, ДатаЗаявки, ВремяЗаявки, Позывной, ПО, ПН, ТелКл, КодТар)

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

Распределим атрибуты универсального отношения по полученным нормализованным отношениям.

Водитель

Характеристики_Водителя

ТехДанные

Марка

Рация

Заявка

Тариф

Диспетчер

Характеристики_Диспетчера

3.2 Проектирование с использованием ER-метода

3.2.1 Определение сущностей и связей между ними

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

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

Сущностями в данном случае являются Водитель, Диспетчер, Автомобиль, ТехДанные, Заявка, Характеристики_Водителя, Характеристики_Диспетчера, Рация.

Сущности Водитель и Заявка связаны связью Получает.

Сущности Заявка и Тариф связаны связью Назначается.

Сущности Водитель и Автомобиль связаны связью Имеет.

Сущности Автомобиль и ТехДанные связаны связью Имеет.

Сущности Диспетчер и Заявка связаны связью Принимает.

Сущности Водитель и Рация связаны связью Использует.

Сущности Водитель и Характеристики_Водителя связаны связью Имеет. Сущности Диспетчер и Характеристики_Диспетчера связаны связью Имеет.

3.2.2 Построение ER-диаграмм

Составим диаграмму ER-экземпляров:

рис. 10 Диаграмма ER-экземпляров

Каждый водитель имеет свой автомобиль, и каждый автомобиль принадлежит только одному водителю. Т. е. между сущностями Водитель и автомобиль степень связи 1:1. Класс принадлежности сущностей Водитель и Автомобиль обязательный.

У каждого водителя есть свои характеристики, но одни и те же характеристики могут иметь несколько водителей. Т. е. между сущностями Водитель и Характеристики водителя степень связи N:1. Класс принадлежности сущности Водитель обязательный, а сущности Характеристики водителя — необязательный.

У каждого автомобиля есть свои характеристики, но одни и те же характеристики могут иметь несколько автомобилей. Т. е. между сущностями Автомобиль и Технические данные степень связи N:1. Класс принадлежности сущности Автомобиль обязательный, а сущности Технические данные — необязательный.

У каждого водителя есть рация, с которой он работает, но в данный момент времени одна и та же рация может находиться только у одного водителя. Т. е. между сущностями Водитель и Рация степень связи 1:1. Класс принадлежности сущности Водитель обязательный, а сущности Рация — необязательный.

Каждый водитель получает заявку, и каждая заявка должна быть получена водителем. Т. е. между сущностями Водитель и Заявка степень связи 1: N. Класс принадлежности сущностей Водитель и Заявка обязательный.

Каждый диспетчер принимает заявку, и каждая заявка должна быть принята диспетчером. Т. е. между сущностями Диспетчер и Заявка степень связи 1: N. Класс принадлежности сущностей Диспетчер и Заявка обязательный.

У каждого диспетчера есть свои характеристики, но одни и те же характеристики могут иметь несколько диспетчеров. Т. е. между сущностями Диспетчер и Характеристики диспетчера степень связи N:1. Класс принадлежности сущности Диспетчер обязательный, а сущности Характеристики диспетчерf — необязательный.

Каждой заявке назначается только один тариф, но один и тот же тариф может назначаться нескольким заявкам. Т. е. между сущностями Заявка и Тариф степень связи N:1. Класс принадлежности сущности Заявка обязательный, а сущности Тариф — необязательный.

Составим диаграмму ER-типа, представленную на рис. 11:

рис. 11 Диаграмма ER-типа

Здесь ключами сущностей являются: Позыв, Рег№, Марка, №Заявки, ДатаЗаявки, ВремяЗаявки, РИДисп, КодТар, №Рац, Таб№.

3.2.3 Построение набора предварительных отношений

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

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

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

В соответствии с пятым правилом получения отношений из диаграмм ER-типа — для связей, где степень бинарной связи равна 1: N и класс принадлежности N-связной сущности является необязательным, необходимо формирование трех отношений: по одному для каждой сущности, причем ключ каждой сущности служит первичным ключом соответствующего отношения, и одного отношения для связи.

Получаем пятнадцать предварительных отношений следующего вида:

Рация (№Рац, …)

ВодРац (Позывной, №Рац…)

ХарВодителя (Таб№, …)

В_Х (Позыв, Таб№, …)

Водитель (Рег№,…)

Марка (Марка, …)

ТехДанные (Рег№, Марка…)

Заявка (№Заявки, …)

З_В (Позыв, №Заявки…)

Тариф (КодТар, …)

З_Тариф (№Заявки, КодТар, …)

Диспетчер (ДатаЗаявки, …)

З_Д (№Заявки, ДатаЗаявки, …)

ХарДисп (РИДисп, …)

Д_ХарДисп (ДатаЗаявки, РИДисп, …)

Повторяющихся отношений нет.

Объединим следующие отношения:

Заявка (№Заявки, …)

З_В (Позыв, №Заявки…) Заявка (№Заявки, Позывной, ДатаЗаявки, КодТар…),

З_Тариф (№Заявки, КодТар, …)

З_Д (№Заявки, ДатаЗаявки, …)

ВодРац (Позывной, №Рац, …)

В_Х (Позывной, Таб№, …) Водитель (Позывной, №Рац, Рег№, Таб№…)

Водитель (Рег№, …)

Диспетчер (ДатаЗаявки, …)

Д_ХарДисп (ДатаЗаявки, РИДисп, …) Диспетчер (ДатаЗаявки, РИДисп) После объединения получили следующие отношения:

Марка (Марка,…)

ТехДанные (Рег№, Марка…)

Рация (№Рац, …)

Характеристики_Водителя (Таб№, …)

Характеристики_Диспетчера (РИДисп, …)

Диспетчер (ДатаЗаявки, РИДисп).

Тариф (КодТар, …).

Водитель (Позывной, №Рац, Рег№, Таб№…)

Заявка (№Заявки, Позывной, ДатаЗаявки, КодТар…)

3.2.4 Распределение оставшихся атрибутов по полученным отношениям

Марка (Марка, РасТоп, КолМест)

ТехДанные (Рег№, Марка, Цвет, №Дв, №Куз, МРег)

Рация (№Рац, ИспКан, РДейст, КолЧЭ).

Характеристики_Водителя (Таб№,, ФВод, ИВод, ОВод, АдрВод, ДомТелВод, МТел, ДРождВод, ДПрВод).

Характеристики_Диспетчера (РИДисп, ФДисп, ИДисп, ОДисп, АдрДисп, ДомТелДисп, ДРождДисп, ДПрДисп).

Диспетчер (ДатаЗаявки, ВремяЗаявки, КолЗД, РИДисп).

Тариф (КодТар, РайО, РайН, Тариф).

Водитель: (Позывной, Рег№, МС, №Рац, ВрВыхЭ, Сост, Таб№).

Заявка: (№Заявки, ДатаЗаявки, ВремяЗаявки, Позывной, ПО, ПН, ТелКл, КодТар)

3.2.5 Проверка нахождения полученных отношений в НФБК

Полученные отношения необходимо проверить на нахождение в НФБК. Для этого надо построить диаграммы ФЗ.

Диаграмма ФЗ для отношения Марка:

Рис. 12 Диаграмма ФЗ отношения Марка.

По данной диаграмме видно, что Марка является первичным ключом и детерминантом. Следовательно, данное отношение находится в НФБК.

Аналогично рассматривая остальные предварительные отношения, можно легко убедиться в том, что и они находятся в нормальной форме Бойса — Кодда, так как возможный ключ любого из данных отношений полностью совпадает с его детерминантом.

Диаграмма ФЗ для отношения Рация

Рис.13 Диаграмма ФЗ отношения Рация

Диаграмма ФЗ для отношения Технические Данные

Рис.14 Диаграмма ФЗ отношения Технические Данные

Диаграмма ФЗ для отношения Характеристики_Водителя

Рис.15 Диаграмма ФЗ отношения Характеристики_Водителя

Диаграмма ФЗ для отношения Характеристики_Диспетчера

Рис.16 Диаграмма ФЗ отношения Характеристики_Диспетчера

Диаграмма ФЗ для отношения Диспетчер

Рис.17 Диаграмма ФЗ отношения Диспетчер

Диаграмма ФЗ для отношения Тариф

Рис.18 Диаграмма ФЗ отношения Тариф

Диаграмма ФЗ для отношения Водитель

Рис.19 Диаграмма ФЗ отношения Водитель

Диаграмма ФЗ для отношения Заявка

Рис.20 Диаграмма ФЗ отношения Заявка

3.3 Проверка отношений на завершающей фазе проектирования

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

3.4 Составление модели базы данных

3.5 Расчёт требуемой памяти для размещения данных БД

По составленной модели базы данных рассчитаем объём требуемой памяти для размещения данных в отношениях:

Отношение Водители:

Количество записей: 50

Объём каждой записи: 10+12+20+4+1+1+2=50Б

Отношение Характеристики_Водителя:

Количество записей: 50

Объём каждой записи: 2+15+10+15+14+6+11+8+8=89Б

Отношение ТехДанные

Количество записей: 50

Объём каждой записи: 12+15+15+4+4+50=100Б

Отношение Марка

Количество записей: 5

Объём каждой записи: 15+1+1=17Б

Отношение Характеристики_Диспетчера:

Количество записей: 6

Объём каждой записи: 6+15+10+15+14+6+8+8=82Б

Отношение Заявка:

Количество записей: 1000

Объём каждой записи: 8+2+10+14+14+11+8+2=69Б

Отношение Рация:

Количество записей: 50

Объём каждой записи: 4+1+4+1=10Б

Отношение Тариф:

Количество записей: 20

Объём каждой записи: 2+14+14+8=38Б

Отношение Диспетчер:

Количество записей: 6

Объём каждой записи: 8+6=14Б

Суммарный объём памяти для хранения всех данных составит: 80.93 кБ.

4. ВЫБОР СУБД

При выборе СУБД учитываются различные факторы, среди которых могут быть следующие:

— требуемые оперативная и дисковая память;

— трудоемкость разработки программ;

— стоимость эксплуатации;

— совместимость разрабатываемой БД с существующими на предприятии;

— сроки разработки системы;

— затраты на обучение персонала и т. д.

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

В данном курсовом проекте использовалась версия Access 2003.

СУБД Access входит в состав пакета Microsoft Office и хорошо интегрирована с другими программными продуктами фирмы Microsoft. Кроме того, она хорошо зарекомендовала себя при использовании в сети. Программа имеет подробную встроенную документацию, продуманный интуитивный интерфейс, поддержку языка запросов SQL, а также встроенный язык программирования (VBA) и получила широкое распространение среди пользователей ОС Windows.

Access 2003 предлагает универсальный набор программных средств, которые обеспечивают широкие возможности для профессиональных разработчиков и вместе с тем могут быть легко освоены новичками.

Access 2003 поддерживает различные форматы данных, в том числе XML, OLE, ODBC и формат служб Microsoft Windows® SharePoint™ Services. Можно связать таблицы таким образом, чтобы одновременно получать доступ к данным из различных баз, работая с формами, отчетами и страницами доступа к данным в Access 2003. Кроме того, можно связывать таблицы из других баз данных Access, электронных таблиц Microsoft Excel, источников данных ODBC, баз данных Microsoft SQL Server™ и других источников. Можно включить данные Microsoft SQL Server в решения Access, используя конструктор сохраненных процедур для создания и изменения простых процедур, сохраняемых в SQL Server.

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

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

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

Мощные функции анализа данных. Можно перетаскивать элементы управления в форму Access для создания сводной таблицы Microsoft PivotTable®, сводной диаграммы Microsoft PivotChart® или электронной таблицы.

Простота архивирования данных. Access 2003 позволяет сохранить в другом месте копию базы данных, с которой вы работаете.

Необходимая помощь. Из областей задач «Приступая к работе» и «Справка» можно получить доступ к службе поддержки Microsoft Office Online Assistance на веб-узле Microsoft Office Online, где публикуются справочные материалы и статьи, которые регулярно обновляются на основе вопросов пользователей. Для использования некоторых функций этих областей задач требуется подключение к Интернету.

Создание форм и отчетов, которые можно сохранять в предыдущих версиях Access, значительно упрощает совместное использование данных.

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

5. РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

5.1 Создание таблиц

Сначала в режиме конструктора создаются пустые таблицы, соответствующие отношениям, полученным в результате проектирования. В качестве полей в этих таблицах указываются атрибуты этих отношений. Типы данных и имена полей такие же, как в модели данных. Здесь же задаем ограничения на ввод соответствующих значений, и индексы уникальности записей, если необходимо. Необходимо учесть параметр «обязательное поле» для всех реквизитов для контроля безошибочного ввода данных.

В данной базе данных, реализованной в Access, содержится 9 таблиц: «Водитель», «Диспетчер», «Заявка», «Марка», «Рация», «ТехДанные», «Тариф», «Характеристики_Водителя», «Характеристики_Диспетчера. По вкладке Сервис меню открываем окно схемы данных. При помощи правой кнопки мыши добавляем в окно все созданные таблицы. Связи между таблицами должны дублировать связи между отношениями в модели данных.

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

Для связанных таблиц в целях упрощения и контроля вводимых данных для связанных таблиц необходимо предусмотреть параметр «подстановка» данных из главных таблиц.

Рис.21 Схема данных

5.2 Разработка экранных форм

Для удобства заполнения нормативной базы данных с помощью мастера форм создаем для каждого из созданных отношений соответствующую форму. Отношения «ТехДанные» и «Характеристики_Водителя» создаем в виде табличного и ленточного типа подчиненных форм к отношению «Водители», для удобства добавления, изменения технических данных автомобилей, а также характеристик водителя. Для изменения или добавления диспетчера, характеристик диспетчера создаём форму «Диспетчер», и подчиненную «Характеристики диспетчера». Отношение «Тариф» создаём для добавления заявок в отношение «Заявка» через кнопку перехода по формам. Все формы снабжаем необходимыми кнопками для перехода на другие формы для добавления, удаления или изменения введенных данных.

5.3 Создание запросов

В программе реализованы следующие запросы:

1. «ВремяРазрядки» — выводит рации, которые подлежат зарядке.

SELECT Рация.№Рац, Водитель. Позывной, Рация. КолЧЭ, Водитель. ВрВыхЭ, (Time ()-Водитель.ВрВыхЭ) AS РацииЗамена

FROM Рация INNER JOIN Водитель ON Рация.№Рац=Водитель.№Рац

WHERE ((((Time ()-Водитель.ВрВыхЭ))>Рация.КолЧЭ/60));

2. «Вычисление зар. платы диспетчера» — вычисление заработной платы диспетчера:

SELECT Диспетчер. РИДисп, Характеристики_Диспетчера.ФДисп, Характеристики_Диспетчера.ИДисп, Характеристики_Диспетчера.ОДисп, Характеристики_Диспетчера.АдрДисп, Характеристики_Диспетчера.ДомТелДисп, Характеристики_Диспетчера.ДРождДисп, Характеристики_Диспетчера.ДПрДисп, Sum (Тариф.Тариф) AS [Sum-Тариф]

FROM Характеристики_Диспетчера INNER JOIN (Тариф INNER JOIN (Диспетчер INNER JOIN Заявка ON Диспетчер. ДатаЗаявки = Заявка. ДатаЗаявки) ON Тариф. КодТар = Заявка. КодТар) ON Характеристики_Диспетчера.РИДисп = Диспетчер. РИДисп

GROUP BY Диспетчер. РИДисп, Характеристики_Диспетчера.ФДисп, Характеристики_Диспетчера.ИДисп, Характеристики_Диспетчера.ОДисп, Характеристики_Диспетчера.АдрДисп, Характеристики_Диспетчера.ДомТелДисп, Характеристики_Диспетчера.ДРождДисп, Характеристики_Диспетчера.ДПрДисп, Диспетчер. ДатаЗаявки

HAVING (((Диспетчер.ДатаЗаявки)=Date ()));

3. «Вычисление зар. платы Водителя»:

SELECT Запр. Таб№, Характеристики_Водителя.ФВод, Характеристики_Водителя.ИВод, Характеристики_Водителя.ОВод, Запр. Позывной, Sum (Запр.Тариф) AS Зарплата

FROM Запр INNER JOIN Характеристики_Водителя ON Запр. Таб№ = Характеристики_Водителя.Таб№

GROUP BY Запр. Таб№, Характеристики_Водителя.ФВод, Характеристики_Водителя.ИВод, Характеристики_Водителя.ОВод, Запр. Позывной;

4. «Заявки на сегодня» — перечень заявок, принятых на сегодняшний день.

SELECT Count (Заявка.№Заявки) AS [Count-№Заявки], Диспетчер. ДатаЗаявки, Диспетчер. РИДисп

FROM Диспетчер INNER JOIN Заявка ON Диспетчер. ДатаЗаявки = Заявка. ДатаЗаявки

GROUP BY Диспетчер. ДатаЗаявки, Диспетчер. РИДисп

HAVING (((Диспетчер.ДатаЗаявки)=Date ()));

5.4 Создание макросов

Для того чтобы при открытии Access автоматически открывалась база, создаем макрос Autoexec, открывающий Кнопочную форму и присваиваем его событию открытие этой формы. Также при открытии базы данных происходит проверка на разрядку раций. В случае, если есть разряженные рации, то открывается форма «Рации, которые подлежат зарядке».

Макрос под именем «Переходы_по_формам» привязан к соответствующим кнопкам на формах «Рация», «ТехДанные», «ХарВод», «Марка», «ХарДисп», «Тариф», «Заявка» для автоматического перехода по формам.

5.5 Создание отчетов

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

В базе данных создаются 5 вида отчетов:

— «Водители», содержащий информацию о водителях и их характеристиках;

— «Диспетчер», содержащий информацию о диспетчерах и их характеристиках, включая сведения по заработной плате;

— «Зарплата Водителя», содержащий сведения водителя и начисляемой ему заработной плате;

— «Рация», содержащий характеристики используемой рации.

— «Заявки на сегодня», содержащий сведения о принятых заявках на сегодняшний день.

6. ИНСТРУКЦИЯ ПОЛЬЗОВАТЕЛЯ

Для запуска приложения необходимо запустить файл «Служба такси.mdb». При запуске приложения перед пользователем сразу появляется главная кнопочная форма, которая полностью обеспечивает работу с базой данных. Также при открытии базы данных происходит проверка на разрядку раций. В случае, если есть разряженные рации, то открывается форма «Рации, которые подлежат зарядке».

Рис.22 Главная форма Служба такси

Рис.23Форма Рации, которые нужно заменить

Чтобы внести или изменить информацию о водителях, о диспетчерах и об используемой рации необходимо нажать на кнопку «Для администратора».

Рис.24 Форма Администратор

Нажав на кнопку «ДобавлениеВодителя» можно просмотреть, изменить или добавить информацию о водителе, технических данных, об используемой рации. Это делается в следующей форме:

Рис.25 Форма ДобавлениеВодителя

Здесь же, нажав на кнопку «Добавить/изменить тех данные» можно занести технические данные автомобиля. Так же присутствуют вспомогательные кнопки.

Рис.26 Форма Добавление технических данных автомобиля.

Чтобы внести или изменить информацию о характеристиках водителя, необходимо нажать кнопку «Добавить/Изменить характеристики». Откроется окно «Характеристики Водителя».

Рис.27 Форма Добавление Характеристик водителя

Чтобы внести или изменить информацию об используемой рации нужно щелкнуть по кнопке «ДобавитьРацию», после чего откроется окно «Рация». Здесь можно добавлять и изменять характеристики рации.

Рис.28 Форма Рация

Чтобы внести или изменить информацию о кабелях, необходимо в форме «Администратор», нажать кнопку «Добавление Диспетчера». Откроется окно «Характеристики Диспетчера». Здесь можно добавлять и изменять характеристики диспетчера.

Рис.29 Форма Характеристики Диспетчера

Основная работа пользователей, не вносящих изменений в базу данных, производится в разделе «Для просмотра». Чтобы в нее перейти необходимо нажать на кнопку «Для просмотра» в главной кнопочной форме. В результате появится кнопочная форма:

Рис.30 Форма Просмотр

По кнопке «Водитель» можно получить отчет по числящимся водителям.

Рис.31 Отчет «Водители»

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

Рис.32 Отчет «Зарплата Водителя»

Рис.33Отчет «Зарплата Диспетчера»

Рис.34 Отчет «Заявки на сегодня»

Рис. 35 Отчет «Рация»

Чтобы внести или изменить информацию о заявке кнопку «Для диспетчера». Появится окно «Дата», где необходимо указать Сегодняшнюю дату и рабочее имя диспетчера.

Рис.36 Форма «Дата»

Нажав на кнопку «Далее» появится форма «Заявка», куда можно ввести параметры принятой заявки:

Рис.37 Форма «Заявка»

Заключение

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

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