Автоматизация системы учета заказов на предприятии

 















ДИПЛОМНЫЙ ПРОЕКТ

АВТОМАТИЗАЦИЯ СИСТЕМЫ УЧЕТА ЗАКАЗОВ НА ПРЕДПРИЯТИИ


Календарный график выполнения дипломного проекта

Наименование этапов дипломного проектаСрок выполнения этапов проектаПримечание1. Аналитическая часть. Анализ и выбор метода решения задачи "Автоматизация учета заказов на ООО "Кортереал" Разработка реляционной базы данных для учета заказов на ООО «Кортереал» 3. Разработка программного комплекса учета заказов на ООО «Кортереал» средствами Microsoft Access. 4 Анализ надежности и экономической эффективности разработанной системы учета заказов.5 Оформление дипломного проекта и сдача его на кафедру

РЕФЕРАТ


БАЗЫ ДАННЫХ, ACCESS, ИНФОЛОГИЧЕСКОЕ МОДЕЛИРОВАНИЕ, ОБЪЕКТ, НОРМАЛИЗАЦИЯ, ЯЗЫК SQL,ВИЗУАЛЬНЫЕ КОМПОНЕНТЫ, МОДЕЛИ ДАННЫХ, УЧЕТ.

Целью работы является разработка программного обеспечения для автоматизации процесса учета поступления и формирования заказов - базы данных, реализующей хранение данных, организацию доступа к ним и редактирование. Методом выполнения работы является построение реляционной базы данных средствами Microsoft Access. Результатом выполнения работы является создание программного обеспечения База данных учета заказов и его внедрение на предприятии ООО «Кортереал».

Область применения разработанного программного комплекса - коммерческая деятельность ООО «Кортереал», повышение эффективности организации информационных потоков на предприятии.


Содержание


Введение

Глава 1. Анализ и выбор метода решения задачи автоматизации системы учета заказов на предприятии ООО «Кортереал»

.1 Анализ существующей на предприятии системы учета заказов

.2 Принципы построения инфологических моделей

.3 Инфологическая модель задачи автоматизации заказов

.4 Анализ ключей сущностей проектируемой базы данных

.5 Выбор методики и технических средств реализации базы данных

Глава 2. Разработка базы данных по учету заказов на ООО «Кортереал» с использованием пакета Microsoft Access

.1 Процедура проектирования реляционной базы данных

.2 Разработка и нормализация системы таблиц базы данных

.3 Разработка форм для обработки информации в базе данных

.4 Разработка механизма оформления заказов в базе дынных

.5 Разработка средств анализа в базе данных ООО «Кортереал»

.6 Разработка системы отчетов базы данных

Глава 3. Оценка надежности и экономической эффективности системы учета заказов на ООО «Кортереал»

.1 Выбор метода оценки надежности базы данных ООО «Кортереал»

.2 Расчет надежности системы учета заказов на ООО «Кортереал»

.3 Оценка экономической эффективности внедрения системы учета заказов на ООО «Кортереал»

Заключение

Список использованной литературы

Приложения


Введение


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

обеспечивать получение общих и/или детализированных отчетов по итогам работы;

позволять легко определять тенденции изменения важнейших показателей;

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

выполнять точный и полный анализ данных.

Общепринятыми в настоящее время являются технологи, позволяющие использовать возможности других приложений, например, текстовых процессоров, пакетов построения графиков и т.п., и встроенные версии языков высокого уровня (чаще - диалекты SQL и/или VBA) и средства визуального программирования интерфейсов разрабатываемых приложений. Стандартом «де-факто» стала «быстрая разработка приложений» или RAD, основанная на «открытом подходе». Поэтому в одном ряду с «классическими» СУБД все чаще упоминаются языки программирования Visual Basic 4.0 и Visual C++, которые позволяют быстро создавать необходимые компоненты приложений, критичные по скорости работы, которые трудно, а иногда невозможно разработать средствами «классических» СУБД. Современный подход к управлению базами данных подразумевает также широкое использование технологии «клиент-сервер».

