Разработка автоматизированной системы учета торговых операций в автомобильном салоне

Министерство образования и науки РФ

Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

"Юго-Западный государственный университет"

(ЮЗГУ)

Кафедра информационных систем и технологий

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

по дисциплине "Базы данных"

на тему "Разработка автоматизированной системы учета торговых операций в автомобильном салоне"

Курск, 2014 г.

Содержание

Введение

1. Теоретические основы проектирования ИС и БД

1.1 Понятие, состав, задачи и цели ИС

.2 Концепция БД. Этапы проектирования БД

.3 Модели данных

.4 Методы проектирования БД

2. Анализ и проектирование ИС "Автоматизация учета торговых операций в автомобильном салоне"

2.1 Назначение БД. Анализ предметной области

.2 Построение инфологической модели

.3 Методология SADT. Описание IDEF0-модели

.4 Методология DFD

3. Разработка приложения "Автоматизация учета торговых операций в автосалоне"

3.1 Разработка форм приложения

.2 Создание модуля данных

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

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

4. Тестирование приложения

4.1 Тест 1

.2 Тест 2

.3 Тест 3

Заключение

Список используемых источников

Приложения

Введение

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

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

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

Произведем декомпозицию основной задачи курсовой работы на подзадачи:

-       Проектирование БД (анализ, разработка и описание предметной области);

-       Разработка алгоритма на языке С++;

-       Разработка пользовательского интерфейса приложения;

-       Осуществление программной реализации приложения;

-       Тестирование и отладка разработанного приложения.

В качестве СУБД выступает Microsoft Office Access 2007. Средой разработки приложения является программный продукт Borland C++ Builder, позволяющий создавать приложения на языке С++. Разработка информационной системы "Автоматизация учета торговых операций в автомобильном салоне" позволит оперативно предоставлять запрашиваемую пользователями информацию, обеспечит удобный доступ к ней, снизит объёма бумажного документооборота.

1.      Теоретические основы проектирования ИС и БД

1.1 Понятие, состав, задачи и цели ИС

Сегодня для получения дополнительных конкурентных преимуществ большинство отечественных компаний нуждаются в серьезной IT-поддержке своего бизнеса - системе преобразований компании, основанной на применении информационных технологий (ИТ) и направленной на увеличение эффективности деятельности организации.[ ] ИС используются во всех областях жизнедеятельности общества - образовании, предпринимательстве, менеджменте и других. Проектирование ИС представляет собой сложный многоступенчатый вид деятельности.

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

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

)        Запросы по данным. В системе должна существовать возможность находить и просматривать отдельные части накопленной информации.

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

Информационные системы позволяют решать следующие задачи:

-       Повышение оперативности и эффективности взаимодействия между подразделениями;

-       Создание системы статистического учета на предприятии;

-       Учет и оперативное регулирование хозяйственных операций;

-       Подготовка стандартных документов для внешней среды;

-       Регистрация и обработка событий (например, оформление и мониторинг выполнения заказов);

-       Устранение рутинных операций;

-       Ускорение процессов обработки и преобразования информации;

-       Повышение точности учетно-отчетной информации;

-       Повышение оперативности и качественного уровня обслуживания пользователей.

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

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

Цели ИС состоят в следующем:

-       Хранение и обработка информации;

-       Обеспечение эффективного поиска информации;

-       Передачи информации по соответствующим запросам.

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

1.2 Концепция БД. Этапы проектирования БД

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

-       Данные отделяются от прикладной программы (ПП), появляется специальная программная надстройка для управления данными, называемая системой управления базами данных (СУБД);

-       СУБД управляет данными и служит посредником между ними и ПП;

-       ПП упрощаются, освобождаются от функций структуризации, хранения и поиска данных [7, 17].

