Разработка базы данных с использованием средств Microsoft Access для автоматизации процедур учета и формирования заказов на предприятии ООО 'Озон'
Содержание
Введение
1.
Анализ и выбор метода решения задачи автоматизации системы учета заказов на
предприятии ООО «Озон»
1.1 Анализ
существующей на предприятии системы учета заказов
1.2
Инфологическая модель задачи автоматизации заказов
1.3
Анализ ключей сущностей проектируемой базы данных
1.4
Выбор методики и технических средств реализации базы данных
2.
Разработка базы данных по учету заказов на ООО «Озон» с использованием пакета
Microsoft Access
2.1
Процедура проектирования реляционной базы данных
2.2
Разработка и нормализация системы таблиц базы данных
2.3
Разработка форм для обработки информации в базе данных
2.4
Разработка механизма оформления заказов в базе данных
2.5
Разработка средств анализа в базе данных ООО «Озон»
Заключение
Список
использованной литературы
Введение
автоматизация заказ данный форма
Успешность деятельности любой организации во
многом базируется на правильном и адекватном построении информационной
инфраструктуры предприятия. Принципы ее построения зависят от ряда факторов,
среди которых сфера и специфика деятельности компании, ее цели, размеры. Так,
например, в настоящее время уже самые маленькие компании (с числом сотрудников
в несколько человек) имеют в той или иной форме корпоративную сеть для обмена
файлами между сотрудниками, но и в таких небольших компаниях эффективность
может быть значительно увеличена при умелом использовании необходимых в
настоящий момент информационных систем. Развитие информационных технологий
становится ядром преобразований в компании, а рынок информационных систем
остается одним из самых быстрорастущих, предлагая все новые варианты построения
информационной инфраструктуры. Следует также упомянуть, что формирование
информационной инфраструктуры компании - это одна из основных задач
современного информационного менеджмента.
В настоящее время можно отметить, что акцент в
развитии информационных технологий (далее сокращение ИТ) смещается в сторону
улучшения взаимоотношений с клиентами, и продолжает усовершенствоваться класс
интеллектуальных информационных технологий. Интеллектуальные программные
системы способны непрерывно извлекать новые знания и изменять свою структуру и
функции, развиваться и адаптироваться вместе с предприятием к решаемым задачам
и условиям внешней среды. Один из путей решения этой задачи - применение
мультиагентных систем (далее МАS - Multiagent Systems), получивших
стремительное развитие в последнее десятилетие. Технологии управления
взаимоотношениями с клиентами (Customer Relationship Management) в настоящее
время представляют собой удобный информационный инструмент и позволяют
выработать эффективную технологию работы с клиентами. На первый взгляд две
данные технологии находятся на разных полюсах, как по своей сложности, так и по
своей направленности и специфике. Однако при более детальном рассмотрении можно
сказать, что в перспективе их методологии могут быть рассмотрены как
взаимодополняющие.
Целью работы является разработка базы данных с
использованием средств Microsoft Access для автоматизации процедур учета и
формирования заказов на предприятии ООО «Озон», занимающемся оптовой и
розничной реализацией фармацевтической продукции.
Задачами работы являются:
- анализ системы документооборота на ООО «Озон»;
- построение инфологической модели учета
заказов;
- разработка даталогической модели системы учета
заказов на предприятии с использованием средств Microsoft Access;
- практическая разработка программного комплекса
учета и контроля заказов средств Microsoft Access;
- анализ надежности созданного программного
продукта;
- оценка экономической эффективности мероприятий
по внедрению на фирме разработанного программного комплекса.
1. Анализ и выбор метода решения задачи
автоматизации системы учета заказов на предприятии ООО «Озон»
.1 Анализ существующей на предприятии системы
учета заказов
ООО «Озон» - компания, специализирующаяся на
оптовой и розничной продаже фармацевтической продукции.
Объемы продаж имеют устойчивую тенденцию к
росту, постоянно расширяется география как клиентов, так и поставщиков
предприятия. В 2011 году было реализовано продукции на 244 млн. руб., что
составило 145600 выполненных заказов. Это на 8,6 % больше, чем в предыдущем,
2010 году.
Однако система работы с заказами и поставщиками
в настоящее время является довольно примитивной, каждый менеджер ведет учет и
контроль самостоятельно, используя те средства автоматизации, которые для него
являются наиболее подходящими. В частности, учет поставок и заказов в
некоторых случаях ведется с использованием совершенно не подходящего для этого
инструмента - редактора Microsoft Word, что, естественно, никак не способствует
повышению эффективности работы менеджеров. Единой базы данных по поступившим
заказам на предприятии нет, лишь в бухгалтерии можно найти более или менее
организованные сведения о поставщиках и покупателях, но эти сведения довольно
специфичны и никоим образом не могут служить основой для содержательного
анализа работы предприятия с точки зрения менеджмента.
Для решения этой задачи, прежде всего,
необходимо иметь четкую концепцию информационных потоков на ООО, связанную с
обслуживанием и регистрацией поступающих заказов. Рассмотрим общий алгоритм
работы менеджеров ООО «Озон» по обслуживанию заказов, который фактически никак
не зависит от того, в какой форме собираются и обрабатываются информационные
данные. Блок-схема алгоритма представлена на Рисунке 1.1:
В связи с ростом объемов заказов и необходимостью отражения всех
заказов в удобной для заинтересованных пользователей единообразной форме
руководством ООО «Озон» поставлена задача организации единой базы данных по
поставщикам и заказам (как выполненным, так и находящимся в работе),
позволяющей сохранять поступающую оперативную информацию по заказам, состоянию
склада, а также позволяющей проводить анализ накапливаемых данных, что должно
позволить прогнозировать динамику продаж и более четкое планирование работы с
поставщиками.
Наиболее слабыми местами в данной схеме работы
являются:
Проверка оперативным менеджером наличия товара
на складе. В настоящее время, после формирования заявки, оперативный менеджер,
ведущий поступивший заказ, вынужден самостоятельно обращаться на склад и
менеджер склада, используя имеющиеся только в его распоряжении данные по
складу, делает выводы о возможности немедленного выполнения заказа. В такой
ситуации промежуток между формированием заказа и заключением о сроках его
выполнения, получаемое менеджером, ведущим заказ, от менеджера склада, может
быть довольно значительным (до нескольких суток, если заказ формируется,
например, в предпраздничный день), что сейчас уже неприемлемо.
Выставление бухгалтерией счета заказчику
происходит по заявке ведущего заказ оперативного менеджера. Такая заявка может
поступить в бухгалтерию только после того, как менеджер убедится в выполнимости
заказа (товар есть на складе либо заказан и ожидается его поступление на склад
в ближайшее время). О поступлении товара на склад оперативный менеджер узнает
от менеджера склада и составляет заявку в бухгалтерию. Поскольку такая связь
между отправкой счета и движением товара по складу является опосредованной, то
также возможны существенные задержки в отправке счетов клиентам.
Наиболее слабым местом является процедура заказа
недостающих позиций у поставщиков. Менеджер склада выполняет эти операции
периодически, по мере накопления определенного количества недостающих позиций.
Выполнять эти действия более оперативно при существующих условиях невозможно,
поскольку отсутствует эффективный механизм формирования заказов поставщикам
продукции с определенным временным интервалом, например, ежедневно.
Итак, можно видеть, что существующая система
работы является недостаточно эффективной, существенно задерживающей обработку и
отправку полученных на ООО «Озон» заказов. Автоматизация работы и обеспечение
доступности информации в режиме реального времени для всех заинтересованных
исполнителей должно значительно повысить эффективность работы на предприятии.
.2 Инфологическая модель задачи автоматизации
заказов
Для обработки поступающих от клиентов заказов,
контроля состояния склада и формирования заказов поставщикам менеджеры ООО
«Озон» используют значительное количество информационных данных. В настоящее
время менеджеры по работе с клиентами зачастую собирают о клиентах (особенно
оптовых покупателях) довольно значительный объем данных, но можно выделить те
атрибуты, которые в обязательном порядке используются всеми менеджерами -
именно они и должны лечь в основу разрабатываемой базы данных предприятия по
учету заказов. Итак, как легко видеть из рисунка 1.4., стержневыми сущностями в
данной информационной системе являются: ПОСТАВЩИК; КЛИЕНТЫ; СОТРУДНИКИ
Нам также потребуется сущность ТОВАРЫ, которая
является обозначающей для сущности ПОСТАВЩИК.
Для характеристики сущности КЛИЕНТЫ используется
сущность ЗАКАЗ, поскольку заказ возникает только после того, как один из
клиентов оформит его на фирме. Эта же сущность используется для характиристики
и другой стержневой сущности - СОТРУДНИКИ, т.к. именно сотрудники выполняют
все действия, связанные с обслуживанием полученного заказ.
Между сущностями ТОВАРЫ и ЗАКАЗ существует
связь, являющаяся ассоциативной сущностью ЗАКАЗАНО. Она представлена связью
«многие - ко многим», поскольку один Заказ может содержать несколько
наименований Товаров, а один и тот же Товар входить в разные Заказы.
Концептуальная модель предметной области
представлена на рисунке 1.4.
1 м м 1
Рисунок 1.4. - Концептуальная модель задачи
учета заказов на ООО «Озон»
Далее необходимо выявить атрибуты сущностей и
ключи, наборы которые и лягут в основу разрабатываемой базы данных.
Итак, рассмотрим сначала сущность ПОСТАВЩИК.
Конечно, возможно связать с этой сущностью очень много атрибутов, но нам
следует выделить только те, которые касаются всех участников процесса продаж на
ООО «Озон». Таких атрибутов не так уж и много:
Название поставщика (все поставщики - фирмы или
частные предприниматели, имеющие фирменное наименование)
Адрес поставщика включает в себя адрес без
указания города и страны, поскольку город, область и страну целесообразно
выделить в качестве отдельных атрибутов для облегчения процедур анализа продаж)
Город поставщика
Область поставщика
Индекс поставщика
Страна поставщика
Телефон поставщика (с кодом страны или региона)
Факс поставщика (с кодом страны или региона)
Кроме того, целесообразно иметь уникальный код
Поставщика, поскольку теоретически названия (и другие атрибуты) могут и
совпадать, а нам необходимо точно и однозначно идентифицировать каждого
Поставщика. Код поставщика будет его девятым атрибутом.
Ключевым полем сущности разумно считать
уникальный код Поставщика.
Далее рассмотрим обозначающую сущность ТОВАРЫ.
Ей присущи следующие обязательные атрибуты:
Наименование товара
Единица измерения товара
Цена товара
Наличие товара на складе (данный атрибут должен
выражаться неотрицательным целым числом)
Возможность заказать товар у Поставщика (данный
атрибут проще всего представить в логической форме - поставки прекращены или
есть возможность заказа товара).
Представляется целесообразным для товаров
отображать в базе данных всех возможных поставщиков данного товара (ясно, что
один и тот же товар может быть заказан у нескольких поставщиков), при этом
товары, поступающие от различных поставщиков, считать различными. Поэтому
используем атрибут Код Поставщика, который, в соответствии с описанием атрибутов
сущности Поставщики, однозначно определяет экземпляр Поставщика.
Считая товар, заказываемый у различных
Продавцов, различным, вводим в качестве атрибута уникальный Код Товара. Этот
код является ключом сущности.
Рассмотрим стержневую сущность КЛИЕНТЫ. По сути,
это база клиентов, разместивших заказы на фирме. Атрибутами сущности являются:
Название клиента
Адрес клиента
Город клиента
Область клиента
Индекс клиента
Страна клиента
Телефон клиента (с кодом страны или региона)
Факс клиента (с кодом страны или региона)
Кроме того, целесообразно иметь уникальный код
Клиента, поскольку теоретически названия (и другие атрибуты) могут и совпадать,
а нам необходимо точно и однозначно идентифицировать каждого Поставщика. Код
поставщика будет его десятым атрибутом. Этот код является ключом данной
сущности.
Важной стержневой сущностью базы данных является
сущность СОТРУДНКИ, с помощью которой ведется база работников предприятия,
заносится вся необходимая информация о сотруднике. Необходимыми атрибутами
данной сущности являются:
Фамилия, имя и отчество сотрудника
Пол сотрудника
Должность сотрудника
Дата рождения сотрудника
Адрес сотрудника
Город сотрудника
Область сотрудника
Индекс сотрудника
Страна сотрудника (атрибуты 5-9 существенны,
поскольку сотрудники ООО «Озон» работают и в других городах и даже за рубежом)
Домашний телефон сотрудника (с кодом страны или
региона)
Мобильный телефон сотрудника (с кодом страны или
региона)
Общие сведения о сотруднике
Уникальный идентификационный номер сотрудника,
являющийся также и ключом данной сущности.
Сущность ЗАКАЗ является характеристикой
сущностей КЛИЕНТЫ и СОТРУДНИКИ. Её атрибутами являются:
Уникальный код клиента, разместившего заказ
Уникальный код сотрудника, обслуживающего заказ
Дата размещения заказа
Название получателя заказа (поскольку получатель
не всегда совпадает с клиентом, т.е. лицом, разместившим заказ)
Адрес получателя
Город получателя
Индекс получателя
Область получателя
Страна получателя
Кроме того, каждому заказу из сущности
целесообразно также присваивать уникальный идентификационный код
Последней сущностью, которую следует
проанализировать, является ассоциативная сущность ЗАКАЗАНО. Её атрибутами
являются:
Код заказанного товара
Цена товара в заказе
Количество товара в заказе
Предоставленная скидка
Каждому заказу необходимо присвоить уникальный
код Заказа, являющийся вместе с кодом заказанного товара ключом данной сущности
(поскольку в данном уникальном заказе возможно наличие нескольких заказанных
товаров, никогда, впрочем, не повторяющихся в рамках одного и того же заказа).
По результатам проведенного анализа легко
видеть, что все рассматриваемые сущности обладают уникальным кодом и этот код
является простым, т.е. содержащим только один атрибут сущности. Для того, чтобы
впоследствии эффективно работать с заявленными сущностями, необходимо точно
указать, каким типом данных выражается тот или иной атрибут сущности и каков
его размер при размещении в базе данных. Также важно для атрибутов установить,
обязательными ли они являются для данной сущности и возможны ли повторения для
данных атрибутов. Проведя анализ имеющихся записей у менеджеров, работающих с
клиентами и менеджера склада, можно дать соответствующие оценки. Итоговые
данные по сущностям, используемым в инфологической модели базы данных,
приведены в Приложении А. Модель на языке ЯИМ имеет следующий вид:
ПОСТАВЩИКИ(КодПоставщика, Название, Адрес,
Город, Область, Индекс, Страна, Телефон, Факс)
ТОВАРЫ (КодТовара, Наименование, КодПоставщика,
ЕдиницаИзмерения, Цена, НаСкладе, ПоставкиПрекращены) [ПОСТАВЩИКИ]
ЗАКАЗ (КодЗаказа, КодКлиента, КодСотрудника,
Дата