Файл: Проектирование реализации операций бизнес-процесса Продажи.pdf

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

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

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

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

Цель курсовой работы – проектирование реализации операций бизнес-процесса «Продажи».

Исходя из поставленной цели необходимо решить такие основные задачи:

– рассмотреть основные определения теории бизнес-процессов и баз данных;

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

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

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

Основные методы исследования: декомпозиция, анализ бизнес-процесса «Продажи», связанных с хранением данных в табличном виде.

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

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

1.Теоретические основы теории баз данных и бизнес-процессов

1.1. Основные понятия о моделировании бизнес-процессов

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

Бизнес-процесс – это последовательность действий (подпроцессов), которая направлена на получение определенного результата, ценного для некоторого предприятия.[3]

Наилучшим подходом построения систем для управления является управление некоторыми потоками работ и процессами, составляющими характеристику деятельности предприятия.

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

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

Понятия бизнес-процесса лежит в основе специального процессного подхода к синтезу и анализу деятельности организации.

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

Ключевыми понятиями в бизнес-процессах являются:[1]

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

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

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

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

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

Для моделирования бизнес-процессов необходимо использовать специальные языке моделирования.

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

Язык моделирования – это одна из существующих нотаций, например, графических, использующуюся для моделирования структуры, потоков и разных процессов в ИС. Такая нотация может включать в себя совокупность разных графических сущностей, объектов, которые могут быть применены при построении модели. То есть, при моделировании ИС данная нотация выступает своеобразным синтаксисом языка [1].

1. IDEF0 (Integration Definition for Function Modeling) применяется для задач создания разных функциональных моделей ИС, которые способны корректно отображать функции системы, а также ее структуру.

Сама нотация IDEF0 является этапом развития графического языка моделирования SADT, использовавшегося при описании функциональных ИС.

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

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

верхняя сторона применяется для задания управляющих действий (Control);
левая сторона применяется для определения входных потоков;
правая сторона применяется для задания результатных потоков работы;
нижняя сторона применяется для задания исполнителей [9].

Рис. 1. Пример функционального блока в IDEF0

2. IDEF3 (Integrated DEFinition for Process Description Capture Method) – это нотация которая выступает в качестве средств для описания разных технологических процессов, что имеют место для конкретного предприятии. Содержит набор свойств и графических объектов по работы сценариев развития ИС. Сценарием, в рассматриваемой нотации, принято называть формальное описание последовательностей для модификации различных объектов в рамках процессов [4].

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

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

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

Рис. 2. Образец IDEF3 диаграммы

3. DFD (Data Flow Diagram) – нотация, что организует корректное описание разных выходов системы при входном на систему.[2] Все DFD диаграммы выступают как одно из наиболее гибких методов моделирования различных возможностей проектируемой ИС. Реализация нотации DFD диаграмм основывается на использовании таких главных понятий: потоки данных, структурные процессы (вход-выход), некоторые сущности и хранилища информации [9].

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

2. Преобразовательные процессы применяются для осуществления продуцирования разных потоков на выходе с ИС путем обработки всех входящих потоков согласно списка действий процесса [10].

3. Хранилища данных используются для определения данных по указанных участках. Все эти данные должны быть сохранены при осуществлении движения, обмена между процессами. А фактически – это выборка или селекция данных.

Рис. 3. DFD диаграмма

1.2. Основные понятия теории баз данных

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

База данных (БД) - именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области. Под предметной областью понимается некоторая область человеческой деятельности или область реального мира, на основе которой создается БД и её структура.[8]

Система управления базами данных (СУБД) - совокупность языковых и программных средств, предназначенных для создания, наполнения, обновления и удаления баз данных.

Принципы построения баз данных

К современным базам данных, а, следовательно, и к СУБД, на которых они строятся, предъявляются следующие основные требования:[7]

– Высокое быстродействие (малое время отклика на запрос). Время отклика - промежуток времени от момента запроса к БД до фактического получения данных.

– Простота обновления данных.

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

– Совместное использование данных многими пользователями.

– Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

– Стандартизация построения и эксплуатации БД (фактически СУБД).

– Адекватность отображения данных соответствующей предметной области.

– Простой интерфейс пользователя.[9]

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

Основные этапы проектирования баз данных:

1) Концептуальное (инфологическое) проектирование – построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например ER-диаграмм (диаграмм «Сущность-связь»). Такая модель строится без ориентации на какую-либо конкретную СУБД.[6]

Основные элементы данной модели:

– Описание объектов предметной области и связей между ними.

– Описание информационных потребностей пользователей (описание основных запросов к БД).

– Описание алгоритмических зависимостей между данными.

– Описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.[4]

2) Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован.