Базы данных в Acсess

ВВЕДЕНИЕВ последние годы на территории г. Сургут произошли значительные перемены, которые не могли не затронуть область информатики и вычислительной техники.
Для оперативного, гибкого и эффективного управления предприятиями, фирмами и организациями различных форм собственности, телекоммуникационными средствами гражданского и военного назначения, информационно-вычислительной, экологическими, радиолокационными и радионавигационными системами широко внедряются системы автоматизированного управления, ядром которых являются базы данных (БД).
При большом объеме информации и сложности, производимых с ней операций, проблема эффективности средств организации хранения, доступа и обработки данных приобретает особое значение.
Учитывая важность и значимость баз данных в современной жизни, весьма серьезные требования предъявляются к квалификации специалистов, создающих приложения на их основе.
Предметная область – это часть реального мира, подлежащая изучению с целью организации управления и, в конечном счете, автоматизации.
Предметной областью разрабатываемой подсистемы является учёт горюче-смазочных материалов (в дальнейшем ГСМ).
Под ГСМ понимают автобензин, дизельное топливо, керосин, дизельные и автотранспортные масла, сжатый и сжиженный газ, используемые в качестве моторного топлива, а так же другие технические и специальные жидкости, используемые при эксплуатации транспортных средств (легковых и грузовых автомобилей, автобусов, микроавтобусов, тягачей, самосвалов и специальных автомобилей).
1. ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА СОЗДАНИЕ ПОДСИСТЕМЫ АВТОМАТИЗАЦИИ УЧЁТА ТОПЛИВА В УСЛОВИЯХ СЕТИ ЗАПРАВОК1.1 Назначение и цель создания подсистемыНастоящие техническое задание разрабатывается для автоматизации процесса по приходу и расходу ГСМ, которая в дальнейшем повысит эффективность работы персонала, а также автоматизирует соответствующий документооборот внутри организации.
Курсовой проект предполагает рассмотреть работу коммерческой организации, представляющая собой сеть АЗС, которая в свою очередь занимается продажей ГСМ.
Основная задача подсистемы является автоматизация процесса предоставления информации, которая хранится в БД АЗС. Хранимые данные в БД используется внутри предприятия и не распространяются третьим лицам, за исключением служб правоохранительных органов. Каждый работник сети АЗС обязан иметь свой профиль в базе данных так как БД учитывает множество факторов.
Основной целью разработки подсистемы является автоматизация учёта топлива в условиях организации. После внедрение подсистемы предполагается, что часть рутинной работы пользователей БД будет автоматизирована и исключаться некоторые недочёты при формировании различных документов. Будет разработан специальный учёт всех операций, который позволит вывести проведенную операцию на бумажный носитель.

1.2 Характеристика объекта компьютеризации
Сотрудники АЗС обладают правами заказа топлива на АЗС к которому работник привязан, а также заправка гражданских транспортных средств. Метод интеграция подсистемы в информационную систему представлена на рисунке 1.1

Рис. 1.1 – Метод интеграции подсистемы
Существующая информационная система в организации отличается от разрабатываемой. Это связано с тем, что версии программного обеспечения для создания базы данных разные. В проекте разрабатывается база данных MS Access 2016, в то время как на предприятии используется устаревшая СУБД MS Access. Для автоматизации кассового аппарата используется программное обеспечение 1С. Работа с клиентами и оформление клиентских карт берёт программное обеспечение, которое собственноручно разрабатывалось исключительно для предприятия.
Несколько баз данных основаны на различных архитектурах связаны между собой. Так специально разработанное ПО для клиентских карт взаимодействует с архитектурой СУБД.
Основным недостатком информационной системы является как раз подсистема, которая реализуется в курсовом проекте. В отличии от разрабатываемой подсистемы, в существующей подсистеме имеется ряд критических проблем. Поэтому работники привыкли заполнять бланки вручную, нежели полагаться на вычислительную технику.
В ходе детального расчета деятельности автозаправочной станции, можно отметить повышение эффективности работников после внедрения разрабатываемой подсистемы. Оптимизация рабочего места по заправке гражданских транспортных средств значительно улучшит пропускную способность автозаправочной станции, что позволит автоматизировать работу по учёту ГСМ на автозаправочной станции.
На территории г. Сургут в данный период времени существуют множество компаний, которые предоставляют услуги по заправке ГСМ. Системный подход к реализации той или иной функции разный, однако документооборот данного типа деятельности практически идентичный.
В качестве сравнения были использованы 2 подсистемы, которые также учитывают приход и расход ГСМ на АЗС. Первая подсистема «Управление продажами ГСМ» на АЗС «Чайка». Информационная система находится в открытом доступе без системы авторизации и реальных манипуляций с предприятием.
Исходя из просмотра рисунков 1.2 и 1.3 можно сделать выводы:
простая кнопочная форма;
быстрый отклик на действие;
относительно удобная система шифрования;
работающая система автоматизации.

