Содержание:

Введение

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

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

Тема представленной работы: «Проектирование реализации операций бизнес-процесса «Продажи».

Цель проектирования заключается в повышении уровня информатизации предприятия в области учета продаж.

Объектом исследования был выбран магазин бытовой техники.

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

1 Аналитическая часть

1.1 Выбор комплекса задач автоматизации

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

Магазин создан в 2017 году. Организационная форма – общество с ограниченной ответственностью. В штате сотрудников находится 56 человек.

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

Стратегия развития магазина ориентирована на выполнение следующих задач:

1. Увеличение оборота товара в пять раз к концу 2020 года;
2. Увеличение доли рынка к концу 2020 года;
3. Поддержание рентабельности на уровне 15-20% путём пристального внимания к расходам и стоимости проданных товаров;
4. Стимулирование осведомлённости потенциальных клиентов через упоминания в печатных изданиях и интернет-ресурсах.
5. Открытие новых путей реализации продукции

Магазин имеет следующую организационную структуру (рисунок 1.1).

Рисунок 1.1 – Организационная структура магазина

Общее руководство организацией осуществляет генеральный директор.

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

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

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

В рамках представленной курсовой работы планируется автоматизация работы отдела продаж. К основным функциям отдела продаж относят:

1. Отпуск товара со склада;
2. Оформление заказов;
3. Ведение базы данных (товаров, категорий, производителей, клиентов);
4. Оформление расходных документов.

Рассмотрим некоторые технико-экономические показатели магазина, таблица 1.1.

Таблица 1.1 Технико-экономические показатели

№ п\п	Наименование характеристики (показателя)	Значение показателя на 01.11.2019
1.	Количество клиентов	1000
2.	Количество постоянных клиентов	500
3.	Количество товарных групп	300
4.	Количество брендов, с которыми сотрудничает компания	400
5.	Количество контрагентов, с которыми сотрудничает компания	100
8.	Количество сотрудников	25
9.	Количество филиалов в России	5
10.	Количество филиалов за рубежом	0
11.	Среднее количество продаж в год	2000

1.2 Характеристика существующих бизнес-процессов

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

В то же время, товаровед занимается ведением базы данных производителей, товаров и проделанных операций:

1. Ведет учет количества товара на складе;
2. Добавляет данные о новом товаре, либо редактирует данные уже имеющегося на складе товара;
3. Составляет отчеты о проделанных операциях.

На сегодняшний день все данные, которые менеджер по продажам использует в работе, хранятся в формате xls-файла. Редактирование информации осуществляется с помощью MS Excel.

С помощью CASE-средства BPWin построим модель бизнес-процесса «Продажа бытовой техники». Контекстная модель построена в методоолгии IDEF0. В IDEF0 модели процесса предоставляются в виде иерархической совокупности взаимодействующих функций (работ) и стрелок. Входная информация преобразуется в выходной сигнал, с помощью чего или кого регламентируется в выполнение определённой функции. Основным компонентом модели является блок и стрелки. Функциональный блок изображается в виде прямоугольника и обозначает собой некоторую конкретную функцию в рамках рассматриваемой системы. Второй элемент диаграммы - стрелка, она бывает четырёх типов: вход, выход, механизм, управление.

Главной компонентой диаграммы является «Продажа бытовой техники». Входные потоки для работы представляют собой: «Заказ», «Оплата заказа», «Информация о технике». На выходе формируются информационные потоки «Выполненный заказ», «Чек», «Расходная накладная» и «Прайс-лист». На диаграмме присутствуют также затунелированные (относящиеся ко всем сущностям декомпозиции) стрелки управления «Устав организации», «Нормативная документация» и стрелки механизмы «Менеджер» и «Товаровед».

Контекстная диаграмма изображена на рисунке 1.2.

Рисунок 1.2 – Контекстная диаграмма

Рисунок 1.3 – IDEF0, первый уровень декомпозиции

Модель DFD или диаграмма потоков данных представляет собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления- продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. В отличие от стрелок IDEF0, которые представляют собой жесткие взаимосвязи, стрелки DFD показывают, как объекты (включая данные) двигаются от одной работы к другой. Это представление потоков совместно с хранилищами данных и внешними сущностями делает модели DFD более похожими на физические характеристики системы - движение объектов (data flow), хранение объектов (datastores), поставка и распространение объектов. DFD декомпозиции второго уровня представлены на рисунках 1.4, 1.5.

