Изучение основных функций пакета BPwin

BPwin позволяет аналитику создавать сложные модели бизнес-процессов при минимальных усилиях. BPwin поддерживает три методологии – IDEF0, IDEF3 и DFD. Каждая из них призвана решать свои специфические задачи.

Модель в BPwin рассматривается как совокупность работ, каждая из которых оперирует с некоторым набором данных. Работы изображаются в виде прямоугольников (блоков), данные – в виде стрелок (дуг).

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

В IDEFO различают пять типов стрелок:

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

Управление ( Control ) - правила, стратегии, процедуры или стандарты, которыми руководствуется работа. Каждая работа должна иметь хотя бы одну стрелку управления. Стрелка управления рисуется как входящая в верхнюю грань работы.

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

Механизм ( Mechanism ) - ресурсы, которые выполняют работу, например персонал предприятия, станки, устройства и т. д. Стрелка механизма рисуется как входящая в нижнюю грань работы.

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

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

Диаграммы потоков данных (Data flow diagramming, DFD) используются для описания документооборота и обработки информации. Подобно IDEF0, DFD представляет модельную систему как сеть связанных между собой работ. Их можно использовать как дополнение к модели IDEF0 для более наглядного отображения текущих операций документооборота в корпора­тивных системах обработки информации. DFD описывает:

■ функции обработки информации (работы);

■ документы (стрелки, arrow), объекты, сотрудников или отделы,
которые участвуют в обработке информации;

■ внешние ссылки (external references), которые обеспечивают интер­
фейс с внешними объектами, находящимися за границами модели­
руемой системы;

■ таблицы для хранения документов (хранилище данных, data store).

В отличие от IDEF0, где система рассматривается как взаимосвязанные работы, DFD рассматривает систему как совокупность предметов.

Наличие в диаграммах DFD элементов для описания источников, приемников и хранилищ данных позволяет более эффективно и наглядно описать процесс документооборота. Однако для описания логики взаимо­действия информационных потоков более подходит IDEF3, называемая также workflow diagramming - методологией моделирования, использующая графическое описание информационных потоков, взаимоотношений между процессами обработки информации и объектов, являющихся частью этих процессов. Диаграммы Workflow могут быть использованы в моделиро­вании бизнес-процессов для анализа завершенности процедур обработки информации. С их помощью можно описывать сценарии действий сот­рудников организации, например последовательность обработки заказа события, которые необходимо обработать за конечное время.

Финансово-экономический отдел

Начальник узла почтовой связи

Отдел информатизации и эксплуатации почтовой связи

Отдел кадров

Заместитель начальника

Отдел сортировки, обработки и доставки почты

Коммерческий отдел

Отдел перевозки почты

Хозяйственный отдел

Транспортный участок

Рис.1. Организационно - производственная структура узла почтовой связи

ЗАКЛЮЧЕНИЕ

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

Моей целью являлось проектирование базы данных «Почтовые отделения» средствами СУБД MS Access.

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

– ограничения, накладываемые на информацию, которая будет храниться в базе данных;

– перечень запросов на предоставление справочной информации;

– возможные изменения информации, которая будет храниться в базе данных, а также добавление новой и удаление ненужной информации;

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

Результаты проведенного анализа должны быть сгруппированы должным образом и представлены в виде отчета на бумажном носителе.

Второй этап проектирования делится на две фазы, первая из них это выбор методологии проектирования, а вторая – проектирование базы данных «Почтовые отделения». Для проектирования моей базы данных я выбрал метод «сущность-связь» и метод нормальных форм. С помощью первого из них формируются сущности, выявляются связи между ними и строится диаграмм ER-типов. Далее из сущностей и связей между ними формируются отношения согласно правилам формирования отношений, изложенным выше. С помощью второго метода уже сформированные отношения приводятся к БКНФ.

Третий этап проектирования заключается в реализации базы данных «Почтовые отделения» с помощью СУБД Microsoft Access. Выбор для реализации базы данных СУБД MS Access обосновывается следующим. Во-первых, эта СУБД входит в состав наиболее распространенного пакета прикладных программ по работе с документами Microsoft Office. Из MS Access возможен экспорт информации в другие приложения, входящие в MS Office (MS Word, MS Excel). Во-вторых, MS Access может являться дополнением к другим приложениям, в частности и СУБД, таким как Delphi, dBase и другие. Например, файлы MS Access могут являться основой для построения базы данных с помощью Delphi. Также MS Access может являться клиентом по отношению к Microsoft SQL Server. В-третьих, MS Access поддерживает механизм OLE, т.е. может связывать и внедрять объекты.

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

СПИСОК ЛИТЕРАТУРЫ

1. Карпова Т.С. Базы данных: модели, разработка, реализация. – СПб.: Питер, 2001. – 304 с.

2. Хомоненко А.Д., Гридин В.В. Microsoft Access. Быстрый старт. – СПб.: БХВ-Петербург, 2003. – 304 с.

3. Золотова С.И. Практикум по Access. – М.: Финансы и статистика, 2004. – 144 с.

4. Тиори Т., Фрай Дж. Проектирование структур баз данных: В 2-х кн. Кн. 1. Пер. с англ. – М.: Мир, 1985. – 287 с.

5. Чамберлин Д.Д., Астрахан М.М., Эсваран К.П., Грифитс П.П., Лори Р.А., Мел Д.В., Райшер П., Вейд Б.В. SEQUEL 2: унифицированный подход к определению, манипулированию и контролю данных //СУБД. - 1996. - №1. - С.144-159.

6. Чаудхари С. Методы оптимизации запросов в реляционных системах //СУБД. - 1998. - №3. - С.22-36.

7. Чен П. Модель "сущность-связь" - шаг к единому представлению о данных //СУБД. - 1995. - №3. - С.137-158.