СОДЕРЖАНИЕ
Анализ деятельности автосалона
Общие сведения об объекте автоматизации
Описание учета реализации автомобилей
Описание бизнес-процессов учета реализации автомобилей
Исследование информационных потоков
Анализ и выбор проектных решений
Обоснование разработки ИС «Автоматизация торговых операций в автосалоне»
Выбор и обоснование выбора используемого программного обеспечения
Разработка приложения АИС автосалона
Описание структурной схемы АИС
Описание логической и физической модели данных
Экономическое обоснование эффективности
Для управления БД используются системы управления базами данных (СУБД) - программное обеспечение, позволяющее создавать БД, обновлять хранимую в ней информацию и обеспечивающее удобный доступ к ней с целью просмотра и поиска. БД и СУБД являются составными частями информационной системы (ИС). При выборе СУБД необходимо оценить технические параметры системы, также необходимо убедиться, что данная СУБД способна принести предприятию выгоду.
По способу доступа к БД различают следующие виды СУБД:
1) Файл-серверные СУБД. В файл-серверных СУБД файлы данных располагаются централизованно на файл-сервере. СУБД располагается на каждом клиентском компьютере (рабочей станции). Доступ СУБД к данным осуществляется через локальную сеть. Синхронизация чтений и обновлений осуществляется посредством файловых блокировок.
Преимуществом этой архитектуры является низкая нагрузка на процессор файлового сервера.
Недостатки: потенциально высокая загрузка локальной сети; затрудненность или невозможность централизованного управления. Применяются чаще всего в локальных приложениях, которые используют функции управления БД; в системах с низкой интенсивностью обработки данных и низкими пиковыми нагрузками на БД.
Примеры: Microsoft Access, Paradox, dBase, FoxPro, Visual FoxPro.
2) Клиент-серверные СУБД. Клиент-серверная СУБД располагается на сервере вместе с БД и осуществляет доступ к БД непосредственно, в монопольном режиме. Все клиентские запросы на обработку данных обрабатываются клиент-серверной СУБД централизованно.
Недостаток клиент-серверных СУБД состоит в повышенных требованиях к серверу.
Достоинства: потенциально более низкая загрузка локальной сети; удобство централизованного управления; удобство обеспечения таких важных характеристик как высокая надёжность, высокая доступность и высокая безопасность.
Примеры: Oracle, Sybase Adaptive ServerEnterprise, PostgreSQL, MySQL.
3) Встраиваемые СУБД. Встраиваемая СУБД -- СУБД, которая может поставляться как составная часть некоторого программного продукта, не требуя процедуры самостоятельной установки. Встраиваемая СУБД предназначена для локального хранения данных своего приложения и не рассчитана на коллективное использование в сети. Доступ к данным со стороны приложения может происходить через SQL либо через специальные программные интерфейсы.
Примеры: OpenEdge, SQLite, BerkeleyDB, Microsoft SQL Server Compact, ЛИНТЕР.
В качестве СУБД выступает Microsoft Office Access 2010. Средой разработки приложения является программный продукт Borland C++ Builder инструмент быстрой разработки приложений, позволяющий создавать приложения на языке С++. Access имеет удобный и понятный интерфейс, позволяющая выполнить все заложенные в БД функции понятные любому пользователю. Также в него встроены различные мастера, конструкторы, которые облегчают процесс проектирования. Borland C++ Builder является универсальной системой, позволяющая разрабатывать самые разнообразные приложения, позволяющий работать почти со всеми современными СУБД.
Проектируемая база данных предназначена для хранения данных об учете торговых операций в автосалоне, что позволит повысить эффективность своей компании за счет систематизации и быстрого поиска требуемой информации. В БД должны храниться следующие сведения: каталог автомобилей, журнал заказов, информация о клиентах и менеджерах автосалона, а также должна быть учтена реализация автомобилей.
Исходя из выполняемых системой функций и требований, декомпозируем систему:
? Подсистема ввода и редактирования информации (модули ввода сведений о клиентах, авто, заказах, автосалоне, менеджерах;
? Подсистема учета реализации автомобилей (модули заказа автомобиля, продажи);
? Подсистема формирования отчетов (модули формирования отчетов о клиентах, заказах, каталоге автомобилей).
Система построена на основе двухуровневой клиент-серверной архитектуры обработки данных, именно модель файл-сервера. Удаленная база данных размещается на компьютере - сервере, а клиентское приложение, осуществляющее работу с этой базой данных, находится на рабочей станции. Клиент посылает запрос на предоставление данных и получает множество данных, извлеченных на сервере. Структурная схема АИС на концептуальном уровне представлена в приложении Б.
Менеджер автосалона должен иметь возможность получить следующие сведения:
- Какие автомобили доступны в каталоге (их основные характеристики и стоимость);
- Сведения о заказах клиентов;
- Сведения о реализации автомобилей.
Таким образом, имеется заданная предметная область - автомобильный салон. Следует организовать автоматизацию учета торговых операций в автомобильном салоне. В процессе продажи автомобилей участвуют продавец(автосалон) и покупатель(клиент). Объектом продажи является автомобиль. Спроектированная логическая модель данных имеет следующие сущности, представленные в таблицах:
Полужирным шрифтом в таблицах выделены ключевые поля.
Таблица1. - Автомобиль
|
ID авто |
ID модели |
Название |
Год выпуска |
Цвет |
Тип коробки |
Комплектация |
Материал салона |
Стоимость |
Таблица .2. - Заказ
|
Код заказа |
Дата заказа |
ID модели |
Название |
Год выпуска |
Цвет |
Тип коробки |
Комплектация |
Материал салона |
Стоимость |
Таблица .3. - Реализация
|
Номер договора |
Код заказа |
ID авто |
№ паспорта |
ФИО |
ID менеджера |
Стоимость |
Количество |
Название автосалона |
Таблица .4. - Клиенты
|
№ паспорта |
ФИО |
Телефон |
Таблица .5. - Менеджеры
|
ID менеджера |
ФИО |
Телефон |
Таблица .6. - Автосалон
|
Название |
Адрес |
Телефон справочной |
Телефон главного менеджера |
Карта |
Ключ - атрибут или набор атрибутов, используемый для идентификации экземпляра сущности, то есть по значениям ключевых полей можно однозначно найти требуемый экземпляр сущности. Каждая сущность обладает хотя бы одним возможным ключом. Ключами сущностей являются соответственно поля:
- для сущности «Автомобиль» поле «ID автомобиля»;
- для сущности «Заказ» поле «Код заказа»;
- для сущности «Реализация» поле «Номер договора»;
- для сущности «Клиенты» поле «Паспортные данные»;
- для сущности «Менеджеры» поле «ID менеджера»;
- для сущности «Автосалон» поле «Название».
В качестве модели данных для проектируемой системы была выбрана реляционная модель. Исходя из выбранной модели данных, была спроектирована схема логической (диаграмма ERD - модель сущность-связь) модели данных, представленная в приложении В.
Технологическая архитектура -- это архитектура оборудования, в ней описывается структура используемых технологий, связи между ними, а также принципы поддержки этими технологиями эксплуатационных требований организации. Технологическая архитектура описывает используемое в организации оборудование и программное обеспечение. Технологическая архитектура представляет собой логическое, не привязанное к конкретным производителям описание инфраструктуры и системных компонентов, требующихся для поддержки архитектуры приложений и информационной архитектуры
Физическая организация сети выбрана в виде звезды. Центром является маршрутизатор, который соединяет сети всех подразделов организации в единственную вычислительную сеть. Присутствующие концентраторы служат для соединения отдельных узлов сети и использования маршрутизатора, позволяющего локализовать трафик подразделов. Технологическая архитектура представлена в приложении Г.
Для удобства работы приложение будет открываться с главной формы (рис. 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 - Форма просмотра запросов
Наличие на форме большого количества невидимых компонентов в ряде случаев затрудняет проектирование пользовательского интерфейса. Отделение компонентов, отвечающих за доступ к данным и бизнес-логику информационной системы, от интерфейсных элементов, применяется для облегчения ее дальнейшей модернизации. Для этой цели в 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:
1) Выполнить двойной щелчок по свойству 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 - Форма с отображенной таблицей