Файл: Проектирование реализации операций бизнес-процесса « Складской учет».pdf

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

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

ГЛАВА 3. Проектная часть

3.1 Информационное обеспечение комплекса задач

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

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

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

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

• структурный;
• объектно-ориентированный.

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

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

SADT (Structured Analysis and Design Technique) - модель в нотации SADT представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм;

DFD (Data Flow Diagrams) - диаграммы потоков данных. Диаграммы DFD обычно строятся для наглядного изображения текущей работы системы документооборота организации. Как правило, диаграммы DFD используют в качестве дополнения модели бизнес-процессов, выполненной в SADT;

ERD (Entity-Relationship Diagrams) - диаграммы "сущность-связь".

Методология SADT (Structured Analysis and Design Technique). Описание системы с помощью SADT называется моделью. В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка - сама методология SADT. Графический язык SADT обеспечивает структуру и точную семантику естественному языку модели. Графический язык SADT организует естественный язык вполне определенным и однозначным образом, за счет чего SADT и позволяет описывать системы, которые до недавнего времени не поддавались адекватному представлению [17 стр. 19].

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

Диаграммы потоков данных DFD (Data Flow Diagrams) являются основным средством моделирования функциональных требований проектируемой системы. С их помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель таких средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Главная цель построения иерархического множества DFD заключается в том, чтобы сделать требования ясными и понятными на каждом уровне детализации, а также разбить эти требования на части с точно определенными отношениями между ними.

Модель Сущность-Связь ERD (Entity-Relationship Diagrams) — это модель данных, позволяющая описывать концептуальные схемы. Она предоставляет графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета - моделью данных, то есть средством описания моделей данных [21 стр. 14].

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

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

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

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

Описание входной оперативной информации.

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

Для решения задач по учету товаров используется информация, которая находится в базе MS Access и содержит:

1) для автомобилей:

- регистрационный номер;

- марка;

- модель;

- тип кузова;

- год выпуска;

- пробег;

- коробка передач;

- тип двигателя;

- объём двигателя;

- привод;

- цена;

2) для мототехники:

- регистрационный номер;

- вид мототехники;

- марка;

- модель;

- год выпуска;

- цена;

3) для запчастей и комплектующих:

- номер запчасти;

- тип товара;

- наименование;

- описание;

- цена.

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

3.1.3.1 Характеристика инфологической модели БД

На этапе инфологического проектирования базы данных строится инфологическая модель предметной области, которая должна отражать семантику (смысл взаимосвязи объектов) предметной области. Инфологическая модель строится не для отдельного объекта, а отображает классы объектов и связи между ними. Диаграмма, отражающая связи объектов предметной области, называется диаграммой ER-типа (так как Entity – сущность, Relationship – связь).

Выделим основные сущности:

- сущность Avto

- сущность Moto

- сущность Zapchasti

- сущность ProdAvto

- сущность ProdMoto

- сущность ProdZap

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

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

Рисунок 3.1 Инфологическая модель БД Автоматизация складского учета материальных ценностей

Сущность Zapchasti содержит информацию о запчастях и комплектующих, имеющихся на складе. Сущность ProdAvto содержит информацию о проданных автомобилях на предприятии ООО «Сфера». Сущность ProdMoto содержит информацию о проданной мототехнике на предприятии. Сущность ProdZapchasti хранит информацию о проданных запчастях и комплектующих.

3.1.3.2 Характеристика даталогической модели БД

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

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

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

В результате получили следующие отношения:

R1 Avto (РегНомер, Марка, Модель, ТипКузова, ГодВыпуска, Пробег, КПП, ТипДвигателя, ОбъемДвигателя, Привод, Цена);

R2 Moto (РегНомер, ВидМототехники, Марка, Модель, ГодВыпуска, Цена);

R3 Zapchasti (НомерЗапчасти, ТипТовара, Наименование, Описание, Цена);

R4 ProdAvto (РегНомер, Марка, Модель, Цена);

R5 ProdMoto (РегНомер, ВидМототехники, Марка, Модель, Цена);

R6 ProdZapchasti (НомерЗапчасти, ТипТовара, Наименование, Описание, Цена).

Данные отношения уже находятся в 3 НФ.

Даталогическая модель БД Автоматизация складского учета материальных ценностей представлена на рисунке 3.2.

Рисунок 3.2 Даталогическая модель БД Автоматизация складского учета материальных ценностей

Для физического проектирования базы данных будем использовать СУБД Microsoft Access 2003. Данная СУБД является самой распространенной и установлена практически на каждом домашнем компьютере. MS Access поддерживает язык запросов SQL, разнообразные формы и отчеты. В Access много средств для создания приложений, даже без знания языка программирования. Данная СУБД обеспечивает нормальное функционирование базы данных на локальном компьютере.

Выполним физическое проектирование в среде СУБД Microsoft Access 2003. Поименуем таблицы и атрибуты, определим типы данных и размерность атрибутов. В таблицах определим ключевые поля. Результаты работы представлены ниже на рисунках.

На рисунке 3.3 представлена структура таблицы Avto.

В данной таблице хранится информация об автомобилях, имеющихся на складе ООО «Сфера».

Рисунок 3.3 Структура таблицы Avto

В данной таблице хранится информация о мототехнике, имеющейся на складе ООО «Сфера».

На рисунке 3.4 представлена структура таблицы Moto.

Рисунок 3.4 Структура таблицы Moto

На рисунке 3.5 представлена структура таблицы Zapchasti.

Рисунок 3.5 Структура таблицы Zapchasti

В данной таблице хранится информация о запчастях и аксессуарах, имеющихся на складе ООО «Сфера».

На рисунке 3.6 представлена структура таблицы ProdAvto.

В этой таблице хранится информация о проданных автомобилях.

Рисунок 3.6 Структура таблицы ProdAvto

На рисунке 3.7 представлена структура таблицы «ProdMoto».

В этой таблице хранится информация о проданной мототехнике.

Рисунок 3.7 Структура таблицы ProdMoto

На рисунке 3.8 представлена структура таблицы ProdZapchasti.

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

Рисунок 3.8 Структура таблицы ProdZap

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

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

• Отчёты о товарах, имеющихся на складе;
• Отчёты о проданных товарах;
• Договора купли-продажи;
• Товарные чеки.

На рисунке 3.9 представлена форма с отчетом об автомобилях на складе.

Рисунок 3.9 Форма с отчетом об автомобилях на складе

На данной форме представлен отчет об автомобилях на складе ООО «Сфера», данные которых используются из таблицы Avto. Сформированный отчет можно распечатать, или сохранить в файл формата *.pdf.

На рисунке 3.10 представлена форма с отчетом о мототехнике на складе.

Рисунок 3.10 Форма с отчетом о мототехнике на складе

На данной форме представлен отчет о мототехнике на складе ООО «Сфера», данные которых используются из таблицы Moto. Сформированный отчет можно распечатать, или сохранить в файл формата *.pdf.

На рисунке 3.11 представлена форма с отчетом о запчастях и аксессуарах на складе.