Разработка регламента выполнения процесса «Складской учет»(Анализ предметной области)

Содержание:

Введение

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

Цель данного курсового проекта – разработка регламента выполнения процесса «Складской учет».

Для достижения указанной цели определим ряд задач:

1. исследовать предметную область;
2. проанализировать внутренние бизнес-процессы организации складского учета;
3. сформулировать требования к разрабатываемому регламенту;
4. разработать модель бизнес-процессов организации;
5. разработать модель данных ИС складского учета;

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

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

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

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

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

В заключении сделаны выводы о работе и решенных задачах проекта.

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

В качестве программных средств были использованы: CA ERWin Process Modeler; CA ERWin Data Modeler; 1С: Предприятие 8.2.

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

1. 1 Разработка регламента выполнения процесса «Складской учет»

§1.1 Анализ предметной области

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

Будем рассматривать деятельность склада на примере фирмы «МетаФлекс», занимающейся продажей современных труб, различных подводок, систем пожаротушения. Структура организации представлена на рисунке 1.1.

Рисунок 1.1 – Структура организации «МетаФлекс»

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

• Отдел продаж;
• Отдел закупок;
• Отдел доставки;
• Бухгалтерия;
• Склад.

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

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

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

На заведующего складом возлагаются такие функции, как:

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

Кладовщик – специалист, выполняющий большинство складских операций: прием и отпуск товарно-материальных ценностей, проверка товарно-сопроводительных документов, ведение складской документации, и др.

Задачи кладовщика можно сформулировать следующим образом:

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

Рассмотрим взаимодействие работников склада более конкретно на схеме информационных потоков (рисунок 1.2).

Рисунок 1.2 – Схема информационных потоков

§1.2 Функциональные требования к разработке проекта системы складского учета

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

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

• Создание и ведение БД клиентов;
• Создание и ведение БД поставщиков;
• Автоматизация учета приходных, расходных документов;
• Автоматизация проведения учета текущего наличия товаров (инвентаризация);
• Автоматизация записи и осуществление хранения архива движения товаров на складе;
• Формирование необходимой отчетности о наличии товаров;
• Поддержание перспективы расширения ИС для большого числа пользователей.

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

§1.3 Разработка моделей бизнес-процессов системы складского учета

§1.3.1 Обоснование выбора инструментария разработки модели бизнес-процессов

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

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

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

Деятельность организаций девелопмента имеет специфику, которая не позволяет просто копировать традиционные методы информационного анализа и моделирования бизнес-процессов, известные в теории и на практике (методология ARIS, IDEF). Поэтому чрезвычайно актуальной становится задача объективного выбора адекватного Case-средства моделирования, позволяющего проводить дальнейшую модификацию в соответствии с принципиальными целями и задачами моделирования.

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

Рассмотрим модельные, функциональные, технологические характеристики CASE-систем:

ARIS - рассматривает предприятие как совокупность четырех взглядов (views): взгляд на организационную структуру

• взгляд на структуру функций
• взгляд на структуру данных;
• взгляд на структуру процессов.

ARIS позволяет составлять диаграмму целей, связывая процессы через цели с миссией компании. В результате после построения бизнес-модели получается комплексное видение компании: Цели - Процессы - Оргструктура - Данные - Продукты/услуги в виде отдельных, но связанных через объекты диаграмм. Это означает, что при изменении названия должности на одной диаграмме сразу корректируются названия во всех процессах, где она присутствует, и в оргструктуре.

При этом каждый из данных взглядов разделяется еще на три подуровня:

• описание требований;
• описание спецификации;
• описание внедрения.

ARIS предлагает рассматривать организацию с позиции 4-х аспектов, отображающих разные взгляды на предприятие, а также разную глубину этих взглядов. Для описания бизнес-среды предлагается использовать 85 типов моделей (обычно в практической деятельности применяется не более 6-7 типов моделей), каждая из которых принадлежит тому или иному аспекту. ARIS Toolset является, с одной стороны, достаточно сложной для освоения системой. С другой стороны, диаграммы бизнес-процессов в готовом виде понятны даже неподготовленным сотрудникам, это позволяет эффективно организовывать работу команд, не прибегая к тотальному обучению всех работающих над проектом сотрудников.