Таким образом, использование концепции баз данных позволяет:

)        Повысить надежность, целостность и сохранность данных;

)        Сохранить затраты интеллектуального труда;

)        Обеспечить простоту и легкость использования данных;

)        Обеспечить независимость прикладных программ от данных(изменений их описаний и способов хранения);

)        Обеспечить достоверность данных;

)        Обеспечить требуемую скорость доступа к данным;

)        Стандартизовать данные в пределах одной предметной области;

)        Автоматизировать реорганизацию данных;

)        Обеспечить защиту от искажения и уничтожения данных;

)        Сократить дублирование информации за счет структурирования данных;

)        Обеспечить обработку незапланированных запросов к хранимой информации;

)        Создать предпосылки для создания распределенной обработки дaнныx.

Обеспечение основных принципов концепции баз данных достигается за счет трехуровневого представления информации - концептуального, физического и внешнего [7, 30].

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

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

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

)        Этап формулирования и анализа требований. На данном этапе устанавливаются цели организации, определяются требования к БД. Они состоят из общих требований и специфических требований. Все требования документируются в форме, доступной конечному пользователю и проектировщику БД [3, 44].

)        Этап концептуального проектирования заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Исходными данными могут быть совокупность документов пользователя или алгоритмы приложений (алгоритмы бизнеса) [3, 44].

)        Этап логического проектирования. По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели "сущность-связь". В процессе логического проектирования высокоуровневое представление данных преобразуется в структуру используемой СУБД. Основной целью этапа является устранение избыточности данных с использованием специальных правил нормализации. Цель нормализации - минимизировать повторения данных и возможные структурные изменения БД при процедурах обновления. Это достигается декомпозицией одной таблицы в две или несколько с последующим использованием при запросах операции навигации.

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

Различие уровней представления данных на каждом этапе проектирования реляционной базы данных представлены в таблице 1.1. - Различие уровней представления данных:

Таблица 1.1. - Различие уровней представления данных

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

1.3 Модели данных

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

-       Объект предметной области (сущность) - объект реального мира, характеризующийся некоторыми свойствами;

-       Атрибут - это информационное отображение свойств объекта.

Различают три основных типа моделей данных: иерархическую, сетевую и реляционную.)    Иерархическая модель данных

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

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

Рисунок 1.1. - Графическое представление иерархической модели данных

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

сложность внесения в нее изменений.)    Сетевая модель данных

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

Рисунок 1.2. - Графическое изображение сетевой модели данных

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

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

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

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

-       Каждый элемент таблицы соответствует одному элементу данных;

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

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

-       Одинаковые строки в таблице отсутствуют;

-       Порядок следования строк и столбцов может быть произвольным.

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

информационный база данные приложение

1.4 Методы проектирования БД

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

Метод сущность-связь называют также методом "ER-диаграмм" (англ. "Entity-Relationship model"). Данная модель была впервые предложена Питером Ченом в 1976 году. Ее предназначение - концептуальное моделирование предметной области. Модель "сущность-связь" (объектно-ориентированная модель предметной области) основывается на некой важной семантической информации о реальном мире и предназначена для логического представления данных [3, 36]. Она определяет значения данных в контексте их взаимосвязи с другими данными. Важным является тот факт, что из модели "сущность-связь" могут быть порождены все существующие модели данных (иерархическая, сетевая, реляционная), поэтому она является наиболее общей. ER-модель обычно представляется в графической форме.

Основные элементы ER-моделей:

-       Объекты (сущности);

-       Атрибуты объектов;

-       Связи между объектами.

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

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

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

Основные преимущества ER-моделей:

-       Наглядность;

-       Проектирование базы данных с большим количеством объектов и атрибутов;

-       ER-модели реализованы во многих системах автоматизированного проектирования баз данных.

Процесс проектирования базы данных является итерационным - допускающим возврат к предыдущим этапам для пересмотра ранее принятых решений и включает следующие этапы [3, 39]:

)        Выделение сущностей и связей между ними;

)        Построение диаграмм ER-типа с учетом всех сущностей и их связей;

)        Формирование набора предварительных отношений с указанием предполагаемого первичного ключа для каждого отношения и использованием диаграмм ER-типа;

)        Добавление не ключевых атрибутов в отношения.

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

