Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Бюджетное профессиональное образовательное учреждение Удмуртской Республики

Воткинский машиностроительный техникум имени В.Г. Садовникова

Специальность: 09.02.04

Курсовой проект

По профессиональному модулю ПМ.01 Эксплуатация и модификация информационных систем

Тема:

Проектирование автоматизированного рабочего места диспетчера такси

Разработал Аннюк А.А.

студент группы П-31:

Руководитель Федотов А.Ю.

2020



Оглавление

• Введение
• Цели и задачи
• Теоретическая часть
• 1. Информационная система
• 1.1 Структура информационной системы
• 1.2 Жизненный цикл (ЖЦ) ИС
• 1.3 Техническое задание
• 1.4 Процессы жизненного цикла
• 1.5 Связь между процессами ЖЦ ПП
• 1.6 Качество ИС
• 1.7 Стандартизация и сертификация ИС
• 2. База данных (БД)
• 2.1 Концептуальная схема
• 2.2 Модель “сущность - связь”
• 2.3 CASE-технологии
• 2.4 Внутренняя схема данных
• Практическая часть. Инфологическое проектирование
• 3. Ход работы
• 3.1 Системный анализ
• 3.2 Концептуальная схема
• 3.3 Техническое задание
• 3.4 Разработка интерфейса
• 3.5 Процесс разработки
• 4. Описание логической модели данных
• 4.1 Сущности
• 4.2 Связи между сущностями
• 4.3 Описание пользовательского интерфейса программы
• Заключение
• Список литературы
• Приложение 1. Логическая схема данных
• Приложение 2. Техническое задание



Введение

До появления программ такого типа, все сведения о заказах, водителях и других производственных данных записывались на бумагу и как следствие могли содержать ошибки (неправильный номер дома или улицы, цена заказа и т.д.) или просто потеряться. АРМ диспетчера такси вносит сведения и базу данных о заказах и сотрудниках и может брать оттуда данные о районах, улицах и домах расположенных на этих улицах, что исключает такого рода ошибки. Специальных блок (не во всех программах) рассчитывает расстояние от пункта отправки до пункта назначения и умножает его на стоимость за 1 км, что дает однозначную цену заказа. Еще в некоторые АРМ можно вводить схемы маршрутов, по которым должны двигаться водители (чтобы не дать возможность "левого заработка")

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

Сегодня на рынке существует несколько аналогичных программных продуктов: … Software 123 их программа АРМ диспетчера такси 2.0

F-Groupe Software их программный комплекс "Диспетчер такси"

Fastsoft их программа Диспетчер такси Стандартная версия (1.0.0.0)

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

· Исследовать сферу деятельности таксопарка;

· Проанализировать существующие аналоги автоматизации деятельности диспетчера такси;

· Выбрать СУБД и язык программирования;

· Построить структуру СУБД;

· Согласовать интерфейс с заказчиком;

· Написать программный код;



Цели и задачи

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

· Вычисление полного заказа такси

· Обновление водителя на другой заказ

· Обновление оператора на другой заказ



1. Информационная система

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

Система - это совокупность элементов, объединяющаяся связями между ним, и обладающая определённой целостности.

Автоматизированные системы - это системы, состоящие из персонала, и комплекса средств автоматизации его деятельности, реализующая определённые информационные технологии.

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

1.1 Структура информационной системы

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

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

Функциональные подсистемы. Зависят от особенностей предметной области для которой создаётся ИС. Предназначена для автоматизации задач конкретной предметной области.

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

Метрологическое обеспечение - Это совокупность методов и средств метрологии и инструкции по их применению для всех компонентов ИС.

Эргономическое обеспечение - это совокупность методов и средств по созданию оптимальных условий в рамках ИС.

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

Техническое обеспечение - это комплекс технических средств и документаций, обеспечивающий работу системы.

Математическое обеспечение - это совокупность математических методов, модели и алгоритмов применяемых в ИС.

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

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

Информационное обеспечение (ИО) - совокупность единой системы классификации и кодирования информации, унифицированных систем документации. ИО информационной системы включает в себя 2 комплекса - внемашинное ИО и внутримашинное ИО.

Внемашинное ИО - любую информацию необходимо сначала упорядочить (классифицировать), а затем формализовать (закодировать) с использованием классификаторов.