Business Studio разработана специально для максимально легкого создания бизнес-архитектуры. Помимо этого, она обеспечивает решение смежных задач, необходимых для обеспечения непрерывного развития компании. Таким образом, Business Studio поддерживает полный цикл создания эффективной системы управления компанией – «Проектирование - Внедрение – Контроль – Анализ», позволяя решать следующие задачи:

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

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

На основании приведенных сравнений было выбрано программное средство Business Studio, ключевые преимущества которой, принципиально отличаются от других аналогичных программных продуктов:

• Простота, удобство и высокая скорость освоения специалистами.
• Использование самых популярных нотаций моделирования бизнес-процессов, понятных сотрудникам без дополнительной подготовки: IDEF0, Процесс (Basic Flowchart), Процедура (Cross Functional Flowchart), BPMN 2.0, EPC.
• Интегрированность: в одном инструменте собраны все востребованные бизнесом методики и технологии: BSC/KPI, моделирование бизнес-процессов, имитационное моделирование, функционально-стоимостной анализ, поддержка СМК.
• Формирование на выходе конкретизированных регламентирующих документов, не требующих дополнительной доработки.
• Business Studio Portal, предоставляющий сотрудникам необходимую для работы информацию и вовлекающий их в процесс улучшения компании.
• Мощный Мастер отчетов, позволяющий формировать отчеты с использованием всех возможностей форматирования Microsoft Word и поддерживающий сложные выборки данных.
• Возможность расширения структуры данных с помощью модуля MetaEdit: создание собственных параметров (в т.ч. списков) и справочников.
• Возможность построения бесшовной системы управления благодаря тесной интеграции с ЕСМ-системой DIRECTUM. Поддержка стандарта XPDL для экспорта схем процессов в BPM-системы.

CA ERWin Process Modeler 7 — инструмент для моделирования, анализа, документирования и оптимизации бизнес – процессов. CA ERWin Process Modeler 7 можно использовать для графического представления бизнес-процессов.

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

CA ERWin Process Modeler 7 повышает бизнес-эффективность ИТ-решений, позволяя аналитикам и проектировщикам моделей соотносить корпоративные инициативы и задачи с бизнес-требованиями и процессами информационной архитектуры и проектирования приложений. Таким образом, формируется целостная картина деятельности предприятия: от потоков работ в небольших подразделениях до сложных организационных функций.

CA ERWin Process Modeler 7 эффективен в проектах, связанных с описанием действующих баз предприятий, реорганизацией бизнес-процессов, внедрением корпоративной информационной системы. Продукт позволяет оптимизировать деятельность предприятия и проверить ее на соответствие стандартам ISO 9000, спроектировать оргструктуру, снизить издержки, исключить ненужные операции и повысить эффективность.

CASE-средство верхнего уровня AllFusion Process Modeler (BPwin), поддерживает методологии:

• IDEF0 (функциональная модель);
• DFD (DataFlow Diagram);
• IDEF3 (Workflow Diagram).

Функциональная модель предназначена для описания существующих бизнес – процессов на предприятии (так называемая модель AS-IS «как есть») и идеального положения вещей – того, к чему нужно стремиться (модель ТО-ВЕ «как должно быть»). Методология IDEF0 предписывает построение иерархической системы диаграмм – единичных описаний фрагментов системы.

В данном проекте используется методология IDEF0.

§1.3.2 Разработка модели бизнес-процессов «как есть»

Построение модели ИС начинается с описания функционирования предприятия (системы) или отдельной ее части (в нашем случае это деятельность складского хозяйства) в целом в виде контекстной диаграммы (рисунок 1.3).

Рисунок 1.3 ‒ Контекстная диаграмма системы складского учета

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

• Информация о клиенте;
• Накладная на выдачу;
• Товар от поставщика;
• Документы на возврат товара;
• Сопроводительные документы;
• Возвращаемый товар.