Рис. 1.2 – Главная форма подсистемы по продаже ГСМ АЗС «Чайка»
Для реализации данной подсистемы использовались различные методы автоматизации. Основным недостатком подсистемы является ориентированный интерфейс, который не является удобным, а также форма по продажам не даёт какой-либо информации по мониторингу системы. Например: остаток топлива на АЗС не отображается (рис. 1.3).

Рис. 1.3 – Реализация кассового аппарата по продаже ГСМ на АЗС «Чайка»
Второй пример является информационной моделью реализованный с помощью СУБД MS Access (рис 1.4). Информационная система имеет ряд подсистем.
Из хороших качеств необходимо отметить:
приятный интерфейс;
быстрый отклик между формами;
понятный для восприятия информационный поток данных;

Рис. 1.4 – Главная страница ИС ЧП «Лебедев»

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

Рис. 1.5 – Подсистема заправки транспортных средств

В ходе анализа двух существующих подсистем было выявлено, что обе подсистемы имеют некоторые недостатки. Предполагаемая подсистема на стадии проектирования изначально исключит данные недочёты.
1.3 Требования к подсистеме в целомВсе серверные и клиентские данные должны быть полностью структурированы и обладать определенным набором правил. Таблицы должны храниться в закрытом виде. Вся необходимая информация должна извлекаться в формы, отчёты или запросы.
Данная информационная систем рассчитана на следующие функциональные подсистемы:
сбор информации с различных документов для последующего хранения в таблицах;
набор правил, проверок на ввод различной информации в поля таблицы;
приложения-формы под разные уровни доступа пользователей;
безопасное хранение, извлечение, сохранение, удаление данных с подсистемы.
Стандартные функции в подсистеме:
авторизация работника АЗС, который получает пользовательскую форму в зависимости от уровня допуска к базе данных:
поэтапное проведение заказа ГСМ в сети АЗС, которое затрагивает сразу несколько уровней доступа;
автоматизированное рабочее место оператора по продаже ГСМ на АЗС
мониторинг всей наиболее важной информации в системе на уровне администратора
вывод данных на бумажный носитель в структурированной форме;
служба поддержка в сети АЗС.
Подсистема должна располагаться в СУБД MS Access 2016 и корректно отображать пользовательские формы на мониторе. Разрабатываемая подсистема должна соответствовать всем требованиям информационной системы в более старых версиях СУБД MS Access. Использовать такие объекты взаимодействия с базой данных, которые позволят открываться на различных устройствах. Задать свойство главным элементам управления общепринятые параметры и правила оформления.
Разрабатываемая подсистема должна войти в панели информационной системы (администрирование, кассовый аппарат, служба обратной связи).
1.4 Требования к видам обеспеченияИнформационное обеспечение заключается в формирование понятного для рядового пользователя интерфейса.
Все данные должны храниться в отдельных полях, основные справочники должны быть вынесены в правый угол формы. Элементы управления по возможности должны находиться в конце последнего поля с заполняемой информацией (рис 1.6).

Рис. 1.6 – Форма стандартной панели управления информацией
В соответствии образцов необходимо разработать макеты для следующих документов:
– чек;
– документ о регистрации заказа №251 пп.21;
– отчёт по доставкам ГСМ на АЗС;
– лист сотрудников;
– график выхода на работу.
К требованиям надёжности необходимо, предусмотреть корректный ввод данных в поля. Организовать различные правила и ввести в эксплуатацию некоторые маски ввода на отдельные поля.
Должны быть предустановлены Word, Access. Для подсистемы выделяется минимальная конфигурация, которая состоит из: процессора Pentium, оперативной памяти 150 МБ и свободного места на диске 200 МБ. Система должна располагаться на ОС Windows 7 Enterprise.