Рисунок 1.4 – DFD, «Оформление заказа», второй уровень декомпозиции

Рисунок 1.5 – DFD, «Формирование прайс-листа», второй уровень декомпозиции

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

Рисунок 1.6 – IDEF3, «Выполнение заказа», второй уровень декомпозиции

1.3 Характеристика документооборота, возникающего при решении задачи

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

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

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

Узкое место 1:

Отсутствие структуры данных, единой системы хранения и обработки приводит к следующим проблемам:

1. Сложность оперативного получения необходимой информации о продажах и товарах;
2. Неверный расчет потребностей в товарах из-за некорректных или противоречивых данных;
3. Периодическое отсутствие необходимых товаров на складе;
4. Большие временные затраты на подсчет остатков и формирование потребностей.
5. Повторный ввод информации, данных о товарах и контрагентах.

Предложения:

1. Организовать учет продаж и остатков на административной панели разрабатываемого приложения.
2. Отражать динамику продаж мебели в административной панели разрабатываемого приложения.
3. Отражать остатки каждого товара на складе в административной панели разрабатываемого приложения
4. Организовать хранение данных о контрагентах в базе данных с возможностью редактирования этих данных в административной панели разрабатываемого приложения

Узкое место 2:

Сложность поиска товара.

1. При заполнении расходных, приходных накладных и других документов, приходится искать товар в огромном списке товаров склада.
2. При определении наличия товара на складе для презентации его клиенту также приходится искать товар в огромном списке товаров склада.

Предложения:

1. Отображать категории товаров с возможностью просмотра товаров выбранной категории.
2. Отображать информацию о товарах с возможностью фильтра и сортировки данных о товарах магазина.

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

Рисунок 1.7 - Схема обработки заявки

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

Для большей наглядности рассмотрим данные, представленные в таблице 1.2.

Таблица 1.2 – Трудозатраты на обработку заявок

Наименование работы	Трудозатраты
Сбор информации от клиента	15 мин
Поиск и выбор товара	15 мин
Расчет стоимости накладной	10 мин
Заполнение документов	10 мин
Оформление оплаты	10 мин
Итого:	60 мин

Если бы была возможность автоматической обработки заявок, то удалось бы существенно уменьшить число ошибок, а также ускорить этот процесс.

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

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

1.4 Обоснование проектных решений по информационному обеспечению

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

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

Классификатор является стандартным кодовым языком документов автоматизированных систем. Для нашей задачи классификаторами будут являться:

1. Код сотрудника;
2. Код клиента;
3. Номер накладной;
4. Код товара;
5. Код производителя;
6. Код категории.

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

Для разрабатываемой системы необходимо спроектировать следующие экранные формы:

1. Форма для работы с товарами;
2. Форма для работы с клиентами;
3. Форма для работы с сотрудниками;
4. Форма для работы с накладным;
5. Форма для предоставления статистической информации.

1.5 Обоснование проектных решений по программному обеспечению

Классификация СУБД по способу доступа к базе данных является самой распространенной. В файл-серверных СУБД файлы размещаются на файл-сервере. СУБД находится на каждом клиентском компьютере. Доступ СУБД к данным происходит через локальную сеть. Преимуществом такой СУБД является низкая нагрузка на процессор файл сервера. А вот недостатков будет больше, чем преимуществ. К ним относятся:

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

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

Клиент-серверные СУБД. Такую СУБД располагают на сервере вместе с базой данных. Доступ к базе данных происходит в монопольном режиме. Запросы на обработку данных осуществляются клиент-серверной СУБД. Недостатком этой СУБД является повышенное требование к серверу. А вот достоинств будет больше:

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

С появлением специализированных СУБД появилась возможность реализации модели доступа к удаленной базе данных — модели сервера баз данных. В этом случае ядро СУБД функционирует на сервере, прикладная программа на клиенте, а протокол обмена обеспечивается с помощью языка SQL. Такой подход по сравнению с файловым сервером ведет к уменьшению загрузки сети и унификации интерфейса «клиент-сервер».

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

В качестве архитектуры для проектирования ИС «Продажи бытовой техники» выбрана именно клиент-серверная архитектура.

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

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

Таблица 1.4– Условные обозначения

Условные обозначения
+	Указанная возможность присутствует
-	Указанная возможность отсутствует
+/-	Возможность поддерживается не полностью
-/+	Возможность поддерживается очень ограниченно
?	Нет данных
N/A	Постановка вопроса не применима к языку

Таблица 1.5 – Типы и структуры данных

Возможность	Язык
	C	C++	C#	JavaScript	Perl	PHP	VB.NET	Delphi
Кортежи	-	+/-	+	-	+	+/-	+/-	-
Алгебраические типы данных	-	-	-	N/A	N/A	N/A	-	-/+
Многомерные массивы	+	+	+	+/-	+/-	+/-	+	+
Динамические массивы	-	+	+/-	+/-	+/-	+/-	+	+
Ассоциативные массивы	-	+	+	+	+	+	+	+/-
Контроль границ массивов	-	+/-	+	N/A	N/A	+/-	+	+
Цикл foreach	-	+	+	+	+	+	+	+
Списковые включения	-	-	-/+	-	?	-	+	-
Целые числа произвольной длины	-	-	+	-	+	+/-	+	-
Целые числа с контролем границ	-	-	-	-	-	-	-	+

Таблица 1.6 – Компилятор/интерпретатор

Возможность	Язык
	C	C++	C#	JavaScript	Perl	PHP	VB.NET	Delphi
Open-source компилятор (интерпретатор)	+	+	+	+	+	+	+	+
Возможность компиляции	+	+	+	+	+	+	+	+
Bootstrapping	+	+	+	+	?	N/A	?	+
Многопоточная компиляция	+	+	-	?	?	?	+	?
Интерпретатор командной строки	-/+	+/-	+	+	+	+	+	+/-
Условная компиляция	+	+	+	-/+	+	+	+	+

Таблица 1.7 – Функциональные возможности

Возможность	Язык
	C	C++	C#	JavaScript	Perl	PHP	VB.NET	Delphi
Декларации чистоты функций	-	-	-	-	-	-	-	-
First class functions	-/+	+	+	+	+	-	?	+/-
Анонимные функции	-	+	+	+	+	+	+	+/-
Лексические замыкания	-	+	+	+	+	+	+	+/-
Частичное применение	-	+/-	?	+	-	-	?	?
Каррирование	-	+/-	+	+	+	+	-	+/-

Для выполнения данного дипломного проекта был выбран C#. В качестве интерактивной среды разработки использовалась Visual Studio, которая имеет весь необходимый функционал для создания графических интерфейсов пользователя.MicrosoftVisualStudio — линейка продуктов компании Microsoft, включающих интегрированную среду разработки программного обеспечения и ряд других инструментальных средств. Данные продукты позволяют разрабатывать как консольные приложения, так и приложения с графическим интерфейсом, в том числе с поддержкой технологии WindowsForms, а также веб-сайты, веб-приложения, веб-службы как в родном, так и в управляемом кодах для всех платформ, поддерживаемых Windows, WindowsMobile, Windows CE, .NET Framework и т.д.

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

Примерами СУБД, которые выполняют выше описанные функции как раз и являются MS Access и SQL Server. (Различных СУБД конечно намного больше, но мы рассматриваем лишь эти две). Сначала, как положено, выясним, что это за такие СУБД и где применяются.

Таблица 1.8 – Место применения

MS Access	SQL Server
Microsoft Access – это настольная система управления реляционными базами данных (СУБД), предназначенная для работы на автономном персональном компьютере (ПК) или локальной вычислительной сети под управлением семейства операционных систем Microsoft Windows. Обычно используется на малых предприятиях, для небольшого количества информации.	Microsoft SQL Server – система управления реляционными базами данных (СУБД). Основной используемый язык запросов – Transact SQL. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия.

Как видим, с точки зрения масштабности использования SQL Server 2005 превосходит MS Access, так как может хранить больший объем информации и использоваться на различных, как малых, так и крупных по масштабам предприятиях. MS Access же, зачастую применяется для обучения и для работы небольших организаций, так как она очень удобна в использовании и не требует каких-то особых знаний, времени на ее освоение требуется обычно мало.

Таблица 1.9 – Возможности СУБД

MS Access

SQL Server 2005

К основным возможностям СУБД Microsoft Access можно отнести следующие: Проектирование базовых объектов – двумерные таблицы с полями разных типов данных. Создание связей между таблицами, с поддержкой целостности данных, каскадного обновления полей и каскадного удаления записей. Ввод, хранение, просмотр, сортировка, изменение и выборка данных из таблиц с использованием различных средств контроля информации, индексирования таблиц и аппарата алгебры логики. Создание, модификация и использование производных объектов (запросов, форм и отчетов).

SQL Server 2005 представляет собой интегрированное решение по управлению и анализу данных, которое поможет организациям различного масштаба: Строить, развертывать и управлять промышленными приложениями, которые являются более безопасными, масштабируемыми и надежными. Увеличивать продуктивность информационных технологий, уменьшая сложность построения, развертывания и управления приложениями по работе с базами данных. Разделять данные между платформами, приложениями и устройствами для облегчения соединения внутренних и внешних систем. Контролировать стоимость, не жертвуя качеством выполнения, доступностью, масштабируемостью и безопасностью.

В качестве СУБД в учреждении используется Microsoft SQL Server. Microsoft SQL Server – одна из наиболее мощных СУБД архитектуры клиент-сервер. Эта СУБД позволяет удовлетворять такие требования, предъявляемые к системам распределенной обработке данных, как тиражирование данных, параллельная обработка, поддержка больших баз данных на относительно не дорогих аппаратных платформах при сохранении несмежного управления.

2 Проектная часть

2.1 Информационная модель и её описание

Информационная модель системы представлена на рисунке 2.1.

Рисунок 2.1 – Информационная модель системы

Опишем информационную модель:

• • 1. Авторизация. Администратор авторизуется в системе. Введенные администратором данные для авторизации проверяются в таблице сотрудников;
    2. Редактирование перечня пользователей. Администратор добавляет нового менеджера в систему. Добавляется запись в таблице сотрудников;
    3. Авторизация. Менеджер авторизуется в системе. Введенные менеджером данные для авторизации проверяются в таблице сотрудников;
    4. Редактирование перечня товаров. Добавляется запись в таблицу товаров;
    5. Оформление накладной. Менеджер создаёт новую расходную накладную. Выбираются товары из прайс-листа, вводится их количество, данные о товарах поступают из таблицы товаров;
    6. Печать накладной. Менеджер печатает расходную накладную;
    7. Печать чека. Менеджер печатает чек;

2.2 Характеристика нормативно-справочной, входной и оперативной информации

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

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

2.3 Характеристика результатной информации

Выходными данными системы являются:

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

2.4 Общие положения

Пользователями системы также могут быть менеджеры организации. Опишем основные функции, которые должна выполнять данная система:

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

Структурная схема информационной системы представлена на рисунке 2.2

Рисунок 2.2 – Структурная схема информационной системы

Таким образом, в состав информационной системы входят:

1. Клиентское приложение,
2. Подсистема учета справочников,
3. Подсистема учета контрагентов,
4. Подсистема ведения операций,
5. База данных.

Дерево функций для каждой подсистемы представлено на рисунках 2.3-2.5.

ы

Рисунок 2.3 – Дерево функций учет контрагентов

Рисунок 2.4 – Дерево функций ведение операций

Рисунок 2.5 – Дерево функций учет справочников

На рисунке 2.6 представлен сценарий диалога при редактировании данных таблицы БД.

Рисунок 2.6 – Сценарий диалога

2.5 Характеристика базы данных

ER-модель (уровень «сущность-связь») представлена на рисунке 2.7.

Рисунок 2.7  ER-модель

Сведения о типах сущностей приведены в таблице 2.1.

Таблица 2.1 – Сведения о типах сущностей

№	Имя сущности	Описание	Тип
1	Категория	Список категорий товаров магазина	Сильный
2	Клиент	Список клиентов	Сильный
3	Производитель	Список производителей	Сильный
4	Сотрудник	Список сотрудников магазина	Сильный
5	Покупатель	Список покупателей магазина	Сильный
6	Товар	Справочник товаров магазина	Слабый
7	Расход	Реестр расходных накладных	Слабый

Для устранения связей N:M была добавлена вспомогательная сущность «СоставРасхода».

Сведения о типах связей приведены в таблице 2.2.

Таблица 2.2 – Сведения о типах связей

Тип сущности	Тип связи	Тип сущности	Кардинальность
Категория	Не идентифицирующая	Товар	1:N
Клиент	Не идентифицирующая	Расход	1:N
Производитель	Не идентифицирующая	Товар	1:N
Товар	Не идентифицирующая	СоставРасхода	1:N
Сотрудник	Не идентифицирующая	Расход	1:N
Покупатель	Не идентифицирующая	Расход	1:N

Логическая FA-модель (уровень атрибутов) представлена на рисунке 2.8.