В теории реляционных баз данных обычно выделяется следующая последовательность нормальных форм:

-       Первая нормальная форма (1NF или 1НФ);

-       Вторая нормальная форма (2NF или 2НФ);

-       Третья нормальная форма (3NF или 3НФ);

-       Нормальная форма Бойса-Кодда (BCNF или НФБК);

-       Четвертая нормальная форма (4NF или 4НФ);

-       Пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).

Таблица находится в первой нормальной форме, если каждый её атрибут атомарен, то есть может содержать только одно значение. Для приведения таблицы к 1NF требуется разбить таблицу на несколько отдельных таблиц. Таблица находится во второй нормальной форме, если она находится в первой нормальной форме, и при этом любой её атрибут, не входящий в состав возможного ключа, функционально полно зависит от каждого возможного ключа. Функциональная зависимость - это связь типа "многие к одному" между двумя множествами атрибутов заданной переменной отношения [3, 53]. Функционально полная зависимость означает, что атрибут функционально зависит от всего составного ключа, но при этом не находится в функциональной зависимости от какой-либо из входящих в него атрибутов (частей). Отношение находится в третей нормальной форме, если оно находится во второй нормальной форме и между атрибутами нет транзитивных зависимостей. Транзитивная зависимость - это зависимость между не ключевыми атрибутами. Транзитивные зависимости изымаются также с помощью декомпозиции отношения на другие два или больше отношений, которые не содержат транзитивных отношений и объединение которых даст начальное отношение. Переменная отношения находится в нормальной форме Бойса-Кодда тогда и только тогда, когда детерминанты всех ее функциональных зависимостей являются потенциальными ключами. Отношение находится в 4NF, если оно находится в НФБК и не содержит нетривиальных многозначных зависимостей. То есть все многозначные зависимости являются функциональными зависимостями от ключей отношения.

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

2.      Aнализ и проектирование ИС "Автоматизация учета торговых операций в автомобильном салоне"

2.1 Назначение БД. Анализ предметной области

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

-       Какие автомобили доступны в каталоге(их основные характеристики и стоимость);

-       Сведения о заказах клиентов;

-       Сведения о реализации автомобилей.

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

)        Автомобиль

-       ID автомобиля;

-       Название;

-       Год выпуска;

-       Цвет;

-       Тип коробки;

-       Комплектация;

-       Материал салона;

-       Мощность;

-       Страна сборки;

-       Цена;

-       Фото.

)        Заказ

-       Код заказа;

-       Дата заказа;

-       ID модели;

-       Название;

-       Год выпуска;

-       Цвет;

-       Тип коробки;

-       Комплектация;

-       Материал салона;

-       Стоимость.

)        Реализация

-       Номер договора;

-       Код заказа;

-       Дата заказа;

-       ID автомобиля;

-       № паспорта;

-       ФИО;

-       ID менеджера;

-       Стоимость;

-       Количество;

-       Название автосалона.

)        Клиенты

-       № паспорта;

-       ФИО клиента;

-       Телефон.

)        Менеджеры

-       ID менеджера;

-       ФИО менеджера;

-       Телефон.

-       Название;

-       Адрес;

-       Телефон справочной;

-       Телефон главного менеджера;

-       Карта.

Между объектами предметной области есть связующее звено - продажа (реализация) - рисунок 2.1.

Рисунок 2. 1. - Объектно-связная модель

2.2 Построение инфологической модели

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

Таблица 2.1. - Автомобиль

Таблица 2.2. - Заказ

Таблица 2.3. - Реализация

Таблица 2.4. - Клиенты

Таблица 2.5. - Менеджеры

Таблица 2.6. - Автосалон

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

-       для сущности "Автомобиль" поле "ID автомобиля";

