 |
Моделирование бизнес-процессов. Стандарт IDEF3
|
|
|
|
Методология моделирования IDEF3 (workflow diagramming)
предназначена для описания логики взаимодействия работ и
последовательности их выполнения. Диаграммы IDEF3 [1 – 2] позволяют
сфокусировать внимание на течении процессов и на отношениях процессов и
важных объектов, являющихся частями этих процессов.
Каждая диаграмма в IDEF3 описывает какой-либо сценарий бизнес-
процесса – последовательность изменений свойств объекта, которые
необходимо выполнить за конечное время. Каждый сценарий сопровождается
описанием процесса и может быть использован для документирования.
Моделирование начинается с формулировки точки зрения, цели и области
моделирования.
Единицы работы (Unit of Work, UOW), также называемые работами
(activity), являются центральными компонентами модели. В IDEF3 работы
имеют имя, выраженное отглагольным существительным, обозначающим
процесс действия, одиночным или в составе фразы, и номер (идентификатор).
Другое имя существительное в составе той же фразы обычно отображает
основной выход (результат) работы. Идентификатор работы присваивается при
создании и не меняется никогда. Даже если работа будет удалена, ее
идентификатор не должен вновь использоваться для других работ. Обычно
номер работы состоит из номера родительской работы и порядкового номера на
текущей диаграмме.
Связи показывают взаимоотношения работ. Все связи в IDEF3
однонаправлены и могут быть направлены куда угодно, но обычно диаграммы
стараются построить так, чтобы связи были направлены слева направо. В IDEF3
различают три типа стрелок, изображающих связи:
связь предшествования (Precedence) – показывает, что прежде чем начнется
работа-приемник, должна завершиться работа-источник;
|
|
|
связь отношения (Relational) – показывает связь между двумя работами или
между работой и объектом ссылки;
поток объектов (Object Flow) – показывает участие некоторого объекта в
двух или более работах, как, например, если объект производится в ходе
выполнения одной работы и потребляется другой работой.
Имя стрелки должно ясно идентифицировать отображаемый объект.
Связь предшествования показывает, что работа-источник заканчивается ранее,
чем начинается работа-цель. Если результатом работы-источника становится
объект, необходимый для запуска работы-цели, используется стрелка потока
объектов. Отношение показывает, что работа-источник не обязательно должна
закончиться, прежде чем работа-цель начнется; более того, работа-цель может
закончиться прежде, чем закончится работа-источник.
Перекрестки используются для отображения логики взаимодействия
стрелок при слиянии и разветвлении или для отображения множества событий,
которые могут или должны быть завершены перед началом следующей работы.
Перекрестки применяются, когда окончание одной работы может служить
сигналом к началу нескольких работ, или же одна работа для своего запуска
может ожидать окончания нескольких работ.
Различают два типа перекрестков:
перекресток слияния (Fan-in Junction) – узел, собирающий множество
стрелок в одну, указывая на необходимость условия завершенности работ-
источников стрелок для продолжения процесса;
перекресток ветвления (Fan-out Junction) – узел, в котором единственная
входящая в него стрелка ветвится, показывая, что работы, следующие за
перекрестком, выполняются параллельно или альтернативно.
В IDEF3 стрелки могут сливаться и разветвляться только через
перекрестки. Все перекрестки на диаграмме нумеруются, каждый номер имеет
префикс J. Перекресток не может использоваться одновременно для слияния и
|
|
|
для разветвления.
На одной диаграмме IDEF3 может быть создано несколько перекрестков
различных типов. Определенные сочетания перекрестков для слияния и
разветвления могут приводить к логическим несоответствиям. Чтобы избежать
конфликтов, необходимо соблюдать следующие правила:
1. Каждому перекрестку для слияния должен предшествовать перекресток для
разветвления;
2. Перекресток, имеющий одну стрелку на одной стороне, должен иметь более
одной стрелки на другой.
3. Перекресток для слияния «И» не может следовать за перекрестком для
разветвления типа синхронного или асинхронного «ИЛИ», типа
исключающего «ИЛИ»;
4. Перекресток для слияния типа исключающего «ИЛИ» не может следовать за
перекрестком для разветвления типа «И»;
Объект ссылки (Referent) в IDEF3 выражает некую идею, концепцию или
данные, которые нельзя связать со стрелкой, перекрестком или работой. В
качестве имени можно использовать имя какой-либо стрелки с других
диаграмм или имя сущности из модели данных. Объекты ссылки должны быть
связаны с единицами работ или перекрестками пунктирными линиями. При
внесении объектов ссылок помимо имени следует указывать тип объекта
ссылки.
Методология IDEF3 позволяет декомпозировать работу многократно, то
есть работа может иметь множество дочерних работ. Это позволяет в одной
модели описать альтернативные потоки. Декомпозиция может быть сценарием
или описанием. Описание включает все возможные пути развития процесса.
Сценарий является частным случаем описания и иллюстрирует только один
путь реализации процесса.
Возможность множественной декомпозиции предъявляет
дополнительные требования к нумерации работ. Так, номер работы может
состоять из номера родительской работы, версии декомпозиции и собственного
номера работы на текущей диаграмме. Для описания номер декомпозиции
равен единице. Для сценария номер декомпозиции всегда больше единицы.
При создании сценария или описания необходимо придерживаться
дополнительных ограничений. В сценарии или описании может существовать
только одна точка входа. За точкой входа следует работа или перекресток. Для
|
|
|
описания может существовать только одна точка выхода. Сценарий может
иметь несколько точек выхода.
IDEF3 позволяет внести информацию в модель различными способами.
Например, логика взаимодействия может быть отображена графически в виде
комбинации перекрестков. Та же информация может быть отображена в виде
объекта ссылки типа ELAB в случае, если комбинация перекрестков занимает
значительное место и затрудняет расположение работ на диаграмме.
6. Основные принципы нотации информационного проектирования IDEF1X. Логическая и физическая модели данных. Смысловые примитивы. Сущности. Атрибуты. Связи.
7. Принципы нормализации и денормализации модели данных. Аномалии. Основные нормальные формы.
Первой и самой важной функцией БД является функция хранения информации. Информация должна хранится упорядоченно для более быстрого доступа к ней. Упорядочненность помимо быстрготы доступа приводит к значительному сокращению аппаратных ресурсов необходимых для обслуживания БД. Упорядоченность достигается путем нормализации. Нормализацией отношений в реляционной БД называют процесс построения оптимальной структуры таблиц и связей. Нормализация – это пошаговый последовательный, обратимый процесс замены исходной схемы отношений другой, в которой отношения имеют более строгую и регулярную структуру. Это процедура входе которой одна таблица разбивается на две или несколько согласно определенным правилам. Нормализация проектироемой БД заключается в соблюдении 2-х условий:
- Логичность данных
- Уменьшение объема БД
Задачами нормализации являются:
1) Исключение5 из таблиц повторяющейся информации
2) Создание структуры, в которой предусмотрена возможность ее будущих изменений
3) Создание структуры, в которой влияние возможных изменений на приложение использующие информацию из этой БД, сведено к минимуму.
Прежде всего, при нормализации таблицы предпринимается попытка ограничить количество повторяющихся данных. Существует много уровней и типов нормолизации. Наиболее распространеной процедурой является приведение к БД 3-ей нормальной форме (3NF). Поскольку в больщинстве случаев этот уровень нормализации является компромисом между полной нормализацией и простой.
|
|
|
INF – первая нормальная форма – это основа реляционной системы. INF требует, чтобы каждое поле таблицы было недлинным и не содержало повторяющиеся группы. Неделимость поля означает, что содержащиеся в нем значения не должны делится на более мелкие. Повторяющимся является поле содержащие одинаковое по смыслу значения.
IINF – требует, чтобы все поля таблицы зависили от первичного ключа, те поля которые зависят только от части первичного ключа, если он является составным, должны быть выделены в состав отдельных таблиц.
IIINF. Требует, чтобы все неключевые столбцы зависили от первичного ключа, но были независимы друг от друга.
На практике при создании логической модели данных ответные разработки не приведенному алгоритму нормализации, а сразу строят отношения в 3NF, кроме того основным средством разработки логической модели данных являются различные варианты построения ER-диаграмм.
Денормализация (англ. denormalization) — намеренное приведение структуры базы данных в состояние, не соответствующее критериям нормализации, обычно проводимое с целью ускорения операций чтения из базы за счет добавления избыточных данных. Устранение аномалий данных в соответствии с теорией реляционных баз данных требует, чтобы любая база данных была нормализована, то есть соответствовала требованиям нормальных форм. Соответствие требованиям нормализации минимизирует избыточность базы данных и обеспечивает отсутствие многих видов логических ошибок обновления и выборки данных.
Однако в некоторых случаях для некоторых запросов выборки операция соединения (JOIN) нормализованных отношений выполняется неприемлемо долго. Вследствие этого в ситуациях, когда производительность таких запросов невозможно повысить иными средствами, может проводиться денормализация — композиция нескольких отношений (таблиц) в одну, которая, как правило, находится во второй, но не в третьей нормальной форме. Новое отношение фактически является хранимым результатом операции соединения исходных отношений.
За счёт такого перепроектирования операция соединения при выборке становится ненужной и запросы выборки, которые ранее требовали соединения, работают быстрее.
Следует помнить, что денормализация всегда выполяется за счёт повышения риска нарушения целостности данных при операциях модификации. Поэтому денормализацию следует проводить в крайнем случае, если другие меры повышения производительности невозможны. Идеально, если денормализованная БД используется только на чтение.
|
|
|
Кроме того, следует учесть, что ускорение одних запросов на денормализованной БД может сопровождаться замедлением других запросов, которые ранее выполнялись отдельно на нормализованных отношениях.
|
|
|
