Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ, МОЛОДЕЖИ И СПОРТА УКРАИНЫ
ДОНЕЦКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ
Д050103.1.01.11/108913.КП
Кафедра программного обеспечения
интеллектуальных систем
Курсовой проект
по дисциплине: «Базы данных»
Тема: «Разработка БД информационной системы службы грузоперевозок»
Руководители:
__________ ас. Ногина Н.В.
(дата, подпись)
__________ ас. Мирошниченко А.М.
(дата, подпись)
Разработал:
____ ст.гр. ПОС-11а М.С.Нечепуренко
(дата, подпись)
Донецк – 2013
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ
ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИНФОРМАТИКИ И ИСКУССТВЕННОГО ИНТЕЛЛЕКТА
Факультет: Современных компьютерных информационных технологий
Кафедра: Программного обеспечения интеллектуальных систем
ЗАДАНИЕ НА КУРСОВОЙ ПРОЕКТ
по дисциплине «Базы даных»
Студенту Нечепуренко Максиму Сергеевичу Группы ПЗС-11а
(фамилия, имя, отчество)
Тема проекта Разработка БД информационной системы службы грузоперевозок
Исходные данные к проекту
Перечень искомых результатов
Рекомендуемая литература
Дата выдачи задания
Дата защиты проекта
Руководитель ас. Ногина Н.В.
(подпись) (должность, Ф.И.О.)
ас. Мирошниченко А.М.
(подпись) (должность, Ф.И.О.)
Разработчик
(подпись)
|
РЕФЕРАТ Пояснительная записка: ?? с.,?? диаграмм, ?? источника, ?? таблицы, ?? прил. Объектом разработки является БД информационной системы службы грузоперевозок. |
||||||||
|
Д050103.1.01.11/108913.КП |
||||||||
|
Фамилия |
Подпись |
Дата |
||||||
|
Разработал |
Нечепуренко М.С. |
Разработка БД информационной системы службы грузоперевозок |
Литера |
Лист |
Листов |
|||
|
Рук. проекта |
Ногина Н.В. |
у |
3 |
43 |
||||
|
Мирошниченко А.М. |
ДонНТУ, каф. ПОИС группа ПОC-11a |
|||||||
|
Н.контроль |
||||||||
|
Зав. каф. |
А.И. Шевченко |
|
|
||||||||||||||||||
|
Разработал |
Фамилия |
Подпись |
Дата |
Д050103.1.01.11/108913.КП |
Лист |
|||||||||||||
|
ст.гр. ПОС-11а |
Нечепуренко М.С |
5 |
||||||||||||||||
ВВЕДЕНИЕ
Объектом исследования процессов данного курсового проекта является служба грузоперевозок. В данной области ведётся работа с большим количеством информации и протекает большое количество процессов. В настоящее время уже используются системы управления процессом грузоперевозок при помощи хранении информации в базах данных. Но такие системы не всегда идеальны и могут не подходить для решения разных проблем. Наша задача состоит в том, чтобы создать такую базу данных, которая будет выполнять поставленные перед ней задачи, иметь удобный интерфейс.
Целью курсового проектирование будет облегчение работы сотрудников службы грузоперевозок при помощи уменьшения времени, затрачиваемой на решения однообразных работ, уменьшения возможности совершения ошибки, организации удобного интерфейса.
1. ФУНКЦИОНИРОВАНИЕ СЛУЖБЫ ГРУЗОПЕРЕВОЗОК «ДОНБАСС»
Предметной областью лабораторной работы является служба грузоперевозок «Донбасс». Необходимо разработать базу данных для данной службы.
Отдел службы находится на территории, содержащей здание, в котором находятся рабочий персонал службы и гаражи, в которых содержатся автомобили. Для заключения договора клиент приходит в здание службы грузоперевозок и обращается к диспетчеру, который знакомится с требованиями клиента. Если служба может удовлетворить запрос клиента, диспетчер заносит данные о клиенте и его заказе в базу. При этом диспетчер знакомит клиента с ценой оплаты перевозки. Если цена не устраивает клиента, то диспетчер предлагает возможные другие варианты, которые могут уменьшить стоимость перевозки за счёт изменения сроков, типов машины для перевозки груза. Стоимость оплаты зависит от массы груза, и времени, затраченного на его перевозку. Клиент может заказать только одну машину. Для заказа ещё одной машины должен заключаться ещё один договор. Перед заключением договора клиент сообщает службе тип груза, его габариты и вес. Служба проверяет базу на наличие машин, свободных вместить данный груз и обеспечить необходимые условия перевозки. Если таковая машина имеется, служба узнаёт у клиента адреса погрузки и разгрузки, чтобы определить расстояние, необходимое для перевозки груза. Возможен такой вариант, что весь груз может не поместить сразу в одну машину. Тогда заключается либо ещё один договор на ещё одну машину, либо одна машина делает несколько ходок. Вычисляется стоимость оплаты в зависимости от расстояния, пройденного машиной, типа и массы груза. Клиент указывает необходимые сроки доставки груза. В это же время в базу вносится дата заключения договора, необходимая дата доставки, тип, габариты, масса груза, километраж, который должна пройти машина, а также номер договора. Клиент оставляет свой адрес, телефон, реквизиты оплаты, ФИО или название организации, заключившей договор. Только после этого договор считается полностью заключённым.
База службы грузоперевозок хранит информацию обо всех машинах, принадлежащих службе грузоперевозок. За каждой машиной закреплён свой водитель. В базе хранится ФИО водителя, закреплённой за машиной, марка машины, его грузоподъёмность, тип погрузки, и максимальные габариты вмещаемого груза.
Также в базе хранится информация о типе груза и его названии для каждого договора.
Затем, согласно договору, необходимо доставить груз в установленные сроки. При прибытии машины по адресу погрузки время прибытия заносится в базу. Тоже самое происходит при прибытии по адресу доставки и разгрузки машины. После чего клиент производит оплату в течение двух дней.
Если служба не успевает выполнить заказ в установленный срок, то клиент может разорвать договор, либо воспользоваться пятидесятипроцентной скидкой на перевозку груза в течение удвоенного срока доставки. Соответствующие изменения данных также вносятся и в базу.
После оплаты клиентом договора, либо его разрывом, договор считается выполненным и хранится в базу в течение 12 месяцев, после чего удаляется из базы.
Служба держит при себе штат водителей. Каждый водитель закреплён за определённой машиной. Водитель может узнать, какие грузы, когда, откуда и куда нужно будет перевозить. В соответствии с ожидаемым расстоянием вычисляются расходы на бензин и водителям выдаются карточки на него.
Также оплачивается работа IT-отдела, который следит за работоспособностью компьютеров, находящихся на территории службы и являющихся её собственностью, а также за работоспособностью базы, обеспечивающей целостность разработанной схемы работы службы. IT - отдел занимается улучшением этой схемы и внедрением в неё новых компонентов.
В конце каждого месяца бухгалтерский отдел службы считает доход службы. Если доход становиться отрицательным, необходимо либо сокращать штат службы, либо переходить на дешёвое топливо для автомобилей.
При выполнении курсового проектирования будет создана база данных для службы грузоперевозок, составлена необходимая документация.
Целью курсового проекта является ознакомление с данной предметной областью, составление диаграмм потоков данных, «сущность-связь», контекстной диаграммы, составление иерархической, реляционной, сетевой модели данных, разработка базы данных для службы грузоперевозок, которая будет выполнять возложенные на неё функции, создание интерфейса для работы с базой.
Задачей курсового проектирования является создание базы данных, которая должна обеспечить удобство пользователю, который будет работать с большим количеством информации. Она должна обеспечивать удобное добавление, удаление данных, поиск среди заданных данных.
База данных должна поддерживать архивацию, восстановление и резервное копирование данных, обеспечивать защиту данных с помощью организации различных уровней доступа. База данных должна составлять отчёты по запросу пользователя. Также БД должна содержать различного рода подсказки и справку.
3. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ СИСТЕМЫ
Концептуальное проектирование систем — начальная стадия проектирования, на которой принимаются определяющие последующий облик решения, и проводится исследование и согласование параметров созданных технических решений с возможной их организацией. При проектировании концептуальной системы мы получим непротиворечивую структурированную интерпретацию реально существующей системы и взаимосвязи её структурных компонентов.
3.1 Инфологическое моделирование предметной области
Инфологическое проектирование — построение семантической модели предметной области наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. В семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLean) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель «сущность-связь», предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны. В настоящий момент не существует единой общепринятой системы обозначений для ER-модели и разные CASE-системы используют разные графические нотации.
В данном курсовом проекте мы рассмотри диаграммы потоков данных и диаграмму «сущность-связь»
3.1.1 Построение диаграммы потоков данных
Диаграммы потоков данных представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Функции, хранилища и внешние сущности на DFD-диаграмме связываются дугами, представляющими потоки данных. Дуги могут разветвляться или сливаться, что означает, соответственно, разделение потока данных на части, либо слияние объектов. При интерпретации DFD-диаграммы используются следующие правила:
Построим DFD диаграмму для данной предметной области (см. рис. 3.1).
Рисунок 3.1- DFD-диаграмма
3.1.2 Построение диаграммы «сущность-связь»
Диаграммы "сущность-связь" (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр.
Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола.
Другими словами, сущности представляют собой базовые типы информации, хранимой в базе данных, а отношения показывают, как эти типы данных взаимоувязаны друг с другом. Введение подобных отношений преследует две основополагающие цели:
• обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);
• использование этой информации различными приложениями.
Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются СВЯЗИ. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности.
Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Практика показала, что для большинства приложений достаточно использовал следующие типы отношений:
На рисунке 3.2 приведена диаграмма «Сущность-связь» для службы грузоперевозок.
Рисунок 3.2 – Диаграмма «Сущность-связь»
Объекты клиент и договор связаны отношением 1: ∞ , так как 1 клиент заключает множество договоров, а 1 договор заключается одним клиентом.
Объекты договор, машина груз связаны отношением ∞:∞:∞, так как 1 договор обслуживает 1 машина, которая перевозит много грузов, 1 машина обслуживает много договоров и перевозит множество грузов, 1 груз перевозит ∞ машина по одному договору.
Объекты категория груза, груз связаны отношением 1:∞, так как 1 груз имеет одну категорию груза, а 1 категорию груза имеют множество грузов.
3.2 Выбор модели представлении данных
3.2.1 Иерархическая модель данных
Иерархическая модель данных — представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.
В основе иерархической модели данных лежит один главный элемент (главный узел), с которого все и начинается, такой элемент называет корневым элементом, в теории графов это называется корнем дерева. Вообще, по сути, что сетевая база данных, что иерархическая база данных имеет древовидную структуру. Все элементы или узлы, которые находятся ниже корневого узла иерархической модели, являются потомками корня. Стоит сказать, что и иерархическая база данных, и сетевая база данных оптимизированы на чтение информации из БД, но не на запись информации в базу данных, эта особенность обусловлена самой моделью данных.
Узлы дерева, которые находятся на одном уровне, обычно называются братьями. Узлы, которые находятся ниже какого-то определенного уровня, являются дочерними узлами по отношению к нему.
К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения операций над данными.
Недостатком иерархической модели является ее громоздкость для обработки информации с достаточно сложными логическими связями.
Иерархическая модель данных для рассматриваемой предметной области приведена на рисунках 3.3, 3.4, 3.5
Клиент
|
ФИО |
Адрес |
Телефон |
Реквизиты |
Договор
|
Выполнение договора |
№ договора |
Дата заключения |
Адрес погрузки |
Адрес разгрузки |
Время погрузки |
Время доставки |
Срок доставки |
Расстояние |
Габариты груза |
Масса груза |
Стоимость |
Машина Груз
|
Наименование груза |
|
ФИО водителя |
Марка |
Грузоподъёмность |
Тип погрузки |
Максимальные габариты |
Рисунок 3.3 – Первый фрагмент иерархической модели данных
Категория груза
|
Название категории груза |
Груз
|
Наименование груза |
Машина
|
ФИО водителя |
Марка |
Грузоподъёмность |
Тип погрузки |
Максимальные габариты |
Договор
|
Выполнение договора |
№ договора |
Дата заключения |
Адрес погрузки |
Адрес разгрузки |
Время погрузки |
Время доставки |
Срок доставки |
Расстояние |
Габариты груза |
Масса груза |
Стоимость |
Рисунок 3.4 – Второй фрагмент иерархической модели данных
Машина
|
ФИО водителя |
Марка |
Грузоподъёмность |
Тип погрузки |
Максимальные габариты |
Груз
|
Наименование груза |
Договор
|
Выполнение договора |
№ договора |
Дата заключения |
Адрес погрузки |
Адрес разгрузки |
Время погрузки |
Время доставки |
Срок доставки |
Расстояние |
Габариты груза |
Масса груза |
Стоимость |
Рисунок 3.5 – Третий фрагмент иерархической модели данных
3.2.2 Сетевая модель данных
Сетевая модель данных - это логическая модель данных, представляющая их сетевыми структурами типов записей и связанные отношениями мощности один-к-одному или один-ко-многим.
Сетевая модель данных определяется в тех же терминах, что и иерархическая. Она состоит из множества записей, которые могут быть владельцами или членами групповых отношений.
Основное различие этих моделей состоит в том, что в сетевой модели запись может быть членом более чем одного группового отношения. Согласно этой модели каждое групповое отношение именуется и проводится различие между его типом и экземпляром. Тип группового отношения задается его именем и определяет свойства общие для всех экземпляров данного типа. Экземпляр группового отношения представляется записью-владельцем и множеством (возможно пустым) подчиненных записей. При этом имеется следующее ограничение: экземпляр записи не может быть членом двух экземпляров групповых отношений одного типа.
Преимущества:
Недостатки:
Сетевая модель данных для данной предметной области приведена на рисунке 3.6.
|
ДОГОВОР |
|||||||||||
|
Выполнение договора |
№ договора |
Дата заключения |
Адрес погрузки |
Адрес разгрузки |
Время погрузки |
Время доставки |
Срок доставки |
Расстояние |
Габариты груза |
Масса груза |
Стоимость |
Заключается
Заключает
Обслуживается
Обслуживает
|
КЛИЕНТ |
|||
|
ФИО |
Адрес |
Телефон |
Реквизиты |
Заказывает
Заказывается
|
МАШИНА |
||||
|
ФИО водителя |
Марка |
Грузоподъёмность |
Тип погрузки |
Максимальные габариты |
|
ГРУЗ |
|
Наименование груза |
Перевозится
Перевозит
|
КАТЕГОРИЯ ГРУЗА |
|
Название категории груза |
Принадлежит к
Включает
Рисунок 3.6. - Сетевая модель данных
3.2.3 Реляционная модель данных
Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение.
Отношение представляет собой множество элементов, называемых кортежами. Наглядной формой представления отношения является привычная для человеческого восприятия двумерная таблица.
Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам – атрибуты отношения.
С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно деление одного объекта (явления, сущности, системы и проч.), информация о котором хранится в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы. При этом каждый из подобъектов имеет одинаковую структуру или свойства, описываемые соответствующими значениями полей записей. Например, таблица может содержать сведения о группе обучаемых, о каждом из которых известны следующие характеристики: фамилия, имя и отчество, пол, возраст и образование. Поскольку в рамках одной таблицы не удается описать более сложные логические структуры данных из предметной области, применяют связывание таблиц.
Физическое размещение данных в реляционных базах на внешних носителях легко осуществляется с помощью обычных файлов.
Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми.
Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
На рисунке 3.7 изображена РМД в виде нескольких таблиц для данной предметной области.
Клиент
|
#КК |
ФИО |
Адрес |
Телефон |
Реквизиты |
|
N |
C64 |
C32 |
N12 |
N20 |
1
Договор
|
#КД |
Дата заключения |
Адрес погрузки |
Адрес разгрузки |
Время погрузки |
Время доставки |
Срок доставки |
Расстояние, км |
Габариты груза |
Масса груза |
KK# |
КВ# |
Выполнение договора |
|
N |
D10 |
C32 |
C32 |
T8 |
T8 |
D10 |
N3 |
C12 |
N4 |
N |
N |
L1 |
∞
∞
1
1
Водитель
|
#КВ |
#КМ |
ФИО водителя |
Грузоподъёмность |
Максимальные габариты |
|
N |
N |
C64 |
N5 |
C12 |
∞
|
#КМ |
Марка |
Тип погрузки |
|
N |
C12 |
C16 |
1∞
Машина
Обслуживание договора
∞
∞
|
КД# |
КГ# |
Кол-во ходок |
Количество грузов |
|
N |
N |
N2 |
N2 |
1∞
Груз
∞
|
#КГ |
Наименование груза |
ККГ# |
|
N |
C16 |
N |
1∞
Категория груза
|
#ККГ |
Название категории груза |
|
N |
C32 |
Рисунок 3.7 – Реляционная модель данных
В полученной РМД каждому объекту диаграммы «Сущность-связь» соответствует таблица. Ключевым полем каждой таблицы является поле, содержащее уникальный ключ, который помечается символом # для наглядности. Таблица «Обслуживание договора» возникла в результате преобразование связи многие ко многим. Таблица «Машина» является справочной таблицей, созданной с целью повышения эффективности работы СБД.
3.3 Нормализация таблиц БД
Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости. Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах.
Существует несколько правил нормализации баз данных. Каждое правило называется «нормальной формой». Если выполняется первое правило, говорят, что база данных представлена в «первой нормальной форме». Если выполняются три первых правила, считается, что база данных представлена в «третьей нормальной форме».
Первая нормальная форма - устраняются повторяющиеся группы в отдельных таблицах, создаётся отдельная таблица для каждого набора связанных данных, идентифицируется каждый набор связанных данных с помощью первичного ключа.
Выполнять нормализацию баз данных до третьей нормальной формы теоретически желательно, но не всегда практично. С теоретической точки зрения нормализация желательна. Однако значительное увеличение числа маленьких таблиц может привести к снижению производительности СУБД или исчерпанию памяти и числа дескрипторов открытых файлов.
Выполнять нормализацию до третьей нормальной формы может быть целесообразно только для часто изменяемых данных. Если при этом сохранятся зависимые поля, спроектируйте приложение так, чтобы при изменении одного из этих полей пользователь должен был проверить все связанные поля.
4.ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СИСТЕМЫ
4.1 Обоснование выбора СУБД
4.2 Описание таблиц
4.3 Проектирование пользовательского интерфейса
4.3.1 Уровни доступа к БД
4.3.2 Модель пользовательского интерфейса
4.4 Описание функционирования приложения
4.5 Взаимодействие компонентов системы
4.6 Комплект поставки и порядок установки системы
Выводы
Перечень ссылок
Приложение А Техническое задание
Приложение Б Основные итоговые документы (отчёты)
Приложение В Листинги и описание программных модулей
Базы данных: модели, разработка, реализация / Т, С. Карпова. — СПб.: Питер,
2001. —304 с.;