-       для сущности "Заказ" поле "Код заказа";

-       для сущности "Реализация" поле "Номер договора";

-       для сущности "Клиенты" поле "Паспортные данные";

-       для сущности "Менеджеры" поле "ID менеджера";

-       для сущности "Автосалон" поле "Название".

Инфологическая модель представляет собой описание предметной области, основанное на анализе семантики объектов и явлений, выполненное без ориентации на использование в дальнейшем программных или технических компьютерных средств. Инфологическая модель БД Автосалона представлена на рисунке 2.2.

Рисунок 2.2. - Инфологическая модель базы данных

Каждая из сущностей имеет набор атрибутов. Между сущностями устанавливаются связи. Связь - это некоторая ассоциация между двумя сущностями. Связи делятся на три типа(1:1, 1:М, М:М). Все связи в имеют тип 1:М. Реляционная база данных представляет собой совокупность отношений, содержащих всю информацию, которая должна храниться в БД.

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

Рисунок 2.3. - Реляционная модель данных "Учет торговых операций в автосалоне"

2.3 Методология SADT. Описание IDEF0-модели

SADT (Structured Analysis and Design Technique) -методология структурного анализа и проектирования, интегрирующая процесс моделирования, управление конфигурацией проекта, использование дополнительных языковых средств и руководство проектом со своим графическим языком.

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

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

)        Выход - результат выполнения функции (материал или информация);

)        Управление - условия, правила, стратегии, стандарты, которые влияют на выполнение функции;

)        Механизм - ресурсы, с помощью которых выполняется работа;

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

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

)        Связь по входу - стрелка выхода вышестоящей работы направляется на вход нижестоящей;

)        Связь по управлению - выход вышестоящей работы направляется на управление нижестоящей;

)        Обратная связь по входу - выход нижестоящей работы направляется на вход вышестоящей;

)        Обратная связь по управлению - выход нижестоящей работы направляется на управление вышестоящей;

)        Связь выход-механизм - выход одной работы направляется на механизм другой.

В приложении А представлена IDEF0-модель "Информационная система автосалона", декомпозированная на 3 подуровня. На первом уровне (приложение А, рис. 1) блок А0 отвечает за реализацию автомобилей на основе следующих данных: заказ клиента и поставщик автомобилей. В результате на выходе получаем выполненный заказ. В качестве управления выступают: законодательство РФ, лицензия на продажу, каталог автомобилей. Механизм - Автосалон "AlongTheRoad". При декомпозиции (приложение А, рис. 2) блок А0 разбивается на 4 блока: А1, А2, А3, А4. В блоке А1 формируется план закупок, руководствуясь входными данными заказ клиента, поставщик автомобилей. Блок А2 - Договор с поставщиками соединяется с блоком А3 - Формирование каталога автомобилей. Блок А4 отвечает за сбыт автомобилей, на выходе - выполненный заказ. Механизмами выступают: отдел по закупке автомобилей, юридический отдел, отдел рекламы и PR, отдел бухгалтерии, отдел сбыта автомобилей. Таким образом, выделили 4 подзадачи, произведя детализацию первого уровня.

Перейдем на 3 уровень декомпозиции блока А4 - Сбыт автомобилей (приложение А, рис. 3). Диаграмма представлена тремя блоками: А41 - Принятие заявки, А42 - Оформление договора, А43 - Продажа автомобиля. В качестве управления остаются те же стандарты и правила, что и на первом уровне, на выходе получаем выполненный заказ.

2.4 Методология DFD

Целью методологии является построение модели рассматриваемой системы в виде диаграммы потоков данных (Data Flow Diagram - DFD). Диаграммы потоков данных предназначены прежде всего для описания документооборота и обработки информации, хотя допускают и представление других объектов[6, 57]. При создании диаграммы потоков данных используются четыре основных понятия:

Потоки данных;

Процессы (работы) преобразования входных потоков данных в выходные;

Внешние сущности;

Накопители данных (хранилища).

Потоки данных являются абстракциями, использующимися для моделирования передачи информации (или физических компонент) из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации[6, 58].

Процессы (работы) служат для преобразования входных потоков данных в выходные. Каждый процесс имеет уникальный номер для ссылок на него внутри диаграммы, который может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели. Хранилище (накопитель) данных моделирует данные, которые будут сохраняться в памяти между процессами. Информация, которую содержит хранилище, может использоваться в любое время после ее получения, при этом данные могут выбираться в любом порядке. Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником данных. В приложении Б представлены диаграммы потоков данных ИС "Автоматизация торговых операций в автосалоне".

3.      Разработка приложения "Автоматизация учета торговых операций в автосалоне"

3.1 Разработка форм приложения

Для удобства работы приложение будет открываться с главной формы (рис. 3.1). Формы связываются с главной формой функцией подключением к главной форме файлов: #include "Unit1.h". Оформим внешний вид формы фоновым рисунком. Это можно сделать с помощью метода LoadFromFile:

Image1->Picture->LoadFromFile("train.bmp");

Или добавить в свойство Picture компонента Image нужное изображение. Воспользуемся вторым способом.

Рисунок 3.1. - Главная форма приложения

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

Создадим форму для просмотра данных и навигации по ним на примере таблицы "Автомобиль" (рис. 3.2.). Для этого добавим на форму компоненты Panel, DBGrid, ComboBox, Button, BitBtn, Edit, Image, Label, CroupBox, Navigator и не визуальный компонент OpenPictureDialog.

Рисунок 3.2. - Форма для просмотра и поиска данных

Аналогичным образом созданы остальные формы для просмотра и поиска данных.

Рассмотрим создание форм для просмотра отчетов(рис.3.3). Используем компонент QuickReport, основанный на наборе горизонтальных полос (bands). При построении отчета на форму помещаются несколько компонентов QRBand различных типов, также используются компоненты QRImage, QRLabel, QRSysData.

Рисунок 3.3. - Форма отчета "Каталог автомобилей"

Для создания формы запросов (рис. 3.4.) будем использовать компоненты DBGrid - позволяет просматривать запрашиваемые данные, RadioButton - Отражает критерии запроса, RadioGroup - группирует критерии для удобства. Кнопка BitBtn закрывает форму.

Рисунок 3.4. - Форма просмотра запросов

3.2 Создание модуля данных

Наличие на форме большого количества невидимых компонентов в ряде случаев затрудняет проектирование пользовательского интерфейса. Отделение компонентов, отвечающих за доступ к данным и бизнес-логику информационной системы, от интерфейсных элементов, применяется для облегчения ее дальнейшей модернизации. Для этой цели в C++ Builder имеется специальный тип, называемый модулем данных - TDataModule. Компонент этого типа можно условно считать специальным видом формы. Такой компонент-контейнер может содержать компоненты со страницы Data Access, а сам он не виден пользователю во время выполнения.

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

File/New/Other/DataModule

В появившемся окне разместить компоненты: ADOConnection, DataSource и ADOTable. Количество компонентов DataSource и ADOTable должно соответствовать количеству таблиц в БД (рис.3.5). Свойство каждого компонента DataSource DataSet установить на имя соответствующего ему ADOTable (например, DataSet->ADOTable1).

Рисунок 3.5. - Окно модуля данных с компонентами

Компонент ADOConnection1 обеспечит связь других компонентов с базой данных при помощи механизма ADO. Связь обеспечивается свойством компонента ConnectionString:

)        Выполнить двойной щелчок по свойству ConnectionString компонента ADOConnection1. Откроется окно подключения компонента к ADO:

Рис.3.6. - Окно подключения компонента к ADO

2)      Нажать кнопку Build. Открывается новое окно, содержащее настройки подключения, выбираем поставщика данных на вкладке Поставщик данных:

Рисунок 3.7. - Выбор поставщика данных

3)      На вкладке Подключение указать источник данных - прописать путь к БД:

G:\БД\БД авто.accdb

4) Нажать Проверить подключение:

Рисунок 3.8. - Окно проверки связи с данными

Выделить компоненты ADOTable и установить свойство Connection на ADOConnection1. Для каждого компонента ADOTable выбрать имя таблицы в свойстве TableName. Установить свойство Active->true.

Рисунок 3.9. - Окно инспектора объектов с установленными свойствами

Для обеспечения подключения формы приложения к данным с помощью модуля данных следует заранее создать форму приложения и добавить ее в хранилище (repository):

Рисунок 3.10. - Добавление формы в репозиторий

После создания макеты формы выполнить:

File/Include/Unit/DataModule

Для отображения таблицы на форме расположить компонент DBGrid и установить его свойство DataSource на имя одного из компонентов в модуле. После выполнения указанных действий на каждой из созданных форм отобразится таблица БД.

Рисунок 3.11. - Форма с отображенной таблицей

В модуль данных добавляем компоненты DataSource, ADOQuery для связи с таблицей БД. Устанавливаем свойство DataSet компонента DataSource7 на имя компонента ADOQuery1. Свойство Connection компонента ADOQuery1 устанавливаем на ADOConnection1 .

Рисунок 3.12. - Модуль данных с компонентами DataSource, ADOQuery.

Создаем форму следующего вида: DBGrid, RadioButton, RadioGroup, BitBtn

Рисунок 3.13. - Форма просмотра запросов

Cвойство DataSource компонента DBGrid устанавливаем соответственно модулю данных: DataModule1->Datasource7.

В обработчикe события OnClick компонента RadioButton :

__fastcall TForm8::RadioButton1Click(TObject *Sender)

{->ADOQuery1->SQL->Clear();->ADOQuery1->SQL->Add("SELECT Автомобиль.Название, Автомобиль.Цвет, Автомобиль.Цена FROM Автомобиль");->ADOQuery1->Open();

}

//---------------------------------------------------------------------------__fastcall TForm8::RadioButton2Click(TObject *Sender)

{->ADOQuery1->SQL->Clear();->ADOQuery1->SQL->Add("SELECT Автомобиль.[ID автомобиля], Автомобиль.Название, Автомобиль.Мощность FROM Автомобиль GROUP BY Автомобиль.[ID автомобиля], Автомобиль.Название, Автомобиль.Мощность ORDER BY Автомобиль.Мощность;");->ADOQuery1->Open();

}

//---------------------------------------------------------------------------__fastcall TForm8::RadioButton3Click(TObject *Sender)

{->ADOQuery1->SQL->Clear();->ADOQuery1->SQL->Add("SELECT Реализация.[ФИО клиента], Автомобиль.Название, Автомобиль.Цвет, Заказ.[Год выпуска], Реализация.[ID менеджера]FROM Заказ INNER JOIN (Автосалон INNER JOIN (Автомобиль INNER JOIN Реализация ON Автомобиль.[ID автомобиля] = Реализация.[ID автомобиля]) ON Автосалон.[Название автосалона] = Реализация.[Название автосалона]) ON Заказ.[Код заказа] = Реализация.[Код заказа];");->ADOQuery1->Open();

}

//---------------------------------------------------------------------------__fastcall TForm8::RadioButton4Click(TObject *Sender)

{->ADOQuery1->SQL->Clear();->ADOQuery1->SQL->Add("SELECT Клиенты.[ФИО клиента], Клиенты.[Паспортные данные], Реализация.[Дата заказа]FROM Клиенты INNER JOIN (Автомобиль INNER JOIN Реализация ON Автомобиль.[ID автомобиля] = Реализация.[ID автомобиля]) ON Клиенты.[Паспортные данные] = Реализация.[Паспортные данные]ORDER BY Реализация.[Дата заказа];");1->ADOQuery1->Open();

}