Выходами для системы (Справа) являются:

• Выходные документы;
• Выданный товар;
• Списанный товар.

Механизмами управления системой (Сверху) являются:

• Должностные инструкции;
• Указания руководства;
• Законодательство РФ.

Ресурсами системы (снизу) являются:

• Складское оборудование;
• Персонал склада;
• Упаковочные материалы;
• Офисная техника и ПК;
• Информационные ресурсы.

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

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

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

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

§1.3.3 Разработка модели бизнес-процессов «как должно быть»

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

Рисунок 1.4 Диаграмма декомпозиции блока «Система складского учета»

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

Весь процесс деятельности склада можно подразделить на этапы:

• Подсистема приема товара (принятие товара по сопроводительным документам и передача его на хранение).

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

• Подсистема приема возврата (прием товара от покупателей).

Товар может поступать на склад не только от поставщиков, но и от покупателей, желающих вернуть товар по каким-то причинам.

• Подсистема отгрузки товара (выдача скомплектованного товара клиенту, либо возврат поставщику).

Данный этап подразумевает отгрузку клиенту товара, скомплектованного по отгрузочным документам либо отгрузка товаров поставщикам (если произошла ошибка при получении товаров).

• Хранение (основная и самая сложная функция склада, подразумевает все остальные действия с товаром, не описанные выше, например, комплектование, оформление документации на товар, списание).

Этап «Хранение» возьмем для последующей декомпозиции (рисунок 1.5).

Рисунок 1.5 Диаграмма декомпозиции блока «Подсистема хранения»

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

• Формирование отгрузочных документов (согласно оплаченному счету клиента).

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

• Складирование (непосредственное размещение товара на складе)

В зависимости от характера товара товар размещается на соответствующем складе. Предприятие может использовать основной склад и, например, дополнительный.

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

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

• Списание товара (списание и дальнейшая передача на утилизацию брака или испорченного товара с формированием документов о списании).

Этап «складирование» является наиболее интересным для дальнейшего рассмотрения (рисунок 1.6).

Рисунок 1.6 Диаграмма декомпозиции блока «Складирование»

Диаграмма складирования, в свою очередь подразделяется на пункты:

• Хранение на временной площадке (товар, прибывший от поставщика или возвращаемый клиентом).

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

• Складирование на основной склад (товары, прошедшие качественно – количественную проверку).

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

• Формирование документов по принятому товару (выходные документы).

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

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

• Диаграмма «Система складского учета» – первый уровень дерева узлов (top level activity);
• Диаграммы «Подсистема приема товара», «Подсистема приема возврата», «Подсистема отгрузки товара» и «Подсистема хранения» – второй уровень дерева узлов;
• Диаграммы «Формирование отгрузочных документов», «Складирование», «Комплектование» и «Списание товара» – третий уровень дерева узлов;
• Диаграммы «Хранение на временной площадке», «Складирование на основной склад», «формирование документов по принятому товару» - четвертый уровень дерева узлов.

Данного уровня декомпозиции достаточно для выполнения нашего курсового проекта.

Рисунок 1.7 Диаграмма дерева узлов

Так же, для более наглядного восприятия роли работников склада в деятельности организации, а так же определения места склада в CA Process Modeler была создана организационная диаграмма (рисунок 1.8). Для этого были созданы:

• Словарь групп ролей;
• Словарь ролей;
• Словарь ресурсов.

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

Рисунок 1.8 Организационная диаграмма

§1.4 Разработка модели базы данных системы складского учета

ERwin создает визуальное представление (модель данных) для решаемой задачи. Это представление может использоваться для детального анализа, уточнения и распространения как части документации, необходимой в цикле разработки. Однако, ERwin далеко не только инструмент для рисования. ERwin автоматически создает базу данных (таблицы, индексы, хранимые процедуры, триггеры для обеспечения ссылочной целостности и другие объекты, необходимые для управления данными).

В ERwin существуют два уровня представления и моделирования - логический и физический. Логический уровень означает прямое отображение фактов из реальной жизни. Например, люди, столы, отделы, собаки и компьютеры являются реальными объектами. Они именуются на естественном языке, с любыми разделителями слов (пробелы, запятые и т.д.). На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц.

Целевая СУБД, имена объектов и типы данных, индексы составляют второй (физический) уровень модели ERwin. ERwin предоставляет возможности создавать и управлять этими двумя различными уровнями представления одной диаграммы (модели), равно как и иметь много вариантов отображения на каждом уровне.

Объекты модели на данном уровне называются сущностями и атрибутами. Диаграмма сущность – связь (рисунок 1.9) содержит сущности и взаимосвязи, которые отражают основные закономерности предметной области.

Данные о сущностях разработанной модели данных представлены в таблице А.1 (Приложение А). Данные о выявленных связях между сущностями представлены в таблице А.2 (Приложение А). Связи «многие ко многим» в таблице А.3 (Приложение А).

Рисунок 1.9 ER – диаграмма модели базы данных

Модель данных, основанная на ключах (KB – модель), кроме сущностей и связей, включает в себя ключевые атрибуты сущностей: первичные (PK) и внешние (FK). Для определения первичных и внешних ключей были выявлены следующие закономерности:

1. Каждый сотрудник обладает своим уникальным кодом.
2. Каждый сотрудник может быть закреплен на выдачу товара по нескольким накладным.
3. Каждая накладная обладает своим уникальным кодом.
4. Каждая накладная может содержать несколько строк, указывающих на товары по накладной.
5. Каждая накладная содержит информацию о клиенте, на которого производится выдача товара.
6. Каждый клиент вносится в базу под своим уникальным кодом.
7. Каждый клиент может оформлять несколько накладных.
8. Каждый склад обладает уникальным кодом.
9. Один склад может быть прописан в нескольких накладных.
10. Каждая строка входит в состав определенной накладной.
11. Каждая строка содержит информацию о товаре по коду товара.
12. Каждый товар обладает своим уникальным кодом.
13. Каждый поставщик обладает своим уникальным кодом.
14. Каждый поставщик может поставлять множество товаров.

В результате формируем KB-модель (рисунок 1.10).

Рисунок 1.10 KB – диаграмма модели базы данных

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

Каждая из наших сущностей будет обладать своими атрибутами. Соответствие атрибутов и сущностей проведено в таблице А.4 (Приложение А). В таблице А.5 (Приложение А) отображены функциональные зависимости.

В результате формируется FA – модель, представлена на рисунке 1.2.8.

Рисунок 1.11 FA – модель базы данных информационной системы склада

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

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

Рисунок 1.12 T – модель базы данных информационной системы склада

Далее была разработана DBMS-модель в виде SQL-кода, представленного в приложении Б. Его интерпретация позволила получить схему базы данных в формате СУБД MS SQL Server на физическом уровне.

Заключение

В результате выполнения курсового проекта были выполнены задачи:

• исследована предметная область;
• проанализированы внутренние бизнес-процессы организации складского учета;
• разработана модель бизнес-процессов организации;
• разработана модель данных ИС складского учета;

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

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

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

Список литературных источников

1. Ческидов С.В. Проектирование информационных систем на основе структурного подхода: Практикум. – М.: МГПУ, 2010. – 93 с.
2. Ческидов С.В. «Методическая разработка для проведения лабораторных работ»: М.:МГПУ, 2014.
3. Интернет – портал по разработке конфигураций на платформе 1С: Предприятие www.1c-pro.ru.
4. Материалы и видео уроки по созданию конфигурации на платформе 1С: Предприятие www.1c-uroki.ru.
5. GLPI (Gestionnaire libre de parc informatique) – система инвентаризации компьютерной и оргтехники. [Электронный ресурс] – Режим доступа: http://wiki.dieg.info/glpi (дата обращения 10.02.2017).
6. Коданев, В.Л., Чискидов, С.В. Проектирование информационных систем: Практикум, ч.1. – М.: МГПУ, 2010. – 93 с.
7. Исаев, Г.Н. Проектирование информационных систем: Учебное пособие. – М.: Омега–Л, 2013. – 424 с.
8. Белов, В. В. Проектирование информационных систем: учебник для студ. учреждений высш. проф. образования / В. В. Белов, В. И. Чистякова; под ред. В. В. Белова. – М.: Издательский центр «Академия», 2013. – 352 с.
9. Коваленко, В. В. Проектирование информационных систем: учебное пособие для студентов вузов. – М.: Форум, 2012. – 319 с.