Система классификации - это совокупность правил распределение объекта множества на подмножества.

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

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

Так же унифицированная система документации является основной компонентой вне машинного ИО.

Основной частью внутри машинного ИО является информационная база. Информационная база может быть организована разными способами: a) Совокупность локальных файлов, которая поддерживается функциональными пакетами прикладных программ. b) Интегрированная база данных + система управления базой данных.

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

· Дублирование данных;

· Возможное несогласованность данных в разных приложениях;

· Не гибкость доступа к информации;

По мимо информационной базы внутри машинное ИО включает в себя: Электронные формы документов при чем появление бумажной формы предполагает только в качестве твёрдой копии документа.

1.1 Жизненный цикл (ЖЦ) ИС

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

1.1.1 Каскадная модель

В настоящее время как правило используют несколько моделей ЖЦ - это каскадная модель, поэтапная (итерационная) модель с промежуточным контролем и модель, обеспечивающаяся меньшую трудоёмкость по сравнению с каскадной моделью (Спиральная модель). Поподробнее мы расскажем про каскадную модель (изображена на рис. 1.1)

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Рис. 1.1 Каскадная модель

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

Достоинство: на каждом этапе формируется законченный набор проектной документации и можно планировать сроки завершения работ и соответственно затраты.

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



1.2 Техническое задание

Техническое задание - это документ, определяющий цели, требования и основные исходные данные необходимые для разработки АИС. Техническое задание создается в соответствии с ГОСТОМ 34.602-89 (Состав и содержание) и ГОСТ 19.201-78 (Техническое задание - требования к оформлению и содержанию).

При разработке технического задания необходимо:

· Устанавливать цель создания ИС, определяющий состав подсистем и функциональные задачи;

· Разработать и обосновать требования предъявляемым подсистемам;

· Разработать и обосновать требования предъявляемыми к информационной базе и обеспечивающим подсистемам;

· Установить общие требования к проектированию системы;

· Определить перечень задач создание системы;

· Определить этапы создания системы и сроки их выполнения;

· Провести предварительный расчёт затрат на создание ИС и определить уровень экономической эффективности её внедрения.

1.3 Процессы жизненного цикла

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

В соответствии с международным стандартом 12207 все процессы ЖЦ подразделяются на 3 группы: Основные, вспомогательные, Организационные.

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

Действия организационных процессов ЖЦ являются: процесс управления (Исполнителем является менеджер), процесс по созданию инфраструктуры, процесс усовершенствования, процесс обучения.

1.4 Связь между процессами ЖЦ ПП

Рис 1.2 Связь между процессами ЖЦ ПП

1.5 Качество ИС

Под качеством ИС понимают совокупность свойств системы, позволяющих их использовать для удовлетворения определений в соответствии с её назначением потребностей. Количественные характеристики этих свойств определяют показатели, которые необходимо контролировать и учитывать. Основными показателями качества ИС является:

· Надёжность;

· Достоверность;

· Безопасность;

· Эффективность;

1.6 Стандартизация и сертификация ИС

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



2. База данных (БД)

БД - это основная часть ИС. Технология БД была разработана для того, чтобы преодолеть недостатки свойственны систем обработки данных.

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

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

Система обработки БД - компоненты системы БД можно представить следующим образом;

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Размещено на http://www.Allbest.Ru/

Рис. 2.1 Система обработки БД

Приложение БД - это совокупность программ, которые служат посредником между пользователем и СУБД.

Форма - это диалоговое окно, предназначенное для взаимодействия пользователя с системой.

Запрос - это специальным образом, оформление требований на выполнение каких - то действий в БД.

Отчёт - это представление данных БД в удобном для анализа виде.

БД хранит данные пользователя, метаданные, метаданные приложения, индексы и реляционные структуры, хранимые процедуры и триггеры.

Триггер - это хранимая процедура, которая запускается при совершении какого - либо события БД.

Функции стандартного интегрированного приложения можно разделить на следующие группы;

· Функции ввода и отображения данных (Презентационная логика);

· Прикладные функции, определяют основные алгоритмы решения задач приложения (Бизнес-логика);

· Функция обработки данных (Логика обработки данных внутри приложения);

Данные, используемые для описания предметной области, представляются в виде трёх схем: внешняя схема, концептуальная схема, внутренняя схема.

Внешняя схема - описывает то, как пользователь БД. Для всех БД, кроме простейших внешняя схема отображает лишь часть реальной БД.

2.1 Концептуальная схема

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

· Может быть построена на основе другой логической модели;

· Не связана с конкретной СУБД

· Объекты данной модели являются сущности и атрибуты;

· Сущности именуются существительным в единственном числе;

2.2 Модель “сущность - связь”

Модель “сущность-связь” представляет собой совокупность понятий и графических символов для построения концептуальной схемы. Сущность - это не что о чём хранится информация. Это множество экземпляров реальных или абстрактных объектов (людей, предметов, событий, идей, состояний и т.д.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен в виде одной сущности, которая должна быть уникальна идентифицирована. При этом имя сущности должно отражать класс объекта, а не конкретный экземпляр.

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

· Иметь уникальное имя с четким смысловым значением;

· Именоваться существительным в единственном числе;

· К одному и тому же имени должна применяться интерпретация;

· Одна и та же интерпретация не может применятся к различным именам только если они не являются псевдонимами;

· Один или не сколько атрибутов, которые принадлежат сущности, либо наследуются через связь;

· Иметь идентификатор экземпляра сущности, который однозначно должен идентифицировать каждый экземпляр сущности.

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

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

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

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

Атрибуты сущности подразделяются;

· Простые - состоящие из одного элемента;

· Композитные (Составные) - состоят из группы атрибутов;

· Многозначные - представляют список значений одного атрибута;

В большинстве версий модели “Сущность-связь” многозначные атрибуты не допускаются и требуется, чтобы многозначные атрибуты были преобразованы в сущность.

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

Модель “сущность-связь” включает в себя классы связей и экземпляр связи.

Число классов сущности, участвовавшие в связях называются степенью связи. Если в связи участвовали два класса сущности, то такая связь называется бинарной. Существует три типа бинарной связи “Один-к-одному”, “Один-ко-многим”, “Многие-ко-многим”. Может существовать связь между сущностями одного и того же класса, такая связь называется рекурсивной.

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

Каждая связь должна именоваться глаголом или глагольным сочетанием.

В стандарте IDEF1X определены четыре типа связи:

· Неидентифицирующая связь принадлежности;

· Идентифицирующая связь принадлежности;

· Категориальная связь;

· Специфическая связь;

Неидетифицирующая связь принадлежности - это связь 1:1 или 1:N между двумя неидентификационно-зависимыми сущностями. Обозначаются пунктирными линиями и отображаются всегда в направлении от родителя к потомку. В случае связи 1:1 необходимо выбрать на роль родителя одну из данных сущностей. На конце линии связи рядом с сущностью-потомком на диаграмме “Сущность-связь” помещается закрашенный кружок.

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

На диаграмме	Смысл обозначений
Пунктирные линии в направлении от родителя к потомку	Связи 1:1 или 1:N между двумя неидентификационно-зависимыми сущностями
Закрашенный кружок на конце линии связи рядом с сущностью-потомком	Указывает потомка (сторону “многие”)
Символ P рядом с кружком на соответствующем конце линии связи (от positive - положительный).	Потомок является обязательным
Ромб на родительском конце линии связи	Родитель является необязательным
Индекс 1 рядом с кружком на соответствующей стороне связи.	Связь 1:1; требуется ровно один потомок, не больше и не меньше.
Индекс Z рядом с кружком на соответствующей стороне связи.	Связь 1:1; потомок может быть один, либо его может не быть вовсе

Идентифицирующая связь принадлежности - идентифицирующие связи принадлежности показываются сплошными линиями. Сущности потомок рисуются в таких связях с закруглёнными углами. На родительской стороне идентифицирующей связи не может быть ромба, т.к. сущности-родители в таких связях всегда являются обязательными. На конце линии связи рядом с сущностью-потомком на диаграмме “сущность - связь” помещается закрашенный кружок.

На диаграмме	Смысл обозначений
Сплошные линии в направлении от родителя к потомку	Связи 1:1 или 1: N между двумя идентификационно-зависимыми сущностями
Закрашенный кружок на конце линии связи рядом с сущностью-потомком	Указывает потомка (сторону “многие”)
Символ P рядом с кружком на соответствующем конце линии связи	Потомок является обязательным
Индекс 1 рядом с кружком на соответствующей стороне связи.	Связь 1:1; требуется ровно один потомок, не больше и не меньше.
Индекс Z рядом с кружком на соответствующей стороне связи.	Связь 1:1; потомок может быть один, либо его может не быть вовсе
Прямоугольник с закруглёнными углами	Для изображения сущности-потомка

Неспецифические связи - под данной связью понимается связь М:М. Неспецифические связи обозначаются закрашенными кружками на обеих сторонах.

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

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

Идентификационно-зависимые сущности - это слабые сущности, идентификатор которых содержит идентификатор другой сущности.

Идентификационно-независимые сущности в составе своего идентификатора не содержит идентификатор сильной сущности, от которой она зависит.

Многозначные атрибуты представляют модель “сущность-связь” путем создания новой идентификационно-зависимой сущности и представление связи с ней “Один-ко-многим”.

2.3 CASE-технологии

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

CASE - технологии базируются на использовании трёх составляющих:

· Методология (устанавливает правила анализа и синтеза ИС);

· Нотация - определяет вид документов, используемых в процессе проектирования с использованием CASE - средств и форму их представления.

· Инструментальные средства - это программные и стандартные средства, реализующие определённую методологию и нотацию.

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

Так же в составе CASE - средств, как правило можно выделить следующие подсистемы:

· Репозиторий (Хранилище);

· Административная;

· Подсистема документирования;

· Графический редактор диаграмм;

· Подсистема проверки диаграмм;

· Сервисная подсистема;

2.3.1 ERwin Data Modeler

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

ERwin имеет два уровня представления данных - логический и физический.

2.4 Внутренняя схема данных

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

· Зависит от конкретной СУБД;

· От одной и той же логической модели может соответствовать не сколько разных физических моделей;

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

2.4.1 Система управления баз данных (СУБД)

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

Функции СУБД:

· управление данными во внешней памяти (на дисках);

· управление данными в оперативной памяти с использованием дискового кэша;

· журнализация изменений, резервное копирование и восстановление базы данных после сбоев;

· поддержка языков БД (язык определения данных, язык манипулирования данными).

Обычно современная СУБД содержит следующие компоненты:

· ядро, которое отвечает за управление данными во внешней и оперативной памяти и журнализацию,

· процессор языка базы данных, обеспечивающий оптимизацию запросов на извлечение и изменение данных и создание, как правило, машинно-независимого исполняемого внутреннего кода,

· подсистему поддержки времени исполнения, которая интерпретирует программы манипуляции данными, создающие пользовательский интерфейс с СУБД

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

В зависимости от архитектуры построения системы управления базами СУБД могут подразделяться на следующие типы: иерархические, многомерные, реляционные, сетевые, объектно-ориентированные, объектно-реляционные.

Реляционная модель - модель, определяющая способ структурирования и обработки БД.

Реляционное СУБД - хранит данные в форме отношения, которая представляет собой особую разновидность таблиц.

Отношение - это двухмерная таблица, обладающая следующими характеристиками:

· Строки содержать данные о сущности;

· Столбцы содержать данные об атрибутах сущности;

· Ячейки таблицы содержат одиночные значения;

· Все записи в одном столбце должны иметь один и тот же тип;

· Каждый столбец имеет уникальное имя;

· Порядок следования строк и столбцов не важен;

· Не может быть двух идентичных строк;

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

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

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

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

· Уникальность - Два экземпляра сущности не должны иметь одинаковое значение PK$

· Компактность - Составной PK не должен содержать ни одного атрибута удаление, которого не приводило к утрате уникальности;

· PK должен по возможности редко изменяться.

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

В реляционной модели данных все связи представляются путём помещения PK в родительскую таблицу в подчинённую таблицу. В подчинённой таблице такой ключ называется внешним (FK).

Целостность БД - это свойство БД, означающее что она содержит полную непротиворечивою и адекватно отражающее предметную область информации.

Целостность БД включает в себя:

· Целостность данных - Обеспечивается наличием PK;

· Ссылочная целостность - для её обеспечение каждому значению FK содержащее Null - значение, должно соответствовать значение PK родительской таблицы.

Стандартные правила поддержания ссылочной целостности

Действия над родительской таблицей	Вставка новой строки	Всегда разрешено
	Удаление строки	Запрещено, если имеются связанные записи в дочерней таблице
	Обновление PK	Запрещено, если имеются связанные записи в дочерней таблице
Действие над дочерней таблицей	Вставка новой строки	Запрещена если значение FK не соответствуют ни одному значению PK в родительской таблице
	Удаление строки	Всегда разрешено
	Обновление FK	Запрещено если обновление FK не соответствуют ни одному значению PK в родительской таблице

Ограничение ссылочной целостности (Ограничение связи) заключается в автоматической проверке СУБД на наличие для каждого значения FK в дочерней таблице соответствует значение PK в родительской таблице.

Ограничение - это правило накладывается на объект БД, которое тем или иным способом ограничивает значение этого объекта.

Для объектов существует следующие ограничения;

· PK;

· FK;

· Not null - обязательно требуется занесения значения;

· Null - не требуется занесение значений;

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

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

Аномалия удаления - это ситуация, когда удаление одних данных приводит к не предвиденному удалению других данных.

Аномалия обновления - это ситуация, когда обновления одного значение требует обновления нескольких строк.

Суть процесса нормализации заключается в том, что каждое нормализованное отношение должно иметь одну единственную тему.

Аномалии модификации могут быть устранены путём разбиения исходного отношения на два и более новых отношений. Способы предотвращений аномалий называются нормальными формами.

Нормальная форма (НФ) правило, которое должно удовлетворять БД. НФ как бы вложены в друг друга, т.е. отношение во второй НФ является отношением в первой НФ, а отношение в пятой НФ является отношением во всех предыдущих НФ.

· Первая НФ - отношение должно содержать PK

· Вторая НФ - Все поля таблицы (не ключевые) должны зависеть от PK, а также отношение должно содержать одну единственную тему.

· Третья НФ - отношение не должно иметь транзитивной зависимости. Транзитивная зависимость - это функциональная зависимость между не ключевыми атрибутами в отношении.

информационный база данный диспетчер такси

2.4.2 Microsoft office Access

Access - реляционная СУБД корпорации Microsoft. Входит в состав пакета Microsoft Office. Имеет широкий спектр функций, включая связанные запросы, связь с внешними таблицами и базами данных. Благодаря встроенному языку VBA, в самом Access можно писать приложения, работающие с базами данных.

Использование Access позволяет;

· добавлять новую информацию в базу данных, например новый артикул складских запасов;

· изменять информацию, уже находящуюся в базе, например перемещать артикул;

· удалять информацию, например если артикул был продан или утилизирован;

· упорядочивать и просматривать данные различными способами;

· обмениваться данными с другими людьми с помощью отчётов, сообщений электронной почты, внутренней сети или Интернета.

В БД Access входят - таблицы, формы, отчёты, запросы, макросы, модули.



3. Практическая часть. Инфологическое проектирование

Краткая характеристика предметной области

Заказчиком является клиент. Задачей является автоматизировать место диспетчера такси при заказе клиента.

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

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

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

Подходы к построению моделей:

· Семантическая сеть - граф, дуги которого есть отношения между вершинами (значениями);

· Графовые модели - отражают совокупность объектов реального мира в виде графа взаимосвязанных информационных объектов. Выделяют иерархическую или сетевую модели;

· Модель сущность - связь (ER - модель) - модель данных, позволяющая отписывать концептуальные схемы.

Основными конструктивными элементами являются сущность, атрибут и связь.

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

· Атрибут - поимённая характеристика сущности, которая принимает значения из некоторого множества значений.

· Связи - средство, с помощью которого представляются отношения между сущностями, имеющими место в ПО.

Модель сущность - связь представлена в приложении 1.

3.1 Системный анализ

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

· Изучение предметной области;

· Составление логической схемы бизнес-логики системы;

· Выявление недостатков и процессов, требующих автоматизации.

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

В завершение данного этапа были выявлены явные недостатки системы и обоснована потребность в её автоматизации.

3.2 Концептуальная схема

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

Построение схемы происходило следующим образом:

· Определение сущностей;

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

· Определение атрибутов и уникальных идентификаторов;

· Согласование схемы с заказчиком.

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

· Внесение клиента в БД или если он там есть найти его

· Составление договора

· Составление отчёта

3.3 Техническое задание

Техническое задание является ключевой вехой в создании информационной системы. Оно даёт точное и однозначное определение всех аспектов разработки информационной системы. Все требования и основные исходные данные. Этапы разработки ТЗ представлены ниже:

· Общие данные о системе;

· Назначение и цели системы;

· Требования к структуре и функциональности системы;

· Требования к подсистемам;

· Описание этапов разработки.

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

3.4 Разработка интерфейса

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

· Разработка макета основных форм системы;

· Определение связей между формами в соответствии с бизнес-логикой;

· Определение действий работника при использовании системы.

3.5 Процесс разработки

Итоговый этап создания информационной системы.

· Генерация БД в СУБД Access;

· Создание форм;

· Написание программного кода;

· Создание отчётов.



4. Описание логической модели данных

4.1 Сущности

Концептуальное проектирование, также как и инфологическое, полностью зависит от предметной области. Основным элементом концептуальной модели выступает сущность. Сущность - любой конкретный или абстрактный объект в рассматриваемой предметной области; базовый тип информации, который хранится в БД. В рассматриваемой предметной области можно выделить следующие сущности:

· ВИД_ОПЛАТЫ - содержит информацию о наличных или электронных платежах;

· КОД_ВОДИТЕЛЯ - содержит информацию о водителе, его код, фамилию, машину, телефон, состояние (находится на заказе или свободен), и его стоянка;

· ЗАКАЗ - содержит информацию о полном заказе, его время начала и конца, вида оплаты и типа заказа;

· КЛИЕНТ - содержит информацию о клиенте, его код, фамилию, телефон, откуда забрать и куда отвезти.;

· ОПЕРАТОР - содержит информацию о операторе, его код, фамилию, смену и его номер.

· ТИП_ЗАКАЗА - содержит информацию о типе заказе (грузо-перевозка, доставка или пассажирская доставка).

Перечень атрибутов

Вышеназванные сущности состоят из атрибутов. Атрибут - свойство сущности в предметной области. Его наименование должно быть уникальным для конкретного типа сущности. Атрибуты БД «Ломбард»:

· ВИД_ОПЛАТЫ - наличные, электронные;

· КОД_ВОДИТЕЛЯ - код, ФИО_водителя, машина, телефон, состояние, стоянка;

· ЗАКАЗ - код_заказа, код_оператора, код_водителя, код_клиента, время_поступления_заказа, время_завершения_заказа, вид_оплаты, тип_заказа, стоимость_услуги_такси;

· КЛИЕНТ - код_клинета, ФИО_клиента, телефон, от_куда, до_куда;

· ОПЕРАТОР - код_оператора, ФИО_оператора, смена, контактный_телефон.

· ТИП_ЗАКАЗА - тип_заказа.

3.2 Связи между сущностями

При проектировании БД информацию располагают обычно в нескольких таблицах. Таблицы при этом связывают с семантикой информации. В реляционной СУБД для указания связей в таблице производят операции их связывания. Основными типами бинарных связей являются:

· 1:1 - одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа;

· 1:N - экземпляр сущности одного типа связан со многими экземплярами сущности другого типа;

· N:1 - многие экземпляры сущности одного типа связаны с одним экземпляром сущности другого типа;

Рассмотрим связи между выявленными сущностями:

· Между атрибутами оператор и заказ будет существовать связь 1:N, так как одному оператору может соответствует несколько заказов;

· Между атрибутами водитель и заказ будет существовать связь 1:N, так как один водитель может забрать заказ;

· Между атрибутами вид оплаты и заказ будет существовать связь 1:N, так как на множество заказов может использоваться один вид оплаты.

· Между атрибутами клиент и заказ будет существовать связь 1:1, так как на один заказ может приходится один клиент.

· Между атрибутами тип заказа и заказ будет существовать связь 1:N, так как на один заказ может быть несколько типов.

3.3 Описание пользовательского интерфейса программы

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

Группа - набор записей, отобранных по определённому критерию. Группировка может быть:

· Для чисел - по десяткам, сотням и другим диапазонам значений, которые задаются в свойстве Интервал;

· Для текстовых полей - по первой букве, по двум первым буквам и т.д.;

· Для полей типа Дата - по годам, по кварталам и т.д.

На рисунке 2.2 представлен отчёт, в котором подведены итоги о выполнении заказа.

Рис. 2.2 Отчёт «Отчет по выполнению заказа»



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

Макет формы состоит из разделов:

· Область данных;

· Заголовок формы;

· Примечание формы;

· Верхний и нижний колонтитулы.

При создании форм в режиме Конструктора можно использовать:

· Вычисляемые поля;

· Подчинённые формы.

Подчинённая форма - форма, находящаяся внутри другой формы.

На рисунке 2.3. представлена кнопочная форма «Главное меню».

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

Рис. 2.3 Форма «Главное меню»

На рисунке 2.4 представлена форма подчиненная форма по таблице «Клиент».

Рис. 2.4 Форма «Новый клиент»

На рисунке 2.5 представлена подчиненная форма «Новый водитель»

Рис. 2.5 Подчинённая форма «Новый водитель»

На рисунке 2.6 представлена подчиненная форма «Новый заказ».

Рис. 2.6 Подчинённая форма «Новый заказ»

На рисунке 2.7 представлена подчиненная форма «Новый оператор».

Рис. 2.7 Подчинённая форма «Новый оператор»



Заключение

Результатом выполнения курсовой работы стало разработанное приложение баз данных, позволяющее автоматизировать место диспетчера такси при приеме заказа клиента. Разработанное приложение отвечает всем требованиям предметной области, таблицы созданной базы данных отвечают требованиям нормализации, что позволяет обеспечить целостность и непротиворечивость информации. Средствами СУБД Microsoft Access создан удобный пользовательский интерфейс. В первой главе данной курсовой работы были изучены теоретические аспекты реляционной БД и СУБД Access.А во второй главе было произведено проектирование самой БД «Автоматизированного места диспетчера такси», посредством:

· изучения особенностей предметной области базы данных «Автоматизированного места диспетчера такси»;

· разработка схемы БД; реализации разработанной схемы в MS Access;

· создание форм, отчётов, запросов, макросов;

· автоматизация работы созданной БД;

· анализ полученных результатов работы базы данных.



Список литературы

1. Кудинов Ю.И. Основы современной информатики: учебное пособие для студентов вузов, обучающихся по специальности "Прикладная информатика" / Ю.И. Кудинов, Ф.Ф. Пащенко. - СПб. [и др.]: Лань, 2009.

2. Калабухова Г.В.. Компьютерный практикум по информатике: офисные технологии: учебное пособие для студентов вузов, обучающихся по направлению и специальности "Социальная работа" / Г.В. Калабухова, В.М. Титов. - М.: ФОРУМ: ИНФРА-М, 2011. - 336 с.

3. Информатика и информационные технологии: учебное пособие для студентов, обучающихся по направлению "Экономика" и другим экономическим специальностям / [Ю.Д. Романова и др.]; под ред. Ю.Д. Романовой. - 2-е изд., испр. и доп. - М.: Эксмо, 2011. - 704 с.

4. Могилев А.В. Информатика: учебное пособие для студентов вузов, обучающихся по специальности "Информатика" / А.В. Могилев, Н.И. Пак, Е.К. Хеннер; ред.: Е.К. Хеннер. - 4-е изд., стер. - М.: Академия, 2007. - 842 с.

5. Информатика. Общий курс: учебник для студентов вузов, обучающихся по специальности "Прикладная информатика (по областям)" и другим экономическим специальностям / А.Н. Гуда [и др.]; ред. В.И. Колесников. - 4-е изд. - М.: Дашков и К°; Ростов н/Д.: Наука-Спектр, 2011. - 399 с.

6. Реляционная модель данных



Приложение 1

Логическая схема данных



Приложение 2

Техническое задание

1. Общие сведения

1.2 Полное наименование системы.

«автоматизированное рабочее место диспетчера такси»

1.3 Условное наименование системы

«АРМ»

1.4 Разработчик

ФИО: Аннюк Алексей Александрович

1.5 Заказчик

ФИО: Федотов Александр Юрьевич

Организация: Воткинский Машиностроительный Техникум

2. Назначение и цели создания системы

Система предназначена для уменьшения количества затрачиваемого времени на процесс заказа такси клиента между диспетчером и его рабочим местом. Система должна предоставлять автоматизацию организационно-управленческих процессов, хранения информации и её представление в удобном пользователю виде.

Целями создания системы являются:

· Повышение эффективности заполнения вызовов клиентов через диспетчерскую базу

· Автоматическое формирование отчетов

· Автоматизация при работе с клиентом

· Автоматизация рабочего места диспетчера такси.

3. Характеристика объекта автоматизации

Деятельность по оформлению заказа такси предполагает следующие действия:

· Откуда забрать клиента

· Занесение его в БД или поиск в БД

· Стоимость поездки

· Тип поездки

· Куда отвезти клиента

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

4. Требования к системе

4.1 Перечень подсистем, их назначение и основные характеристики

4.1.1 Внесение данных

Раздел предназначен для внесения данных клиента для будущего использования этих данных в договоре. Сюда входят такие пункты как: ФИО, гражданство, данные паспорта, место работы, должность.

4.1.2 Составление договора

В этом разделе происходит составление договора. Сюда входит информация о том на какую сумму оформлен залог, на какой срок, под какой процент, способ погашения, идентификатор ломбарда и клиента.

4.1.3 Формирование отчета

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

4.2 Перспективы развития системы:

· Модернизация системы, как самостоятельной программы, web-приложения и мобильного клиента

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

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

4.3 Требования к безопасности и надёжности системы

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

· Организация бесперебойного питания тех. средства

· Использование лицензионного программного обеспечения

4.4 Требования к эргономике интерфейса

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

Интерфейс не должен утомлять зрение. Он должен быть рассчитан на длительную работу пользователей с приложением в течение рабочего дня.

Формы должны быть оптимально загружены элементами управления. При необходимости можно использовать вкладки или дополнительные страницы кода.

Все страницы Системы должны быть оформлены исходя из одного общего стиля. Интерфейс Системы должен обеспечивать:

· быструю и удобную навигацию

· визуальное структурирование информации

· визуальное отображение информации

4.5 Требования к функциям подсистем

4.5.1 Добавить клиента

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

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

2. Здесь же пользователь может удалить клиента из БД, если есть надобность в этом

3. Можно вернуться обратно на главную станицу, если клиент вдруг передумал, или появились иные обстоятельства, вынуждающие вернуться на главную страницу

4.5.2 Добавление нового водителя

Раздел предназначен для занесения нового водителя в БД вследствии записи заносится новый водитель и его данные

1. Здесь пользователь должен заполнить детали водителя (Код водителя, ФИО водителя, телефон, машину, состояние, стоянку) далее нажать на кнопку добавить

4.5.3 Формирование нового заказа

Раздел предназначен для формирования нового заказа от клиента в службу такси.

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

4.5.4 Добавление нового оператора такси

Раздел предназначен для занесения нового оператора такси в БД вследствии записи заносится новый водитель и его данные

Здесь пользователь должен заполнить детали водителя (Код оператора, ФИО оператора, смена, контактный телефон) далее нажать на кнопку добавить

4.6 Требования к видам обеспечения

4.6.1 Информационное обеспечение

Требуется инсталлированная на машину пользователя СУБД Microsoft Access не ниже версии 2010 года. Для вывода некоторой информации требуется Microsoft Excel.

4.6.2 Техническое обеспечение

Компонент	Требование
Процессор	Процессор с тактовой частотой 500 МГц или выше
Оперативная память	ОЗУ объёмом 256 МБ или больше
Физическая память	2 ГБ свободного дискового пространства
Операционная система	Операционные системы Windows XP (32-разрядная), Windows Vista с пакетом обновления 1, Windows Server 2003 R2 с установленным MSXML 6.0, Windows Server 2008 (32- или 64-разрядная), Windows 7 или более поздних версий.



5. Состав и содержание работ по созданию системы

5.1 Изучение предметной области

5.2 Составление концептуальной схемы в соответствии с заданными требованиями по предметной области

5.3 Разработка физической реализации модели данных

Генерация базы данных Access на основе концептуальной схемы

5.4 Разработка приложения

5.4.1 Разработка интерфейса

5.4.2 Построение связей между формами в соответствии с бизнес-логикой предметной области

6. Требования к документированию

Техническое задание составлено в соответствии со стандартом ГОСТ 34.602-89 (состав и содержание) и ГОСТ 19.201-78 (техническое задание - требования к содержанию и оформлению)

7. Источники разработки:

...