Рисунок 2.8 Логическая FA-модель

Разработанная модель находится в 3-й нормальной форме.

В качестве СУБД выбрана MS SQL Server.

Физическая FA-модель (уровень атрибутов) представлена на рисунке 2.9.

Рисунок 2.9 Физическая FA-модель

Описание модели приведено в таблицах 2.3-2.14.

Таблица «Категория» содержит сведения о категориях товара.

Таблица 2.3 – Структура таблицы «Категория»

Наименование	Тип поля	Размер поля	Ключ или индекс
КатегорияНомер	Int, автоинкремент	4	Первичный ключ
Наименование	varchar	40

Таблица 2.4 – Структура таблицы «Производитель»

Наименование	Тип поля	Размер поля	Ключ или индекс
ПроизводительНомер	Int, автоинкремент	4	Первичный ключ
Производитель	varchar	40

Таблица «Товар» содержит сведения о наименованиях товара.

Таблица 2.5 – Структура таблицы «Товар»

Наименование	Тип поля	Размер поля	Ключ или индекс
ТоварНомер	Int, автоинкремент	4	Первичный ключ
КатегорияНомер	Int	4	Внешний ключ (таблица «Категория»)
ПроизводительНомер	Int	4	Внешний ключ (таблица «Производитель»)
Наименование	varchar	40
Артикул	varchar	40
Цена	Int	4

Таблица «СоставРасхода» содержит сведения о составе расходной накладной.

Таблица 2.6 – Структура таблицы «СоставРасхода»

Наименование	Тип поля	Размер поля	Ключ или индекс
СоставНомер	Int, автоинкремент	4	Первичный ключ
ОстатокНомер	Int	4	Внешний ключ (таблица «Остаток»)
РасходНомер	Int	4	Внешний ключ (таблица «Расход»)
Количество	Int	4

Таблица «Расход» содержит сведения о расходных накладных магазина.

Таблица 2.7 – Структура таблицы «Расход»

Наименование	Тип поля	Размер поля	Ключ или индекс
ПриходНомер	Int, автоинкремент	4	Первичный ключ
СотрудникНомер	Int	4	Внешний ключ (таблица «Сотрудник»)
ПокупательНомер	Int	4	Внешний ключ (таблица «Покупатель»)
Сумма	Int	4
Дата	date	3
Статус	varchar	40	«Заказ» или «Продано»

Таблица «Сотрудник» содержит сведения о сотрудниках магазина.

Таблица 2.8 – Структура таблицы «Сотрудник»

Наименование	Тип поля	Размер поля	Ключ или индекс
СотрудникНомер	Int, автоинкремент	4	Первичный ключ
ФИО	varchar	40
Телефон	varchar	40

Таблица «Покупатель» содержит сведения о покупателях товара.

Таблица 2.9 – Структура таблицы «Покупатель»

Наименование	Тип поля	Размер поля	Ключ или индекс
ПокупательНомер	Int, автоинкремент	4	Первичный ключ
ФИО	varchar	40
Почта	varchar	40
Телефон	varchar	40

В SQL Server создали новую базу данных appliances, рисунок 2.10

Рисунок 2.10 – Создание базы данных appliances

Выполнили в SQL Server Management Studio, сгенерированный в ERWin, ddl-скрипт, Рисунок 2.11.

Рисунок 2.12 – Выполнение в SQL Management Studio ddl-скрипта

В результате выполнения ddl-скрипта получили таблицы базы данных, которые по своей структуре соответствуют физической модели данных, Рисунок 2.13.

Рисунок 2.13 – Таблицы базы данных appliances

Построили схему данных разработанной базы данных, рисунки 2.14, 2.15.

Рисунок 2.14 – Построение схемы данных

Рисунок 2.15 –Схема данных

В базе данных создали хранимую процедуру UPD_EXPSUM – процедура подсчета суммы расходной накладной. И три представления:

SumSaleMerch – сумма проданных товаров по наименованию,

SumSaleProducer – сумма проданных товаров по производителю,

SumSaleCategory - сумма проданных товаров по категории.

2.6 Структурная схема пакета

Приложение реализовано в среде разработки Microsoft Visual Studio на языке C#. Графический интерфейс пользователя реализован с использованием интерфейса программирования Windows Forms.

Для создания приложения в Visual Studio были использованы следующие компоненты:

1. Для вывода представлений в формы использовался компонент dataGridView;
2. Для управления таблицей использовался компонент BindingNavigator;
3. Для ввода и редактирования полей, значения которых берутся из других таблиц , используется компонент СomboBox;
4. orgDataSet - обеспечивает подключение формы к БД на сервере;
5. Lebel – для нанесения надписей;
6. GroupBox – группирующая рамка и другие компоненты.

При настройке подключения к базе данных в проекте, выбран источник данных, рисунок 2.16.

Рисунок 2.16 – Выбор источника данных

Настроенный источник данных представлен на рисунке 2.17.

Рисунок 2.17 – Настроенный источник данных

Структура модулей ИС представлена на рисунке 2.18.

Рисунок 2.18 - Структура модулей ИС

2.7 Описание программных модулей

Модуль "frmMain.cs" – главный модуль приложения, обеспечивает переход на все ниже описанные модули посредством меню, рисунок 2.19. На форме расположены компоненты для ввода данных авторизации (textbox1, textbpx2), кнопка для авторизации в системе (button1) и главное меню программы (menuStrip1).

Рисунок 2.19 – Главная форма frmMain.cs

"frmMerch.cs" отвечает за работу с таблицей «Товар», рисунок 2.20.

Рисунок 2.20 – Форма frmMerch.cs

На форме расположен компонент таблица datagridview, предназначенный для вывода данных таблицы «Товар».

Также на форме расположены компоненты кнопки для редактирования данных таблицы, рисунок 2.21.

Рисунок 2.21 – Кнопки редактирования

За соединение с базой данных отвечает компонент orgDataSet. За получение данных из таблицы «Товар» используются компоненты merchTableAdapter, merchBindingSource. За получение данных из таблицы «Категория» (выбор категории из выпадающего списка при редактировании записи о товаре) используются компоненты categoryTableAdapter, categoryBindingSource. За получение данных из таблицы «Производитель» (выбор категории из выпадающего списка при редактировании записи о товаре) используются компоненты producerTableAdapter, producerBindingSource. За перемещение по записям таблицы отвечает компонент bindingNavigator.

"frmWorker.cs" отвечает за работу с таблицей «Сотрудник». Для редактирования и отображения данных таблицы базы данных на форме используются компоненты аналогичные компонентам формы "frmMerch.cs".

"frmClient.cs" отвечает за работу с таблицей «Покупатель». Для редактирования и отображения данных таблицы базы данных на форме используются компоненты аналогичные компонентам формы "frmMerch.cs".

"frmProducer.cs"отвечает за работу с таблицей «Производитель». Для редактирования и отображения данных таблицы базы данных на форме используются компоненты аналогичные компонентам формы "frmMerch.cs".

"frmClient.cs" отвечает за работу с таблицей «Клиент». Для редактирования и отображения данных таблицы базы данных на форме используются компоненты аналогичные компонентам формы "frmMerch.cs".

"frmExpense.cs" отвечает за работу с таблицами «Расход» и «СоставРасхода», рисунок 2.22.

Рисунок 2.22 – Форма frmExpense.cs

На форме расположены два компонента таблицы datagridview, они предназначены для вывода данных основной таблицы «Расход» и вспомогательной таблицы «СоставРасхода», которая фильтруется по номеру приходной накладной при выборе записи в основной таблице. Таким образом, отображается состав приходной накладной.

Также на форме расположены компоненты кнопки для редактирования данных основной таблицы, проведения накладной на склад и печати накладной, рисунок 2.23. И кнопки для работы с вспомогательной таблицей, рисунок 2.24.

Рисунок 2.23 – Кнопки для работы с основной таблицей

Рисунок 2.24 – Кнопки для работы с вспомогательной таблицей

За соединение с базой данных отвечает компонент orgDataSet. За получение данных из таблиц используются компоненты TableAdapter, BindingSource. За перемещение по записям таблицы отвечает компонент bindingNavigator.

"frmStat1.cs" отвечает за вывод статистики продаж товаров по категориям. Статистика выводится с помощью компонента chart.

"frmStat2.cs" отвечает за вывод статистики продаж товаров по наименованиям. Статистика выводится с помощью компонента chart.

"frmStat3.cs" отвечает за вывод статистики продаж товаров по производителям. Статистика выводится с помощью компонента chart.

2.8 Контрольный пример реализации проекта и его описание

По запуску приложения на экран выводится главная форма (логин и пароль для авторизации «admin», «master»), рисунок 2.25.