//-------------------------------------------------------------------------

Запросы при работе приложения представлены ниже

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

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

Создавая форму для просмотра отчета, размещаем следующие компоненты:

-       Для подключения к БД - ADOConnection, ADOTable, DataSource;

-       Для отображения отчета - QuickRep, QRBand, QRDBText, QRLabel, QRDBImage ( вкладка QReport);

Задаем свойство Caption компонента QRLabel в соответствии с названиями столбцов таблицы в БД Access.

Рисунок 3.14. - Форма для просмотра отчета

Затем задаем свойство BandType-> rbDetail компонента QRBand1 и BandType-> rbColumnHeader компонента QRBand2. Свойство DataSet компонента QRDBText устанавливаем на имя компонента ADOTable для связи с таблицей БД. Затем в свойстве DataField выбираем имя требуемого поля таблицы. На форме работы с таблицей БД зараенее создана кнопка Каталог автомобилей, которая будет отвечать за открытие отчета. В обработчике события OnClick этой кнопки:

__fastcall TForm1::Button2Click(TObject *Sender)

{->QuickRep1->Preview();

}

4. Тестирование приложения

4.1 Тест 1

Проверим работу приложения. Для этого запустим файл Project1.exe. После запуска приложение отображает главную форму, содержащую главное меню (рис. 4.1.)

Рисунок 4.1. - Главная форма приложения

При выборе пункта меню "Автосалон" на экране появляется следующая форма, представленная на рис 4.2. При нажатии на кнопку Close, возвращаемся в главное меню приложения.

Рисунок 4.2. - Форма "Автосалон"

При нажатии на пункт меню "Автомобиль" на экране появляется форма, представленная на рис 4.3.

Рисунок 4.3. - Форма "Автомобиль"

То же самое происходит при нажатии остальных пунктов меню. Форма просмотра и поиска данных "Заказ" представлена на рис. 4.4.

Рисунок 4.4. - Форма "Заказ"

4.2 Тест 2

Выбрав пункт главного меню "Автосалон" произведем поиск по адресу (рис. 4.5.). Стрелка в области данных переместилась на вторую запись в соответствии с введенным критерием поиска. Произведем поиск по названию автосалона (рис. 4.6.), введя требуемое название "Киа", так же происходит перемещение по записям.

Рисунок 4.5. - Поиск данных по адресу

Рисунок 4.6. - Поиск данных по названию автосалона

При нажатии на запись в области данных в верхней части формы отображается карта, соответствующая адресу автосалона (рис. 4.7.). Кнопки "Открыть" и "Сохранить" позволяют загружать другие изображения и сохранять их в существующей БД.

Рисунок 4.7. - Форма "Автосалон" с картой месторасположения

Кнопка "Увеличить" открывает отчет с увеличенным изображением карты (рис. 4.8.)

Рисунок 4.8. - Просмотр отчета

Рассмотрим работу формы Avto, вызываемую в главном меню при нажатии на кнопку "Автомобиль". Здесь так же возможно осуществление поиска по записям при введении определенных критериев. Кроме того, доступна фильтрация данных по типу комплектации автомобиля (рис. 4.9.) Фильтрация производится следующим образом: в выпадающем списке выбирается критерий фильтрации и нажимается кнопка "ОК".

Рисунок 4.9. - Фильтрация данных

При нажатии в области данных на требуемую запись в правой части отображается фото автомобиля (рис. 4.10.).

Рисунок 4.10. - Отображение фото выбранной записи таблицы

Возможно добавление и удаление записей с помощью компонента Navigator. На рисунке 4.11. добавлена шестая запись с помощью кнопки "+", а также загружено изображение с помощью кнопок "Открыть" и "Сохранить". Таким образом, обеспечивается обновление данных каталога автомобилей.

Рисунок 4.11. - Обновление данных таблицы (добавление новой записи и загрузка изображения)