Приложение Microsoft Access является мощной и высокопроизводительной 32-разрядной системой управления реляционной базой данных (СУБД). Access - мощное приложение Windows. При этом производительность СУБД органично сочетаются со всеми удобствами и преимуществами Windows. Как реляционная СУБД Access обеспечивает доступ ко всем типам данных и позволяет одновременно использовать несколько таблиц базы данных. Access специально спроектирован для создания многопользовательских приложений, где файлы базы данных являются разделяемыми ресурсами в сети. В Access реализована надёжная система защиты от несанкционированного доступа к файлам. Целью данной дипломной работы является разработка базы данных с использованием средств Microsoft Access для автоматизации процедур учета и формирования заказов на предприятии ООО «Кортереал», занимающемся оптовой и розничной реализацией картографической продукции. Задачами, решаемыми при выполнении поставленной задачи, являются:

- анализ системы документооборота на ООО «Кортереал»;

- построение инфологической модели учета заказов;

- разработка даталогической модели системы учета заказов на предприятии с использованием средств Microsoft Access;

- практическая разработка программного комплекса учета и контроля заказов средств Microsoft Access;

- анализ надежности созданного программного продукта;

- оценка экономической эффективности мероприятий по внедрению на фирме разработанного программного комплекса.

Работа состоит из трех глав. Первая глава посвящена анализу системы документооборота на ООО «Кортереал», проведено обоснование выбора средств автоматизации работы, рассмотрены принципы и методы построения инфологических моделей, построена инфологическая модель среды учета и контроля заказов на фирме. Вторая глава посвящена практической реализации программного комплекса учета и контроля заказов средствами Microsoft Access. В третьей главе проведен анализ надежности разработанного программного комплекса и рассчитаны экономические показатели, достигаемые в результате внедрения комплекса в эксплуатацию.


Глава 1. Анализ и выбор метода решения задачи автоматизации системы учета заказов на предприятии ООО «Кортереал»


.1 Анализ существующей на предприятии системы учета заказов


Общество с ограниченной ответственностью «Кортереал» расположено в г. Ростове. Юридический адрес предприятия: г.Ростов, ул. Гражданская, 24 стр. 1. Численность работающего на предприятии персонала составляет 22 человека. ООО «Кортереал» занимается оптовой и розничной реализацией картографической продукции, в том числе это атласы, сборники топографических карт, судоходные карты, компьютерные диски и программы соответствующей тематики. Фирма сотрудничает с несколькими крупными издательствами в России и за рубежом, а также с крупными оптовыми поставщиками продукции соответствующей тематики. Фирма имеет в г.Ростове довольно крупный оптовый склад, на котором производится накопление и распределение товаров в соответствии с полученными заявками.

При этом более 90% продаж фирмы являются оптовыми, причем география продаж оказывается очень широкой, многие деловые партнеры ООО «Кортереал» находятся за рубежом. Среди постоянных клиентов фирмы несколько крупных судоходных компаний, геологоразведочные организации, туристические бюро и даже операторы сотовой связи (они приобретают электронные топографические карты с привязкой к существующим навигационным системам) и, конечно, книготорговые сети. Среди частных клиентов реализуется незначительная часть товарных запасов (менее 10%). Основной источник заказов частных лиц - Интернет-сайт ООО «Кортереал» и система приема заказов «Книга - Почтой».

Объемы продаж имеют устойчивую тенденцию к росту, постоянно расширяется география как клиентов, так и поставщиков предприятия. В 2011 году было реализовано продукции на 24,4 млн. руб., всего порядка 110 тыс. экземпляров книг, атласов и сборников карт, что составило 14560 выполненных заказов. Это на 8,6 % больше, чем в предыдущем, 2010 году.

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

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

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

Наиболее слабыми местами в данной схеме работы являются:

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

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

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

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


.2 Принципы построения инфологических моделей