Рисунок 2.25 – Главная форма

Редактирование и просмотр данных о производителях представлен на рисунке 2.26.

Рисунок 2.26 – Форма «Производители»

Редактирование и просмотр данных о товарах осуществляется на формах «Товары», «Категории», рисунках 2.27- 2.28.

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

Рисунок 2.28 – Форма «Категории»

Редактирование и просмотр данных о контрагентах осуществляется на формах «Сотрудники», «Покупатели», рисунки 2.29- 2.30.

Рисунок 2.29 – Форма «Сотрудники»

Рисунок 2.30 – Форма «Покупатели»

Редактирование и просмотр данных о накладных осуществляется на формах «Продажи», рисунок 2.31. При обновлении данных (кнопка «Обновить») подсчитывается сумма накладной.

Рисунок 2.31 – Форма «Продажи»

Печатная форма накладной представлена на рисунке 2.32.

Рисунок 2.32 – Печатная форма «Расходная накладная»

Статистика продаж представлена на рисунках 2.33-2.35.

Рисунок 2.33 – Статистика продаж по категориям

Рисунок 2.34 – Статистика продаж по наименованию

Рисунок 2.35 – Статистика продаж по производителям

Заключение

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

В ходе выполнения курсовой работы был спроектирован пользовательский интерфейс для базы данных «Продажа бытовой техники».

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

Результатами разработки являются:

- информационное обеспечение ИС в формате СУБД MS SQL Server;

- пользовательский интерфейс ИС, включающий экранные формы для работы со справочными, оперативными данными и отчетными данными;

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

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

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

Реализация системы проводилась с использованием инструментальных средств Visual Studio. в сочетании с СУБД MS SQL Server. При написании программы основное внимание было уделено удобству работы пользователя и построению дружественного интерфейса.

Приложение 1

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Динман М. С++. Освой на примерах. — Спб.: BHV-CПб, 2016. — 384 с.
2. В.Г. Елиферов, В.В. Репин. Процессный подход к управлению. Моделирование бизнес-процессов. – М.:Манн, Иванов и Фербер, 2013
3. Павловская Т.А. C/C++ Программирование на языке высокого уровня. — Спб.: Питер, 2015. — 464 с.
4. Лафоре Р. Объектно-ориентированное программирование в С++ (Object-Oriented Programming in C++, 4/e). — 4-е изд. — Спб.: Питер, 2016. — 928 с.
5. Виктор Зиборов «C# 2010 на примерах» Спб.: БХВ-Петербург Год издания: 2010
6. Дэн Рамел «C# .NET. Справочник программиста» Издательство: Эком Год издания: 2014
7. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. – Приемы объектно-ориентированного проектирования. Паттерны проектирования. – Спб.: Питер, 2011. – 368 с.
8. Грэхем Иан Объектно-ориентированные методы. Принципы и практика = Object-Oriented Methods: Principles & Practice. — 3-е изд. — М.: «Вильямс», 2014. — С. 840.
9. Петцольд, Ч. Программирование для Microsoft Windows на C++ В 2-х томах Том 1. /Ч. Петцольд. Пер. с англ. М.: Издательский дом «Русская редакция»,2012. – 576 с.
10. Петцольд, Ч. Программирование для Microsoft Windows на C++. В 2-х томах. Том 2. /Ч. Петцольд. Пер. с англ. М.: Издательский дом «Русская редакция»,2012. – 624 с.
11. Роберт Виейра «Программирование баз данных в Microsoft SQL Server», г. Москва, изд. «Диалектика», 2012 г.
12. Астахова И. Ф. «СУБД: язык SQL в примерах и задачах», г. Москва, изд. «Физматлит», 2011г.
13. Вендров А.М. Проектирование программного обеспечения экономических информационных систем. – М.: Финансы и статистика, 2012.
14. Глушаков С. В., Ломотько Д. В. Базы данных, 2012. 415 с.
15. Голицына О. Л., Максимов Н. В., Попов И. И. Базы данных: Учебное пособие. – М.: ФОРУМ: ИНФРА-М, 2011. 268 с.
16. Смирнова Г. Н., Сорокин А. А., Тельнов Ю. Ф. Проектирование экономических информационных систем, 2012.
17. Мишинин А. И. Теория экономических информационных систем, М.: Финансы и статистика, 4-е издание 2007.
18. Петров В.Н. Информационные системы. Спб.: Питер, 2011.