4.3 Тест 3

Рисунок 4.12. - Отчет "Каталог автомобилей"

При нажатии на кнопку "Просмотр запросов" на экране появляется форма просмотра запросов (рис. 4.13.)

Рисунок 4.13 - Форма просмотра запросов

При выборе параметров запросов данные моментально отображаются в верхней области формы (рис. 4.14. а, б, в)

Рисунок 4.14 (а) - Форма просмотра запросов в различных режимах

Рисунок 4.14 (б) - Форма просмотра запросов в различных режимах

Рисунок 4.14 (в) - Форма просмотра запросов в различных режимах

Кнопка "Close" закрывает данную форму.

Работа остальных режимов форм аналогична, снимки экрана представлены в приложении В. Листинг программного кода представлен в приложении Г.

Заключение

В результате выполнения курсовой работы разработана информационная система "Автоматизация учета торговых операций в автосалоне". Проектирование и разработка ИС осуществлялось в несколько этапов:

-       Проектирование БД (анализ, разработка и описание предметной области);

-       Разработка алгоритма на языке С++;

-       Разработка пользовательского интерфейса приложения;

-       Осуществление программной реализации приложения;

-       Тестирование и отладка разработанного приложения.

Выполнены поставленные цели и задачи: создана ИС автоматизации учета торговых операций в автомобильном салоне, включающая в себя БД и приложение, позволяющее вести учет и контроль за базой данных. Разработанное приложение отвечает всем требованиям предметной области, таблицы созданной базы данных отвечают требованиям нормализации, что позволяет обеспечить целостность и непротиворечивость информации. В ходе проектирования БД изучена сфера деятельности автосалона, собрана необходимая информация. Назначение данной БД состоит в возможности вести учет торговых операций компании, хранить и получать необходимые данные, а также обновлять их. Существует возможность корректировки информации. Созданные формы, запросы и отчеты позволяют быстро и эффективно обновлять данные, осуществлять поиск нужных данных, анализировать данные. Таким образом, получены навыки работы с автоматизированными системами в условиях, приближенных к реальным, закреплены практические навыки разработки БД, запросов на языке SQL, прикладных программ в среде визуального программирования Borland C++ Builder 6.0. Созданное приложение позволяет сократить затраты времени и средств на хранение, обработку и транспортировку информации, обеспечивает удобный доступ к ней, снижает объем бумажного документооборота.

Список используемых источников

1)          Карпова Т.С. Базы данных: модели, разработка. - СПб.: Питер, 2006,. - 304 с.

2)      Лапина Т.И. Управление данными [Текст]. - Юго-Зап. гос. ун-т, Курск, 2011. - 255 с.

3) Илюшечкин В.М. основы использования и проектирования БД [Текст]: учебное пособие. - М.: Высшее образование, 2009. - 213с.

4)          Хомоненко А.Д. Базы данных: Учебник для высших учебных заведений / Под ред. проф. А.Д. Хомоненко. - СПб.: Корона-принт, 2005. - 416 с.

5) Верхова Г.В. Базы данных: учебное пособие. - СПб.: Политехника, 2008. - 171с.

6) Горбаченко В. И., Убиенных Г. Ф., Бобрышева Г. В. Создание функциональной модели информационной системы с помощью CASE-средства CA ERwin Process Modeler 7.3. - Пенза: ПГУ, 2010. - 66 с.

7)      Копейкин М.В., Спиридонов В.В., Шумова Е.О. Базы данных. Концепция баз данных: Учеб. пособие. - СПб.: СЗТУ, 2004. - 116 с.

)        Маркин А.В. Построение запросов и программирование на SQL [Текст]: учебное пособие. - М.: Диалог - МИФИ, 2008. - 320с.

)        Голицына О. Л. Программное обеспечение [Текст] : учебное пособие. - 3-е изд., перераб. и доп. - М. : Форум, 2010.