Естественно, что проект базы данных надо начинать с анализа предметной области и выявления требований к ней отдельных пользователей (сотрудников организации, для которых создается база данных). Объединяя частные представления о содержимом базы данных, полученные в результате анализа запросов пользователей, проектировщик сначала создает обобщенное неформальное описание создаваемой базы данных. Это описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных, называют инфологической моделью данных [8, стр. 34].

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

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

Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по инфологической модели данных, называют даталогической моделью данных. [5, стр. 42-43].

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

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

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

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

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

Связь - ассоциирование двух или более сущностей.

При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь) [31, стр.39]. В них сущности изображаются помеченными прямоугольниками, ассоциации - помеченными ромбами или шестиугольниками, атрибуты - помеченными овалами, а связи между ними - ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово "много") и необходимое пояснение. Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип - связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В

Второй тип - связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

Как правило, определяются три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей - обозначения. [25, стр.76-77].

Стержневая сущность (стержень) - это независимая сущность.

Ассоциативная сущность (ассоциация) - это связь вида "многие-ко-многим" ("-ко-многим" и т.д.) между двумя или более сущностями или экземплярами сущности.

Ассоциации рассматриваются как полноправные сущности:

они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности;

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

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

Расширим также язык ER-диаграмм, введя для изображения характеристики трапецию.

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


.3 Инфологическая модель задачи автоматизации заказов


Для обработки поступающих от клиентов заказов, контроля состояния склада и формирования заказов поставщикам менеджеры ООО «Кортереал» используют значительное количество информационных данных. В настоящее время менеджеры по работе с клиентами зачастую собирают о клиентах (особенно оптовых покупателях) довольно значительный объем данных, но можно выделить те атрибуты, которые в обязательном порядке используются всеми менеджерами - именно они и должны лечь в основу разрабатываемой базы данных предприятия по учету заказов. Итак, как легко видеть из рисунка 1.4., стержневыми сущностями в данной информационной системе являются: ПОСТАВЩИК; КЛИЕНТЫ; СОТРУДНИКИ

Нам также потребуется сущность ТОВАРЫ, которая является обозначающей для сущности ПОСТАВЩИК.

Для характеристики сущности КЛИЕНТЫ используется сущность ЗАКАЗ, поскольку заказ возникает только после того, как один из клиентов оформит его на фирме. Эта же сущность используется для характиристики и другой стержневой сущности - СОТРУДНИКИ, т.к. именно сотрудники выполняют все действия, связанные с обслуживанием полученного заказ.

Между сущностями ТОВАРЫ и ЗАКАЗ существует связь, являющаяся ассоциативной сущностью ЗАКАЗАНО. Она представлена связью «многие - ко многим», поскольку один Заказ может содержать несколько наименований Товаров, а один и тот же Товар входить в разные Заказы (напомним, что товаром является не данный конкретный экземпляр книги, атласа и т.п., а абстрактное наименование книги или другого издания, поскольку для клиента безразлично, какой конкретный экземпляр он получит - их пользовательские свойства одинаковы).

Далее необходимо выявить атрибуты сущностей и ключи, наборы которые и лягут в основу разрабатываемой базы данных.

Итак, рассмотрим сначала сущность ПОСТАВЩИК. Конечно, возможно связать с этой сущностью очень много атрибутов, но нам следует выделить только те, которые касаются всех участников процесса продаж на ООО «Кортереал». Таких атрибутов не так уж и много:

Название поставщика (все поставщики - фирмы или частные предприниматели, имеющие фирменное наименование)

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

Город поставщика

Область поставщика

Индекс поставщика

Страна поставщика

Телефон поставщика (с кодом страны или региона)

Факс поставщика (с кодом страны или региона)

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

Ключевым полем сущности разумно считать уникальный код Поставщика.

Далее рассмотрим обозначающую сущность ТОВАРЫ. Ей присущи следующие обязательные атрибуты:

Наименование товара

Единица измерения товара

Цена товара

Наличие товара на складе (данный атрибут должен выражаться неотрицательным целым числом)

Возможность заказать товар у Поставщика (данный атрибут проще всего представить в логической форме - поставки прекращены или есть возможность заказа товара).

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

