Дипломная работа - Автоматизация учета на предприятии
Подождите немного. Документ загружается.
№ докум. ПодписьИзм. Лист Дата
Лист
ВСЭИ.230100-06ДП33.04 ПЗ
1
Учет заключается в фиксации прихода и расхода товаров. Исходным
документом является Приходная накладная, в котором указываются дата
прихода, наименование товара, категория товара, поставщик, количество
штук товара. Выходным документом является расходная накладная, в
которой указываются дата выдачи товара, наименование клиента, товар, вес,
цена, количество, сумма.
Анализ по товару предполагает получение по запросам необходимой
информации. Это может быть различная информация о товарах, клиентах,
поставщиках. По запросу можно получить, например, следующую
информацию:
Список товаров по категории;
Поиск сведений о товаре по наименованию;
Поиск сведений о клиенте;
Поиск сведений о поставщиках по наименованию;
Продажи товаров за период;
Продажи по клиентам;
Товары с заканчивающимся сроком реализации;
Просроченный товар;
Остаток товара на складе;
Остаток товара по поставщику.
Проанализировав все данные, необходимо составить схему данных
рассматриваемой предметной области.
2.2. Проектирование модели в BPWin
Для проектирования информационной системы учета движения
товаров на складе используется программа BPwin 4.0, которая является
мощным инструментом для создания моделей, позволяющих анализировать,
документировать и планировать изменения сложных бизнес-процессов.
BPwin предлагает средство для сбора всей необходимой информации о
работе предприятия и графического изображения этой информации в виде
целостной и непротиворечивой модели.
№ докум. ПодписьИзм. Лист Дата
Лист
ВСЭИ.230100-06ДП33.04 ПЗ
1
BPwin поддерживает три методологии: IDEF0, DFD и IDEF3,
позволяющие анализировать бизнес с трех ключевых точек зрения:
С точки зрения функциональности системы. В рамках методологии
IDEF0 (Integration Definition for Function Modeling) бизнес-процесс
представляется в виде набора элементов-работ, которые взаимодействуют
между собой, а также показывается информационные, людские и
производственные ресурсы, потребляемые каждой работой.
С точки зрения потоков информации (документооборота) в системе.
Диаграммы DFD (Data Flow Diagramming) могут дополнить то, что уже
отражено в модели IDEF3, поскольку они описывают потоки данных,
позволяя проследить, каким образом происходит обмен информацией между
бизнес-функциями внутри системы. В тоже время диаграммы DFD оставляют
без внимания взаимодействие между бизнес-функциями.
С точки зрения последовательности выполняемых работ. И еще более
точную картину можно получить, дополнив модель диаграммами IDEF3.
Этот метод привлекает внимание к очередности выполнения событий. В
IDEF3 включены элементы логики, что позволяет моделировать и
анализировать альтернативные сценарии развития бизнес-процесса.
BPwin умеет проверять создаваемые модели с точки зрения синтаксиса
выбранной методологии, проверяет ссылочную целостность между
диаграммами, а также выполняет ряд других проверок, чтобы помочь создать
правильную модель, а не просто рисунок. При этом сохраняются главные
преимущества рисунка – простота создания и наглядность.
Как видно из контекстной диаграммы (рисунок 1), управляющая
информация входит в блок сверху (Должностные инструкции, ГОСТы), в то
время как входная информация (Информация о товаре, Информация о
клеинте, Заказа на поставку товара, Информация о поставщике), которая
подвергается обработке, показана с левой стороны блока, а результаты
(выход) показаны с правой стороны блока (Прайс-лист, Расходная накладная,
Отчеты). Механизм (Работники склада, Работники отдела сбыта, Работник
№ докум. ПодписьИзм. Лист Дата
Лист
ВСЭИ.230100-06ДП33.04 ПЗ
1
отдела поставок), который осуществляет операцию, предоставляется дугой,
входящий в блок снизу.
Рисунок 1. Контекстная диаграмма
Далее блок Учет движения товаров на складе разбивается на 4
процесса, которые представлены на декомпозиции процесса (рисунок 2):
Получение товара на склад;
Хранение товара;
Выдача товара;
Оформление заявки.
№ докум. ПодписьИзм. Лист Дата
Лист
ВСЭИ.230100-06ДП33.04 ПЗ
1
Рисунок 2. Диаграмма декомпозиции процесса Учет движения товаров
Блок Получение товара на склад разбивается еще на 3 процесса:
Ввод данных о поставщике; Проверка данных; Ввод данных о товаре.
Диаграмма декомпозиции процесса Получение товара на склад представлена
на рисунке 3.
№ докум. ПодписьИзм. Лист Дата
Лист
ВСЭИ.230100-06ДП33.04 ПЗ
1
Рисунок 3. Диаграмма декомпозиции процесса Получение товара на
склад
2.3. Логическое проектирование
Построение схемы данных выполняется в несколько этапов:
1) Извлечение информации из интервью с заказчиком, изучение
предоставленной информации и выделение сущности (объекты предметной
области, информация о которых подлежит хранению). Каждая сущность
имеет уникальный идентификатор и обладает свойствами:
обладать одним или несколькими атрибутами, которые либо
принадлежат этой сущности, либо наследуются через связи;
сущность обладает одним или несколькими ключами, однозначно
идентифицирующими каждый экземпляр;
может обладать любым количеством связей с другими
сущностями.
2) Моделирование связей. Связь – это поименованная ассоциация
между двумя сущностями, значимая в рассматриваемой предметной области.
Обычно каждый экземпляр одной сущности (родительской) ассоциируется с
№ докум. ПодписьИзм. Лист Дата
Лист
ВСЭИ.230100-06ДП33.04 ПЗ
1
произвольным числом экземпляров-потомков. Имя каждой связи между
двумя сущностями должно быть уникально, однако может повторяться в
пределах модели. Для каждой связи определяется степень и обязательность.
Связь всегда направляется от родительской сущности. Связи бывают
следующих типов:
1:1 (один к одному) – используется на верхнем уровне
иерархической модели данных;
1:М (один ко многим) – один экземпляр одной сущности
связывается с несколькими экземплярами второй сущности;
М:N (многие ко многим) – используется на начальной стадии
разработки диаграммы.
3) Определение атрибутов сущности. Атрибут – характеристика
сущности, значимая в рассматриваемой предметной области и предназначена
для классификации, идентификации или выражения состояния сущности.
Атрибут может быть описан или идентифицирован, при определении связи
между сущностями идентифицирующие атрибуты наследуются от
родительской сущности к потомку. Атрибут или их совокупность может
использоваться для уникальной идентификации каждого экземпляра
сущности (первичный ключ). Атрибут, являющийся первичным ключом,
должен располагаться в верхней части списка. Ни одна из частей ключа не
должна принимать значение 0, быть незаполненной или отсутствовать. Если
сущности связаны, то связь передает ключевой атрибут дочерней сущности,
и он называется внешним ключом (FK).
На рисунке 1 представлена схема базы данных, на которой видно, что в
существующей базе данных семь таблиц, так как в модели присутствуют
семь сущностей – это Товары, Группы товаров, Склад, Клиенты,
Поставщики, Приход товара, Расход товара. Также на рисунке описаны и все
атрибуты сущностей. Все сущности в модели связаны связью один ко
многим (1:М).
№ докум. ПодписьИзм. Лист Дата
Лист
ВСЭИ.230100-06ДП33.04 ПЗ
1
Рисунок 1. Схема базы данных
Сущность Клиенты и Товары должны быть связаны между собой, но
связь получается многие-ко-многим, так как несколько клиентов могут
купить один и тот же товар, а так же несколько наименований товара могут
быть проданы одному клиенту, но связи многие-ко-многим в базе данных
использовать не рекомендуется, поэтому вводится промежуточная сущность
Расход товара, которая связывается с сущностью Клиенты по ключевому
полю Код_клиента связью один-ко-многим. А сущность Товары связывается
с сущностью Расход товара по ключевому полю Код_товара связью один-ко-
многим.
Поставщики поставляют товар на склад. Один поставщик может
доставлять несколько видов товаров, а так же один товар может поставляться
несколькими поставщиками. Соответственно, снова получается связь многие-
ко-многим, чтобы избавиться от нее, вводится промежуточная сущность
Приход товара, которая соединяется с сущностью Поставщики и с
сущностью Товары связью один-ко-многим.
№ докум. ПодписьИзм. Лист Дата
Лист
ВСЭИ.230100-06ДП33.04 ПЗ
1
Сущность Группы_товаров и Товары связаны при помощи связи один-
ко-многим, так как одной группе может принадлежать несколько
наименований товаров.
Сущности Склад и Товар соединяются при помощи отношения один-
ко-многим, так как на одном складе может быть несколько наименований
товара.
Полученная схема будет служить основой для создания
информационной базы проектируемой системы.
2.4. Разработка структуры таблиц базы данных
Для физического представления данных следует создать базу данных,
включающую в себя общий файл *.mdb. Поля таблиц с указанием их
идентификаторов, типа данных и длины поля и ограничения целостности
приводятся ниже.
Таблица 1. Структура таблицы Товары.
Имя поля Тип поля Размер поля Ограничения
целостности
Код_товара Счетчик Длинное целое Primary Key
Код_категории Числовой Длинное целое Not Null
Наименовае_товара Текстовый 50 Not Null
Артикул Числовой Длинное целое Not Null
Страна_Происхождения Текстовый 50 Not Null
Единицы_Измерения Текстовый 10 Not Null
Вес(г) Числовой Длинное целое Not Null
Цена Денежный Авто Not Null
В_наличии Логический Авто Null
Сертификат Текстовый 50 Not Null
Срок_действия_до Дата/время Краткий формат
даты
Not Null
№склада Числовой Длинное целое Not Null
Срок_годности_товара Дата/время Краткий формат
даты
Not Null
Количество_товара Числовой Длинное целое Not Null
Таблица 2. Структура таблицы Клиенты
Имя поля Тип поля Размер поля Ограничения
целостности
Код_клиента Счетчик Длинное целое Primary Key
Наименование_клиента Текстовый 50 Not Null
ИНН Числовой Действительное Not Null
№ докум. ПодписьИзм. Лист Дата
Лист
ВСЭИ.230100-06ДП33.04 ПЗ
1
КПП Числовой Действительное Not Null
Юр_адрес Текстовый 50 Not Null
Адрес_доставки Текстовый 50 Not Null
Телефон Текстовый 50 Null
Осн_договор Текстовый 50 Not Null
Отсрочка_(дней) Числовой Длинное целое Not Null
Расчет_счет Текстовый 50 Null
Таблица 3. Структура таблицы Поставщики
Имя поля Тип поля Размер поля Ограничения
целостности
Код_поставщика Счетчик Длинное целое Primary Key
Наименов_поставщика Текстовый 50 Not Null
Адрес Текстовый 50 Not Null
Страна Текстовый 50 Not Null
Телефон Текстовый 50 Null
Условия_оплаты Текстовый 50 Not Null
Заметки Текстовый 50 Null
Таблица 4. Структура таблицы Группы товаров
Имя поля Тип поля Размер поля Ограничения
целостности
№группы Счетчик Длинное целое Primary Key
Категория_товара Текстовый 50 Not Null
Таблица 5. Структура таблицы Склад
Имя поля Тип поля Размер поля Ограничения
целостности
Код_склада Счетчик Длинное целое Primary Key
Наименов_склада Текстовый 50 Not Null
Таблица 6. Структура таблицы Приход товаров
Имя поля Тип поля Размер поля Ограничения
целостности
Дата Дата/время Краткий
формат даты
Not Null
Код_прихода Счетчик Длинное целое Primary Key
Код_товара Числовой Длинное целое Not Null
№группы_товаров Числовой Длинное целое Not Null
№ докум. ПодписьИзм. Лист Дата
Лист
ВСЭИ.230100-06ДП33.04 ПЗ
1
Код_поставщика Числовой Длинное целое Not Null
№документа Числовой Длинное целое Not Null
Количество_(шт) Числовой Длинное целое Not Null
Таблица 7. Структура таблицы Расход товаров
Имя поля Тип поля Размер поля Ограничения
целостности
Дата_выдачи Дата/время Краткий формат
даты
Not Null
Код_расчета Счетчик Длинное целое Primary Key
Код_клиента Числовой Длинное целое Not Null
Код_товара Числовой Длинное целое Not Null
Количество Числовой Длинное целое Not Null
В таблицах содержится информация о приходе и расходе товаров. При
изменении каких-либо данных в этих таблицах, информация автоматически
распространяется на всю базу данных и делает изменения в тех запросах, где
использовались измененные поля, то есть сохраняется целостность базы
данных. Так же таблицы позволяют пользователю выбирать нужное значение
поля из уже имеющихся, и не выбирать каждый раз заново информацию.
2.5. Разработка структуры информационной системы
Разработка структуры меню – это проектирование структуры
информационной системы.
На рисунке 1 приведена структура ИС.