2. ФУНКЦИОНАЛЬНАЯ СТРУКТУРА ПОДСИСТЕМЫ УЧЁТА АВТОМАТИЗАЦИИ ТОПЛИВА В УСЛОВИЯХ СЕТИ ЗАПРАВОК2.1 Функционально-структурная схема подсистемыФункциональная модель разрабатывается в соответствии решаемой задачей, которая предполагает использования программного обеспечения Ramus Educational. В функциональной модели нотации IDE0X A-0 описывается краткая организационная структура сети заправок.
Стадия планирования деятельности сети АЗС подразумевает разработку модели А-0, в которой описывается общее положение входных, выходных документов. За каждым процессом закрепляются пользователи системы, а также правила при совершении операции по закупке и продаже ГСМ.
Модель описывает входящие и выходящие потоки информации. Для поддержки функциональности модели добавлены пользователи для работы с базой данных и различные регламенты, которые в свою очередь обеспечивает соответствующий уровень доступа к базе данных.
В качестве входных данных деятельности сети АЗС выступают клиенты и документы. Сбор информации осуществляется занесением в базу данных сведений по закупке и продаже ГСМ. За сбор и обработку информации отвечают практически все пользователи системы. Администратор базы данных имеет доступ к занесению определенных данных, которые запрещено редактировать рядовому пользователю подсистемы. Выходная информация подразумевает документы, которые формируются при успешном проведении операции по заправке и заказу ГСМ. На выходе также можно получить отказ в проведении операции по продаже или закупки ГСМ. Это связано с максимально допустимым объёмом различного топлива на АЗС. Функциональная модель нотации IDE0X A-0 представлена на рисунке 2.1.

Рис. 2.1 – Функциональная модель А0

В соответствии с использованием ПО Ramus и построений функциональной модели нотации А0 входной информацией является:
данные о клиенте;
сведения о пользователях системы;
текстовая документация;
данные об объёме ГСМ на АЗС.
С правой стороны блока находится выходная информация подсистемы по учёту ГСМ:
Продажа ГСМ клиентам;
поставка ГСМ на АЗС;
обновление сведений об АЗС;
мониторинг учёта ГСМ на АЗС.
Сверху блока расположены регламенты, нормативные документы, правила использования подсистемы, которые использует подсистема. К ним относятся:
регламент по продаже ГСМ;
правила проведения закупки ГСМ;
административная панель.
Под блоком располагаются объекты, которые взаимодействуют с подсистемой:
оператор АЗС;
кассир АЗС;
администратор АЗС.
Для полного анализа предметной области используется функциональная модель нотации IDE0X A0 (рис 2.2). В схеме отображаются все этапы по деятельности учёта прихода и расхода ГСМ. Входные и выходные данные должны соответствовать каждому блоку. Каждый пользователь имеет отношение к одному или нескольким блокам поэтапного использования подсистемы.

Рис. 2.2 – Схема декомпозиции подсистемы
Декомпозиция состоит из 4 блоков, которые взаимодействуют и являются своего рода временным циклом между третьим и четвёртым блоком.
Первый блок «Предоставление прав пользователю» - авторизация в подсистеме, которая выдаёт определенные права и определяет роль пользователя в подсистеме.
Второй блок «Работа по приходу ГСМ» является промежуточным, который играет основную роль в закупках ГСМ на АЗС. Есть ряд пользователей, который имеет доступ к данному блоку.
Третий блок «Просмотр информации» формирует всю информацию в подсистеме. С помощью данного блока осуществляются манипуляции по формированию различной отчётности в подсистеме, а также мониторинг некоторых функций подсистемы.
Четвёртый блок «Расход СГМ на АЗС» формирует основную прибыль для сети АЗС. Благодаря данному блоку производится продажа ГСМ на автозаправочных станциях.
2.2 Описание процесса выполнения функции «Авторизация пользователей в подсистеме»Функция авторизации исключает несанкционированный доступ в подсистему (рис.2.3). Каждый пользователь подсистемы должен иметь определенный набор прав, а также должен быть закреплен к определенной панели. Один пользователь может иметь только одну функционирующую панель. На панели администрирования должны присутствовать элементы управления переключения между панелями оператора и кассового аппарата.

Рис. 2.3 – Декомпозиция функции «Авторизация пользователей в системе»
В случае успеха ввода логина и пароля, система выдаёт определенные права сотруднику АЗС, а также при существовании специальной панели перенаправляет на работу с ней.
2.3 Описание процесса выполнения функции «Осуществление закупки ГСМ на АЗС»Функция «Осуществление закупки на АЗС» должна осуществлять операцию добавления ГСМ с АЗС, а также просчитывать сумму во время каждой закупки ГСМ у поставщиков (рис. 2.5).

Рис. 2.4 – Декомпозиция функции «Осуществление закупки ГСМ»
Функция предназначена для кассира, который будет оставлять заявку на пополнения ГСМ на АЗС, а также отдельная форма под оператора, который будет проверять открытые заявки и определять сумму и поставщика ГСМ.

3. ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ПОДСИСТЕМЫ АВТОМАТИЗАЦИИ УЧЁТА ТОПЛИВА В УСЛОВИЯХ СЕТИ АЗС
3.1 Выбор средства управления данными
На просторах интернета существуют большое количество СУБД для использования как в серверном сегменте, так и в клиентской части. Развитие СУБД растёт с каждым годом только в лучшую сторону. Каждая СУБД предлагает набор функций, которой нет у другой. Все функции направлены для облегчение работы как разработчика, так и пользователя будущей системы. Сейчас можно отметить такие виды СУБД как Oracle Database, MySQL, MongoDB, MS Access, MariaDB, Percona Server, RavenDB и другие.
Сравниваются две СУБД: Microsoft Access и SQL Server.
Одна из главных различий между Access и SQL Server, заключается в том, что Access это программа, управляющая базой данных на стороне клиента. Это означает, что Access выполняется непосредственно на персональном компьютере пользователя, в то время как как SQL Server это системы, использующие сервер. Данная система хранит данные на высокопроизводительном компьютере-сервере, к которому обращаются с обычного ПК.
Другое важное различие между программой Access и серверными СУБД состоит в том, что Access предлагает единое решение для хранения и обработки данных. Серверные процессоры баз данных, такие как SQL Server, нацелены исключительно на хранение данных и пересылку этих данных на другие компьютеры, когда их запрашивают. При таком подходе приходится увеличивать ресурсы использования. Обычный пользователь не может напрямую редактировать базу данных, сохраняемую SQL Server. Вместо этого необходимо использовать еще одну программу, способную общаться с SQL Server и запрашивать нужную информацию. В большинстве случаев такая программа должна быть написана профессиональным программистом.
В таблице 3.1 будет приведен подробный анализ сравнения двух СУБД, которое позволит определить комфортность использования.
Таблица 3.1 – Сравнение MySQL и MS Access
Параметр MySQL Server Microsoft Access
Поддержка ответа БД + +
Хранимые процедуры + +
Скорость работы СУБД Быстрый Средний
Поддержка ОС Windows + +
Хранимые процедуры - +
Несколько типов таблиц + -
Протокол ODBC + +
Протокол JDBC + -
Каждая СУБД имеет плюсы и минусы использования. В ходе выбора СУБД для реализации проекта была выбрана MS Access. Этот выбор обоснован на следующих положительных факторах:
локальное управление БД;
удобный конструктор и мастер по созданию автоматизированной документации;
разработка легкого и понятного интерфейса для пользователя;
возможность быстро сортировать, группировать и отбирать данные по различному критерию;
быстрый доступ к программным модулям и макросам;
интеграция в различные операционные система
возможность синхронизации данных в таблицах;
возможность переноса структуры данных из MS Access в MySQL.
В соответствии с поставленной задачей выбирают СУБД. Если это веб-приложение, то целесообразно использовать MySQL Server, так как он имеет быстрый ответ на запрос клиента.
СУБД MS Access 2016 допускает использование кода Visual Basic, что позволяет создать авторизацию для пользователей и ограничить некоторые параметры использования базы данных. С помощью средства шифрования можно предотвратить чтение базы данных через другие средства и защитить ее паролем.
К основным недостаткам относятся использования VBA в MS Access 2016, так как это не специализированный язык программирования (у Microsoft Visual Basic 6.0 или VB.NET гораздо больше возможностей). Также MS Access 2016 не специализированная СУБД. Это означает, что все технические характеристики изложены в сети разработчиков Microsoft.
Целесообразно использовать MS Access 2016 в качестве БД для малых и с натяжкой для средних предприятий (в зависимости от задач и количества рабочих мест). Для большого предприятия MS Access 2016 целесообразнее использовать в качестве интерфейса БД.
3.2 Разработка моделей данныхВ соответствии с техническим заданием на реализацию функций должны использоваться объекты для хранения данных. В случае выбора СУБД, этими объектами хранения информации выступают таблицы. В проектирование таблиц необходимо смоделировать схему базы банных. Сущности базы данных приведены в таблице 3.2, а атрибуты сущностей представлены в таблице 3.3.


