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

Рисунок 1.3 Декомпозиция системы «Автоматизация продаж автотранспортных средств»

Диаграмма декомпозиции системы Автоматизация продаж автотранспортных средств» разбивается на четыре бизнес-процесса: оформление заказа на покупку, учет продаж, учет движения товаров на складе, анализ динамики продаж.

Инициализацией бизнес-процесса "Оформления заказа на покупку" является поступление на вход регистрационных данных пользователя и остатков товаров в складе центра. Целью выполнения бизнес-процесса является запись в базу данных информации о заказанном товаре. Декомпозиция данного бизнес-процесса приведена на рис. 1.4.

Инициализацией бизнес-процесса "Учет продаж" есть поступление на вход заказа на товар и документов в зависимости от выбранной системы оплаты. Целью выполнения бизнес-процесса является формирование расходной накладной и ведомости по продаже для дальнейшего использования в расчетах остатков товаров на складе и для анализа динамики продаж. Декомпозиция данного бизнес-процесса приведена на рис. 1.5.

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

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

Рисунок 1.4 Декомпозиция второго уровня бизнес-процесса «Оформление заявки на покупку»

Рисунок 1.5 Декомпозиция второго уровня бизнес-процесса «Учет продаж»

Рисунок 1.6 Декомпозиция второго уровня бизнес-процесса «Учет товара на складе»

Рисунок 1.7 Декомпозиция второго уровня бизнес-процесса «Анализ динамики продаж»

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

Рисунок 1.8. Диаграмма дерева узлов разрабатываемого модуля

1.3. Построение инфологической (концептуальной) модели предметной области.

Модуль «Автоматизация продаж автотранспортных средств» позволяет автоматизировать функции пользователя (клиента) и менеджера по продаже, а именно:

бизнес-задач01: "Оформления заказа на покупку".

бизнес-задача 02: "Учет продаж".

бизнес-задача 03: "Учет движения товаров на складе".

бизнес-задача 04: "Анализ динамики продаж".

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

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

введение входных данных;

контроль правильности ввода данных;

сохранение данных;

функции пересмотра и редактирования данных;

печать исходных документов.

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

Модель «сущность-связь» называют также методом ER — диаграмм (Essence - сущность, Relation - связь). Эта модель основана на использовании 3-х основных конструктивных элементах:

• сущность;

• атрибут;

• связь.

Взаимосвязи между таблицами БД могут быть типизированы по следующим основным видам:

• отношение «один к одному» (1:1) означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице;

• отношение «один ко многим» (1:М) возникает, когда одна запись взаимосвязана со многими другими;

• отношение «многие к одному» означает, что многие записи связаны с одной (М:1);

• отношение «многие ко многим» (M:N) возникает между двумя таблицами в тех случаях, когда:

• одна запись из первой таблицы может быть связана более чем с одной записью из второй таблицы;

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

1.4. Проектирование логической структуры базы данных

Построение моделей данных в ERStudio начинается с выбора в меню File пункта создания новой модели (рис. 1.9).

Рисунок 1.9 - Создание новой модели данных

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

Рисунок 1.10 - Создание новой сущности

Для вновь созданной сущности задаем имя и создаем атрибуты, указывая их тип и размерность (рис. 1.11).

Рисунок 1.11 - Создание атрибутов сущности

На рис. 1.12 показано назначение атрибута КодСотрудника первичным ключом в таблице.

Рисунок 1.12 - Назначение первичного ключа

После создания всех сущностей, устанавливаем связи между таблицами (идентифицирующие или неидентифицирующие). На рис. 1.13 представлены сущности модели и идентифицирующие связи между ними.

Рисунок 1.13 - Логическая модель базы данных

1.5. Проектирование физической структуры базы данных

На основании логической модели создать физическую модель БД.

На рис. 1.14 показан переход от логического представления модели БД к физическому представлению.

Рисунок 1.14 - Переход к физической модели

Далее появляются ряд окон для установки различных параметров генерируемой физической модели. Диалоговые окна представлены на рис. 1.15 – 1.18.

Рисунок 1.15 - Генерация физической модели. Шаг 1

Рисунок 1.16 - Генерация физической модели. Шаг 2

Рисунок 1.17 - Генерация физической модели. Шаг 3

Рисунок 1.18 - Генерация физической модели. Шаг 5

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

Рисунок 1.19 - Физическая модель данных

Перед тем, как приступить к генерации БД, можно выбрать БД из списка предложенных в пункте меню Database Change, подпункте Database Platform. Далее можно приступить к генерации БД (рис. 1.20- 1.23).

Рисунок 1.20 - Запуск на генерацию БД

Рисунок 1.21- Мастер генерации БД. Шаг 1

Рисунок 1.22 - Мастер генерации БД. Шаг 2

Рисунок 1.23 - Мастер генерации БД. Шаг 3

Если нужного источника данных нет в выпадающем списке, то создаем его самостоятельно. Нажимаем на «Добавить» (рис. 1.24 – 1.27).

Рисунок 1.24 - Выбор источника данных пользователя

Рисунок 1.25 - Создание нового источника данных

Рисунок 1.26 - Установка драйвера ODBC

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

Рисунок 1.27 - Выбор базы данных

Задаем имя новому источнику данных (рис. 1.28).

Рисунок 1.28 - Установка драйвера ODBC

Схема данных по данной предметной области (схема данных Access) представлена на рис. 1.29

Рисунок 1.29 – Схема данных в ACCESS 2003

Как мы видим, схема данных состоит из семи таблиц и связей между ними.

1.6. Организация ввода данных в БД

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

Для запуска базы данных, необходимо ввести пароль, как показано на рис. 1.30

Рисунок 1.30. Форма для ввода пароля

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

Рисунок 1.31. Главная форма программы

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

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

• сбор данных;

• обработка данных;

• генерация данных;

• хранение данных;

• передача данных.

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

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

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

• вывод результатной информации на печать,

• вывод результатной информации на экран.

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

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

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

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

Создать главную кнопочную форму – это:

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

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

1.7. Организация корректировки БД

Изменение всех или некоторых значений в существующих строках выполняется с помощью оператора UPDATE. Он имеет следующий синтаксис:

UPDATE имя_таблицы

SET поле1=… , поле2=…

WHERE условие

После слова SET идет перечисление столбцов и значений, которые им необходимо присвоить. После WHERE – условие, по которому будут выбраны строки, подлежащие изменению. [2]

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

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

Из главной формы можно получить доступ к товарам, ввод/просмотр других сведений, просмотр отчетов, формы показаны на рис. 1.32-1.34.

Рисунок 2.24. Форма «Товары»

Рисунок 1.33. Форма «Ввод/просмотр других сведений»

Рисунок 1.34. Форма «Отчеты»

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

Пароль на базу данных: 16051972.

1.9. Реализация проекта в среде конкретной СУБД

Описание программного обеспечения

1 Структура ПО. Структура разработанной системы приведена на рис. 14.1, главы 14 и определена требованиями СУБД Access. В настоящей системе использованы следующие объекты данной СУБД – таблицы, запросы, формы, отчеты, макросы.

2. Основные функции ПО. Разработанная система имеет удобный пользовательский интерфейс (кнопочную форму). Система позволяет осуществлять:

• ввод и контроль справочной информации (справочник стран, справочник предприятий, справочник продукции, справочник поставщиков);

• ввод и контроль оперативной информации (договора, накладные);

• автоматизацию ввода и контроля информации;

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

• выдачу отчета "Анализ выполнения договорных обязательств поставщиками".

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