Считая товар, заказываемый у различных Продавцов, различным, вводим в качестве атрибута уникальный Код Товара. Этот код является ключом сущности.

Рассмотрим стержневую сущность КЛИЕНТЫ. По сути, это база клиентов, разместивших заказы на фирме. Атрибутами сущности являются:

Название клиента

Контактное лицо по заказу (особенно это важно при работе с крупными заказчиками, фирмами).

Адрес клиента

Город клиента

Область клиента

Индекс клиента

Страна клиента

Телефон клиента (с кодом страны или региона)

Факс клиента (с кодом страны или региона)

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

Важной стержневой сущностью базы данных является сущность СОТРУДНКИ, с помощью которой ведется база работников предприятия, заносится вся необходимая информация о сотруднике. Необходимыми атрибутами данной сущности являются:

Фамилия, имя и отчество сотрудника

Пол сотрудника

Должность сотрудника

Дата рождения сотрудника

Адрес сотрудника

Город сотрудника

Область сотрудника

Индекс сотрудника

Страна сотрудника (атрибуты 5-9 существенны, поскольку сотрудники ООО «Кортереал» работают и в других городах и даже за рубежом)

Домашний телефон сотрудника (с кодом страны или региона)

Мобильный телефон сотрудника (с кодом страны или региона)

Общие сведения о сотруднике

Уникальный идентификационный номер сотрудника, являющийся также и ключом данной сущности.

Сущность ЗАКАЗ является харакетристикой сущностей КЛИЕНТЫ и СОТРУДНИКИ. Её атрибутами являются:

Уникальный код клиента, разместившего заказ

Уникальный код сотрудника, обслуживающего заказ

Дата размещения заказа

Название получателя заказа (поскольку получатель не всегда совпадает с клиентом, т.е. лицом, разместившим заказ)

Адрес получателя

Город получателя

Индекс получателя

Область получателя

Страна получателя

Кроме того, каждому заказу из сущности целесообразно также присваивать уникальный идентификационный код

Последней сущностью, которую следует проанализировать, является ассоциативная сущность ЗАКАЗАНО. Её атрибутами являются:

Код заказанного товара

Цена товара в заказе

Количество товара в заказе

Предоставленная скидка

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

По результатам проведенного анализа легко видеть, что все рассматриваемые сущности обладают уникальным кодом и этот код является простым, т.е. содержащим только один атрибут сущности. Для того, чтобы впоследствии эффективно работать с заявленными сущностями, необходимо точно указать, каким типом данных выражается тот или иной атрибут сущности и каков его размер при размещении в базе данных. Также важно для атрибутов установить, обязательными ли они являются для данной сущности и возможны ли повторения для данных атрибутов [14, стр.112]. Проведя анализ имеющихся записей у менеджеров, работающих с клиентами и менеджера склада, можно дать соответствующие оценки. Итоговые данные по сущностям, используемым в инфологической модели базы данных, приведены в Приложении А. Модель на языке ЯИМ имеет следующий вид:

ПОСТАВЩИКИ(КодПоставщика, Название, Адрес, Город, Область, Индекс, Страна, Телефон, Факс)

ТОВАРЫ (КодТовара, Наименование, КодПоставщика, ЕдиницаИзмерения, Цена, НаСкладе, ПоставкиПрекращены) [ПОСТАВЩИКИ]

ЗАКАЗ (КодЗаказа, КодКлиента, КодСотрудника, Дата


ДИПЛОМНЫЙ ПРОЕКТ АВТОМАТИЗАЦИЯ СИСТЕМЫ УЧЕТА ЗАКАЗОВ НА ПРЕДПРИЯТИИ Календарный график выполне

Больше работ по теме:

КОНТАКТНЫЙ EMAIL: [email protected]

Скачать реферат © 2017 | Пользовательское соглашение

Скачать      Реферат

ПРОФЕССИОНАЛЬНАЯ ПОМОЩЬ СТУДЕНТАМ