Таблица 3.2 – Сущности модели «Учёт ГСМ на АЗС»
№ Сущность Описание
1 Azs Сведения о точках АЗС
2 Monitor Информации об объёме ГСМ на АЗС
3 Obr Хранимые данные обратной связи
4 Postav Список поставщиков ГСМ
5 Status Справочник по системным статусам
6 Tb_user Информация о сотрудниках АЗС
7 Toplivo Существующие ГСМ на АЗС
8 Zak Список заказов ГСМ на АЗС
9 Zap Список продаж ГСМ на АЗС
Таблица 3.3 – Атрибуты сущностей
№ Сущность Атрибуты
1 Azs Id_azs, same_azs, sdress_azs, sost_azs
2 Monitor Id_monitor, azs_monitor, type_monitor, kol_monitor, cena_monitor
3 Obr Id_obr, time_obr, status_obr, tema_obr, text_obr, otv_obr, kotv_obr, email_obr
4 Postav Id_postav, name_postav, Contry_postav, Adress_postav, Tel_postav
5 Status Id_status, name_status
6 Tb_user Id_sotr, username, password, startForm, Fam_sotr, Otc_sotr, Dolsh_sotr, AZS_sotr
7 Toplivo Id_toplivo, name_toplivo, izmer_toplivo
8 Zak Id_zak, time_zak status_zak, type_zak, obj_zak, numazs_zak, Dost_zak, cena_zak, sum_zak, timeFin_zak
9 Zap Id_zap, time_zap, data_zap, numazs_zap, type_zap, kol_zap, kassir_zap, numavto_zap, itog_zap
Разработка модели данных в логической и физической нотации третубет использования дополнительного стороннего ПО. В качестве реализации моделей выбрано ПО Microsoft Visio.
Суть логической модели заключается в визуализации структуры подсистемы и отображения атрибутов в сущностях. Модель описывает предполагаемую предметную область (рис.3.1).

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

Рис. 3.2 – Физическая модель подсистемы ДП

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

Таблица 3.3- Связи между сущностями
Родительская сущность Дочерняя сущность Тип связи
Название Атрибут Название Атрибут Status Id_status Zak Status_zak Один ко многим
Pastav Id_postav zak Dost_zak Один ко многим
Toplivo Id_toplivo Zak Type_zak Один ко многим
Azs Id_azs Zak Numazs_zak Один ко многим
Toplivo Id_toplivo Zap Type_zap Один ко многим
Toplivo Id_toplivo Monitor Type_monitor Один ко многим
Monitor Id_monitor Zap Type_zap Один ко многим
Azs Id_azs Monitor Azs_monitor Один ко многим
КроссКурс Id_sotr Zap Zap_kassir Один ко многим
Asz Id_azs Tb_user Azs_sottr Один ко многим
Tb_user Id_sotr Obr Itv_obr Один ко многим
Описание физической модели подсистемы представлена в таблицах 3.4 – 3.12. Из полей убраны дублирующие название таблиц, то есть поле «id» в таблице «AZS» имеет полный вид «id_azs».

Таблица 3.4 – Структура таблицы «Azs»
№ Поле Тип Размер Маска/ проверка Обязательное поле Индексация
1 Id Счетчик 6 - + A_I
2 Same Короткийтекст 30 - + + не допускается
3 Sdress Длинный текст 100 - + -
4 Sost Короткий текст 30 - + -

Таблица 3.5 – Структура таблицы «Monitor»
№ Поле Тип Размер Маска/ проверка Обязательное поле Индексация
1 Id Счетчик 6 - + A_I
2 Azs Числовой 6 - + +
3 Type Числовой 6 - + +
4 Kol Числовой 6 =0 or >0 - -
5 Cena Денежный 6 >0 - -
Таблица 3.6 – Структура таблицы «Obr»
№ Поле Тип Размер Маска/ проверка Обязательное поле Индексация
1 Id Счетчик 6 - + A_I
2 Time Дата 10 99.99.0000 + -
3 Status Короткий текст 30 “Открыт”; “Закрыт” + -
4 Tema Короткий текст 100 - + -
5 Text Длинный текст 1000 - + -
6 Otv Длинный тектс 1000 - - -
7 Ksort Короткий текст 30 - + -
8 Kotv Числовой 10 >0 - -
9 Email Короткий текст 50 + -