Приложение А

Т а б л и ц а А.1 – Сущности и их определения

Имя сущности	Определение
Сотрудник	Данные о сотрудниках
Накладная	Документ о складских операциях
Поставщик	Данные о поставщиках
Товар	Данные о товарах
Строки накладной	Данные в накладных
Склады	Данные о складах
Клиенты	Данные о клиентах

Т а б л и ц а А.2 – Связи между сущностями

Родительская сущность	Дочерняя сущность	Тип связи	Семантика связи от родительской к дочерней сущности
Клиенты	Накладная	Один-ко-многим (не идентифицирующая)	Указан
Сотрудники	Накладная	Один-ко-многим (не идентифицирующая)	Закреплен за
Склады	Накладная	Один-ко-многим (не идентифицирующая)	Указан
Поставщик	Товар	Один-ко-многим (не идентифицирующая)	Поставляют

Т а б л и ц а А.3 – Связи «многие-ко-многим»

Родительская сущность 1	Дочерняя сущность	Родительская сущность 2	Семантика связи
Накладная	Строки накладной	Товар	Состоит из / входит в состав

Т а б л и ц а А.4 – Соответствие сущностей и атрибутов

Имя сущности	Атрибут	Ключи	Шифр домена
Сотрудник	Код сотрудника	PK	D1
	Фамилия		D3
	Имя		D3
	Отчество		D3
	Должность		D3
	Телефон		D1
	Пол		D3
	Опыт работы		D3
Накладная	Код накладной	PK	D1
	Код сотрудника	FK	D1
	Дата накладной		D2
	Тип накладной		D3
	Код клиента	FK	D1
	Код склада	FK	D1
Поставщик	Код поставщика	PK	D1
	Наименование		D3
	Город		D3
	Реквизиты		D3
Клиенты	Код клиента	PK	D1
	Фамилия		D3
	Имя		D3
	Отчество		D3
	№ паспорта		D1
Склады	Код склада	PK	D1
	Наименование		D3
Товар	Код товара	PK	D1
	Код поставщика	FK	D1
	Наименование		D3
	Единицы измерения		D3
	Цена продажи		D1
	Цена покупки		D1
Строки накладной	Номер строки		D1
	Код накладной	FK	D1
	Код товара	FK	D1
	Количество		D1
	Стоимость		D1

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

Детерминанта	Функциональная часть
Код сотрудника	Фамилия, Имя, Отчество, Должность, Телефон, Пол, Опыт работы.
Код клиента	Фамилия, Имя, Отчество, № паспорта.
Код поставщика	Наименование, Город, Реквизиты.
Код накладной	Код сотрудника, Дата накладной, Тип накладной, Код клиента, Код склада.
Код склада	Наименование.
Код товара	Код поставщика, Наименование, Единицы измерения, Цена продажи, Цена покупки.

Т а б л и ц а А.6 – Домены атрибутов сущностей

Шифр домена	Наименование домена	Определение	Тип данных	Пример
D1	Порядковый номер	Целое число, принимает уникальные значения	integer	001
D2	Дата	ЧЧ.ММ.ГГГГ – дата , где ЧЧ – две цифры, число (от 01 до 31) ММ – две цифры, месяц (от 01 до 12) ГГГГ – четыре цифры, год (от 0000 до 9999)	date	10.01.2014
D3	Строка символов переменной длины	Множество символьных значений переменной длины не более 20 символов. Выбирается одно значение из указанного множества	varchar(20)	Складов Павел Викторович
D4	Булево	Тип данных, принимающий два возможных значения: истина (true) и ложь (false)	blob	true

1. Приложение Б