Таблица 3.7 – Структура таблицы «Postav»
№ Поле Тип Размер Маска/ проверка Обязательное поле Индексация
1 Id Счетчик 6 - + A_I
2 Name Короткий текст 60 - + -
3 Country Короткий текст 40 - + -
4 Adress Длинный текст 300 - + -
5 Tel Короткий текст 20 \(999") "000\-00\-00;0;-: - -
Таблица 3.8 – Структура таблицы «Status»
№ Поле Тип Размер Маска/ проверка Обязательное поле Индексация
1 Id Счетчик 6 - + A_I
2 name Короткийтекст 30 - + +, не допускается
Таблица 3.9 – Структура таблицы «tb_user»
№ Поле Тип Размер Маска/ проверка Обязательное поле Индексация
1 Id Счетчик 6 - + A_I
2 Username Короткийтекст 10 - - +, не допускается
3 Password Короткийтекст 10 - - -
4 startForm Короткийтекст 20 - - -
5 Fam Короткийтекст 40 - + -
6 Name Короткийтекст 40 - + -
Таблица 3.10 – Структура таблицы «Toplivo»
№ Поле Тип Размер Маска/ проверка Обязательное поле Индексация
1 ID Счетчик 6 - + A_I
2 Name Короткийтекст 30 - + +, не допускается
3 izmer Короткийтекст 30 “л”;”м3” + -
Таблица 3.11 – Структура таблицы «Zak»
№ Поле Тип Размер Маска/ проверка Обязательное поле Индексация
1 Id Счетчик 6 - + A_I
2 Time Дата 10 99.99.0000 + 3 Status Числовой 6 “открыт”; “Закрыт”; “Процесс” + -
4 Type Числовой 6 - - -
5 Obj Числовой 6 >0 + -
6 Cena Денежный 6 >0 + -
7 Sum Числовой 6 >0 - -
8 TimeFin Дата 6 99.99.0000 + -
Таблица 3.12– Структура таблицы «Zap»
№ Поле Тип Размер Маска/ проверка Обязательное поле Индексация
1 Id Счетчик 6 - + A_I
2 Time Дата 10 09:00:00;0;_ + -
3 Data Дата 10 99.99.0000 + -
4 Numazs Числовой 6 - + -
5 Type Числовой 6 - + -
6 Kol Числовой 6 >0 + -
7 Kassir Числовой 6 - - -
3.3 Реализация базы данных
Подсистема автоматизированного учёта топлива на АЗС реализована средствами СУБД MS Access. В реализации хранения информации был задействован конструктор таблиц (рис. 3.3).

Рис. 3.3 – Конструктор таблицы «Zak» в MS Access
На панели конструктора указывается наименования поля, тип и необязательное поле для описания. Для каждого поля в отдельности настраиваются свойства (рис. 3.4) в зависимости от выбранного типа данных. Основными свойствами поля выступают: размер, формат, маска ввода, подпись, значение по умолчанию, правило проверки, сообщение об ошибке, обязательное поле, пустые строки и индексированное поле.

Рис. 3.4 – Свойства поля «time_zak» в таблице «AZS»

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

Рис. 3.5 – Пользовательская форма «ins_user»
В ходе реализации интерактивных панелей был задействован конструктор по созданию форм (рис 3.6). Данный выбор обоснован необходимостью отображения структурированной информации из нескольких таблиц на одной форме.

Рисунок 3.6 – Конструктор формы «ins_user»
Для работы с данными необходимо учесть фактор отбора информации по определенному критерию. В ходе реализации базы данных был задействован «Конструктор запросов», который позволяет группировать, отбирать, удалять, обновлять, добавлять данные таблиц (рис 3.7).

Рис. 3.7 – Конструктор запроса «FinZak»
После отбора информации пользователь попадает не в панель запроса, а на специально разработанную панель под запрос или отчёт, который позволит распечатать полученный результат.
После обработки информации возникает необходимость вывода данных на бумажный носитель. В качестве реализации подсистемы были задействованы отчёты (рис 3.8) и печатные формы (рис 3.9), которые настроены под форматы листов А4, А5.
В соответствии с действующими запросами, разрабатывается отчётность, которая используется для полного отображения той или иной информации в подсистеме.

Рис. 3.8 – Отчёт «Бланк заказа» в подсистеме

Рис. 3.9 – печатная форма «Чек»
3.3 Организация сбора и обработки информацииПодсистема по автоматизированному учёту топлива на АЗС должна иметь входные данные в виде текстовой информации. Обработка информации происходит за счёт работы в пользовательской формы, а также определенных запросов. Отображения информации предоставляется в двух видах: отчёты и формы отображения информации. Структура сбора и обработки информации представлена на рисунке 3.10.

Рисунок 3.10 – Организация сбора и обработки информации в подсистеме

4. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ПОДСИСТЕМЫ АВТОМАТИЗАЦИИ ТОПЛИВА В УСЛОВИЯХ АЗС4.1 Разработка специального программного обеспечения подсистемыАвтоматизированная подсистемы по учёту ГСМ на АЗС осуществляется за счёт реализации следующих программных модулей:
авторизация пользователей в подсистеме;
осуществления заправки на АЗС;
осуществления закупки ГСМ на АЗС;
мониторинг системы;
занесения информации в подсистемы;
редактирования данных;
удаление информации из подсистемы;
обратная связь.
Обобщенная схема всех модулей в подсистеме изображена на рисунке 4.1. Рисунок представлен в виде иерархии процессов подсистемы.

Рис. 4.1 – Схема программных модулей подсистемы
4.2 Описание программного модуля «авторизация пользователей в системе»Программный модуль авторизации обеспечивает переход на пользовательский интерфейс в зависимости от выбранной должности (рис 4.2).

Рис. 4.2 – Форма авторизации пользователя в подсистеме

Форма обладает свойством распознавать ошибки, которые допустил пользователь при вводе пароля. В случае, если пользователь не заполнил поля с логином и паролем, после нажатия кнопки «ОК» отобразиться сообщение, что есть пустые поля (рис 4.3). Другая ошибка может возникать в случаях отзыва прав на использования подсистемы. Например: пользователь вводит правильные данные, однако его нет в списках допуска (рис 4.4)

Рис. 4.3 – Наличие пустых полей на форме авторизации

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

Рис. 4.5 – Главная форма администратора

Форма авторизация является обязательной формой. Без преодоления барьера авторизации дальнейшая работа с подсистемой невозможна.
4.3 Описание программного модуля «Осуществления заправки на АЗС»Заправка ГСМ на коммерческой автозаправочной станции в сети АЗС осуществляется при помощи автоматизированной панели (рис 4.6). На панели заполняются данные поэтапно. При выборе АЗС в соответствующем поле, следующее поле с типом ГСМ отбирается по выбранному АЗС. Также в списке кассиров отображаются только тот персонал, который работает на выбранной АЗС. После выбора типа ГСМ и указание объёма ГСМ, производится вычисление итогов по оплате топлива.

Рис. 4.6 – Панель заправки транспортных средств
В соответствии с лимитированным объём ГСМ на АЗС и динамическим изменением данных, вводится ограничение на заправку клиентских машин. Система выдаст соответствующую ошибку в случае, если объем желаемой покупки превышает существующий запас ГСМ на АЗС (рис 4.7). После сообщения поле с объёмом ГСМ обнуляется.

Рис. 4.7 – Ошибка из-за превышения допустимого объёма

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

Рис. 4.8 - Печатная форма «Чек»
4.4 Описание программного модуля «осуществления закупки ГСМ на АЗС»Закупка ГСМ в сети АЗС происходит в несколько этапов, которые позволяют проводить мониторинг подсистемы.
Первый этап заключается в формировании заявки на получения ГСМ. На панели кассира располагается кнопка, где допускается оформления заявки на получения ГСМ (рис 4.9). Заявку можно оставить только в том случае, если объём заказанного типа ГСМ меньше 500 литров. Для заказа характерны заполнения всех полей. Система не позволит отправить заявку если хотя бы одно поле не заполнено.

Рис. 4.9 – Форма заявки на получения ГСМ
Оформленная заявка отправляется к оператору, где на панели открытых заказов (рис 4.10) осуществляется заполнение полей с поставщиком и ценой за 1 литр топлива. В конце операции выдаётся специальный бланк заказа (рис 4.11).

Рис. 4.10 – Панель открытых заказов

Рис. 4.11 - Бланк заказа
На третьем этапе кассир должен подтвердить получения ГСМ. После того как ГСМ было доставлено на АЗС и все документы оформлены. Кассиру необходимо окончить поставку ГСМ. Для этого он на панели кассира нажимает соответствующую кнопку и вводит номер заказа (рис 4.12).

Рис. 4.12 – Форма закрытия поставки ГСМ на АЗС.
4.5 Описание программного модуля «Мониторинг системы»
Мониторинг системы осуществляется за счёт динамического изменения информации в таблице «Monitor». Допускается вывод полного монитора ГСМ на АЗС, где будут выводиться структурированные данные по каждому АЗС (рис 4.13), а также вывод мониторинга по определенной точки автозаправочной станции в сети АЗС.

Рис. 4.13 – Полная информация по количеству ГСМ на каждом АЗС
При оформлении окрашивания поля в необходимый цвет были учтены следующие правила условного форматирования:
синий цвет при условии «значение = 1500»;
зеленый цвет при условии «значение между 1000 и 1499»;
желтый цвет при условии «значение между 500 и 999»;
красный цвет при условии «значение < 500».
4.6 Описание программного модуля «Обратная связь»Программный модуль обратной связи отвечает за взаимодействия операторов и других пользователей подсистемы. В случае необходимости восстановить пароль из-за утери или задать вопрос, пользователи системы обращаются в службу поддержки через специальное окно (рис 4.14).

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

Рис. 4.15 – Панель открытых вопросов

Будучи в панели открытых вопросов, оператор выбирает вопрос из поставленного списка и работает по нему. Реквизитами, которые должен заполнить оператор являются ответ и ФИО оператора. Оператор в праве удалить открытый вопрос, если тот является спамом. Оставленные вопросы с нарушением регламента по обращению в службу поддержки, также удаляются из подсистемы.
После успешного ответа на вопрос, появляется информативное сообщение, которое сообщает, что форма будет перезапущена. Обработанный вопрос после перезапуска получает значение с «Открытый» на «Решен» и пропадает из списка открытых вопросов.
ЗАКЛЮЧЕНИЕПодсистема разрабатывалась с целью облегчения работы по ведению учета ГСМ, а именно расчета нормативного использования топлива и оценке себестоимости.
Цели и задачи, которые были поставлены при создании данной базы, были выполнены. Интегрируемая подсистема облегчает работу администратора, кассира и оператора. Теперь процесс вычисления фактической нормы расхода топлива на автомобилях различных марок и работающих на разных видах топлива автоматизировано. Определена экономия или перерасход топлива, которые в дальнейшем будут определять приносят ли предприятию это прибыль или убыток. Также же упростился процесс оценки себестоимости. Теперь в краткие сроки возможно оценить себестоимость топлива и рассчитать все суммы, не боясь совершить ошибку при подсчетах.
Появилась возможность оперативно формировать отчеты по ГСМ за определенный промежуток времени.
В ходе работы были созданы таблицы, в которые вводилась вся информация, нужная для работы.
Так же были созданы отчеты, представляющие информацию в конечном виде. Отчеты готовы к распечатыванию их на листах, т.е. являются документом для отчетности о проделанной работе.
СПИСОК ИСПОЛЬЗОВАННЫХ ЛИТЕРАТУРНЫХ ИСТОЧНИКОВ1. Александр, Днепров Видеосамоучитель. Microsoft Access 2016 (+ CD-ROM) / Днепров Александр. - Москва: Огни, 2018. - 677 c.
2. Бекаревич, Юрий Самоучитель Access 2010 (+ CD-ROM) / Юрий Бекаревич , Нина Пушкина. - М.: БХВ-Петербург, 2011. - 432 c.
3. Кронан, Джон Microsoft Office Access 2016. Быстрые шаги / Джон Кронан и др. - М.: НТ Пресс, 2015. - 226 c.
4. Смирнова, О. В. Access 2010 на практике / О.В. Смирнова. - М.: Феникс, 2019. - 160 c.
5. Тимошок, Т. В. Microsoft Access 2016. Самоучитель / Т.В. Тимошок. - М.: Диалектика, 2014. - 352 c.
6. Гурвиц, Г. Microsoft Access 2010. Разработка приложений на реальном примере / Г. Гурвиц. - М.: БХВ-Петербург, 2010. - 496 c.
7. Кошелев, В. Е. Access 2016. Эффективное использование / В.Е. Кошелев. - М.: Бином-Пресс, 2017. - 590 c.
8. Мак-Дональд, Мэтью Access 2016. Недостающее руководство / Мэтью Мак-Дональд. - М.: Русская Редакция, БХВ-Петербург, 2017. - 784 c.
9. Официальный учебный курс Microsoft. Microsoft Office Access 2016 (+ CD-ROM). - М.: Эком, Бином. Лаборатория знаний, 2016. - 528 c.
10. Тимошок, Т. В. Microsoft Access 2016. Краткое руководство / Т.В. Тимошок. - М.: Вильямс, 2014. - 272 c.