CREATE TABLE Clienti

( Kod_klienta integer NOT NULL ,

Familiya varchar(20) NULL ,

Imya char(18) NULL ,

Otchestvo char(18) NULL ,

№_pasporta integer NULL )

go

ALTER TABLE Clienti

ADD CONSTRAINT XPKКлиенты PRIMARY KEY CLUSTERED (Kod_klienta ASC)

go

CREATE TABLE Nakladnaya

( ID_Naklad integer NOT NULL ,

Data_Naklad datetime NULL ,

Tip_Naklad varchar(20) NULL ,

ID_Sotr integer NOT NULL ,

Kod_klienta integer NOT NULL ,

Kod_sklada integer NOT NULL)

go

ALTER TABLE Nakladnaya

ADD CONSTRAINT XPKНакладная PRIMARY KEY CLUSTERED (ID_Naklad ASC)

go

CREATE TABLE Postavshik

( ID_Postavshika integer NOT NULL ,

Name varchar(20) NULL ,

Gorod varchar(20) NULL ,

Rekvezit varchar(20) NULL)

go

ALTER TABLE Postavshik

ADD CONSTRAINT XPKПоставщик PRIMARY KEY CLUSTERED (ID_Postavshika ASC)

go

CREATE TABLE Skladi

( Kod_sklada integer NOT NULL ,

Naimenovanie varchar(20) NULL )

go

ALTER TABLE Skladi

ADD CONSTRAINT XPKСклады PRIMARY KEY CLUSTERED (Kod_sklada ASC)

go

CREATE TABLE Sotrudnik

( ID_Sotr integer NOT NULL ,

Familiya varchar(20) NULL ,

Imya varchar(20) NULL ,

Otchestvo varchar(20) NULL ,

Dolgnost varchar(20) NULL ,

Telefon integer NULL ,

Pol varchar(7) NULL ,

Opit_raboti varchar(max) NULL )

go

ALTER TABLE Sotrudnik

ADD CONSTRAINT XPKСотрудник PRIMARY KEY CLUSTERED (ID_Sotr ASC)

go

CREATE TABLE Stroki_Naklad

( ID_Naklad integer NOT NULL ,

ID_Tovara integer NOT NULL ,

Nomer_stroki integer NOT NULL ,

Kolichestvo integer NULL ,

Stoimost integer NULL )

go

ALTER TABLE Stroki_Naklad

ADD CONSTRAINT XPKСтроки_накладной PRIMARY KEY CLUSTERED (Nomer_stroki ASC,ID_Naklad ASC)

go

CREATE TABLE Tovar

( ID_Tovara integer NOT NULL ,

Name varchar(20) NULL ,

Ed_izmereniya varchar(20) NULL ,

Cena_prodagi integer NULL ,

Cena_pokupki integer NULL ,

ID_Postavshika integer NOT NULL )

go

ALTER TABLE Tovar

ADD CONSTRAINT XPKТовар PRIMARY KEY CLUSTERED (ID_Tovara ASC)

go

ALTER TABLE Nakladnaya

ADD CONSTRAINT R_2 FOREIGN KEY (ID_Sotr) REFERENCES Sotrudnik(ID_Sotr)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Nakladnaya

ADD CONSTRAINT R_8 FOREIGN KEY (Kod_klienta) REFERENCES Clienti(Kod_klienta)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Nakladnaya

ADD CONSTRAINT R_9 FOREIGN KEY (Kod_sklada) REFERENCES Skladi(Kod_sklada)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Stroki_Naklad

ADD CONSTRAINT R_3 FOREIGN KEY (ID_Naklad) REFERENCES Nakladnaya(ID_Naklad)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Stroki_Naklad

ADD CONSTRAINT R_4 FOREIGN KEY (ID_Tovara) REFERENCES Tovar(ID_Tovara)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go

ALTER TABLE Tovar

ADD CONSTRAINT R_1 FOREIGN KEY (ID_Postavshika) REFERENCES Postavshik(ID_Postavshika)

ON DELETE NO ACTION

ON UPDATE NO ACTION

go