Моделирование бизнес-процессов / Моделирование бизнес-процессов / ! Функционально-структурный анализ

ИНФОРМАЦИОННАЯ МОДЕЛЬ объекта или набора объектов - совокупность атрибутов (харак-теристик) данного объекта (объектов) вместе с числовыми или иными значениями этих атрибутов. В системологии под информационной моделью понимается набор неких параметров, которые содержат необходимую информацию об объекте, системе объектов, процессе или явлении. Целью создания информационной модели является обработка данных об объектах реального мира с учетом связей между объектами. Для того чтобы такую обработку можно было автоматизировать, для рассматриваемой модели составляют формализованное описание, доступное компьютерной обработке. Естественной потребностью человека является потребность обмениваться информацией с другими людьми. При этом информация обычно записывается в виде некоторого текста. Например, содержание теоремы Пифагора можно передать следующим текстом « Квадрат длины гипотенузы равен сумме длин квадратов катетов» . Рассматриваемый текст составлен из букв алфавита русского языка. Англоязычный текст использует буквы алфавита английского языка. « Буквами» текста могут быть не только буквы русского или иностранного языка. Музыкант представляет мелодию в виде текста, записанного нотами. Математик при записи математического текста использует математические символы. В этих примерах информация была записана в виде текста на одном из языков кодирования (естественном, научном, специальном). Текст можно рассматривать как своеобразную модель, способную содержать, хранить и передавать информацию. Среди моделей, которыми пользуется человек, языковые модели занимают значительное место, так как они лучше приспособлены для коммуникации. Для передачи такой модели требуется меньше усилий и материальных затрат, чем для передачи, например, натурной модели. Языковые модели, содержащие целенаправленно отобранную информацию, принято называть информационными моде-лями. Умение выделять существенную для рассматриваемого объекта информацию и органи-зовывать ее в удобном для исследования виде является важнейшим фактором, обеспечиваю-щим адекватность модели исследуемому объекту. Пример информационной модели оценивания знаний студентов. Существенными харак-теристиками являются: фамилия студента, предмет и балл. Связи между объектом и его характеристиками представлены на рисунке, который дает схемное описание рассматриваемой модели. В этом описании используемые характеристики принимают следующие значения: фамилия - текстовые значения, предмет - текстовые значения, балл - числовое (5, 4, 3, 2). Формализованное описание данной модели является трехместными предикатом с именем оценка: оценка (фамилия, предмет, балл).

Для конкретных значений аргументов этот предикат превращается в факт. Например, если студент Иванов по программированию получил оценку 5, то имеет место факт: оценка (Иванов, программирование, 5). С помощью таких фактов можно выделить различные характеристики оценки, например, можно выделить студентов, получивших по программированию балл 5. Терминология IDEF1X практически полностью совпадает с терминологией IDEF1, однако существует ряд фундаментальных отличий в теоретических концепциях этих методологий. Графически IDEF1X модель данных изображается совокупностью блоков (сущности), соединяющих блоки линий (отношения между сущностями) и имена атрибутов внутри блоков. Фундаментальные понятия информационных моделей:

• объект - нечто информационное, существующее и различимое (например, редуктор);

• атрибут - свойство, характеристика объекта (например, стандартизированное обозначение редуктора);

• значение атрибута - например, «Одноступенчатый цилиндрический».

АТРИБУТ объекта - каждое отдельное свойство объекта, характеризующее его экземпляр, в то же время это характеристика, общая для всех возможных экземпляров. Например, необходимо создать информационную модель в виде БД литературы, находящейся в библиотеке. В данном случае, можно считать, что это некоторое количество однородных объектов, причем в каждом из литературных источников содержится определенная информация. Простейшая модель библиотеки – это просто список всех книг, составленный в произвольной форме, с указанием, например, номера книги, ее названия, количества страниц и т. п. Однако такая информационная модель не может быть обработана компьютером. Поэтому для библиотеки разрабатывается специальный набор атрибутов. Для каждого литературного источника можно задать: инвентарный номер книги; название; фамилию автора; год издания; классификационный номер согласно рубрикатора; краткое содержание; объем и т. д. При таком определении атрибутов объекта может быть получена более или менее полноценная информационная модель, которую уже можно использовать в компьютерной технологии. Одновременно из этого примера видно, что модель содержит не всю, а только существенную информацию о наборе объектов. В любой момент времени может быть произведено уточнение модели, путем дополнения ее новыми атрибутами, например: тип литературного источ-ника (книга, журнал, дискета, CD-ROM, и т. п.); тематическая направленность; издательство и т. п. Точность модели можно повышать, но собрать всю информацию о моделируемом объекте в принципе не возможно. Возможны две точки зрения на информационную модель и, соответственно, два уровня модели:

1. Логический (точка зрения пользователя) - описывает данные, задействованные в бизнес-процессе предприятия. Логический уровень означает прямое отображение фактов из ре-альной жизни. Например, люди, столы, отделы, собаки и компьютеры являются реальными объектами. На логическом уровне не рассматривается использование конкретной СУБД, не определяются типы данных (например, целое или вещественное число) и не определяются индексы для таблиц. Логическая модель представляется на ERD-диаграммах сущностями, атрибутами и отношениями.

2. Физический - определяет представление информации в БД. Это уровень представляющий собой целевую СУБД, имена объектов и типы данных, индексы составляют.

IDEF1X описывает собой совокупность/набор экземпляров похожих по свойствам, но однозначно отличаемых друг от друга по одному или нескольким признакам. Каждый экземпляр является реализацией сущности, т.о. сущность в IDEF1X описывает конкретный набор экземпляров реального мира, в отличие от сущности в IDEF1, которая представляет собой абстрактный набор информационных отображений реального мира. СУЩНОСТЬ - это множество экземпляров реальных или абстрактных объектов (человек, место, вещь, событие, состояние, концепция, идея, предмет и т.п.), обладающих общими атрибутами или характеристиками, и о которых необходимо хранить информацию. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникальной. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, Заказчик, а не Петров). Сущности именуются обычно существительными, такими как « покупатель», «компьютер» , « служащий» , « продажа» . Более точно, сущность - это множество индивидуальных объектов - экземпляров, причем все эти объекты являются различными. Сущность - это логическое понятие, которой может со--ответствовать таблица в реальной СУБД. Общепринятым видом графического изображения реляционной модели данных является ER-диаграмма, на которой сущности изображаются прямоугольниками, соединенные между собой связями. Такое графическое представление облегчает восприятие структуры базы дан-ных по сравнению с текстовым описанием. Примером сущности IDEF1X может быть сущность « СОТРУДНИК» , которая представля-ет собой всех сотрудников предприятия, а один из них, скажем, Иванов Петр Сергеевич, явля-ется конкретной реализацией этой сущности. В примере, приведенном на рис.1, каждый экземпляр сущности СОТРУДНИК содержит следующую информацию: ID сотрудника, имя сотрудника, адрес сотрудника и т.п. В IDEF1X модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности. Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. В зависимости от режима представления диаграммы прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие сведения. Уникальное имя и номер, разделяются косой чертой « /» и помещаются над блоком. На рис.2 приведен пример IDEF1X диаграммы. Горизонтальная линия прямоугольника разделяет атрибуты сущности на два набора - атрибуты, составляющие первичный ключ в верхней части, и прочие (не входящие в первичных ключ) - в нижней части. Верхняя часть называется ключевой областью, а нижняя часть областью данных. Ключевая область объекта СОТРУДНИК содержит поле « Уникальный идентификатор сотрудника» , в области данных находятся поля « Имя сотрудника» , « Адрес сотрудника» , « Телефон сотрудника» и т.д.

Сущности в IDEF1X всегда имеют ключевую которая содержит первичный ключ для сущности. ПЕРВИЧНЫЙ КЛЮЧ - это атрибут или набор атрибутов, выбранных для идентификации уникальных экземпляров сущности. Если несколько наборов атрибутов могут уникально идентифицировать сущность, то выбор одного из них осуществляется субъективно на основании анализа предметной области. Атрибуты первичного ключа изображаются в виде списка имен внутри блока сущности и располагаются наверху списка над линией в ключевой области и отделяются от других атрибутов горизонтальной чертой. Как следует из названия, не ключевой атрибут - это атрибут, который не был выбран ключевым. Не ключевые атрибуты располагаются под чертой, в области данных. Выбор первичного ключа для сущности является очень важным шагом, и требует большого внимания. В качестве первичных ключей могут быть использованы несколько атрибутов или групп атрибутов. Атрибуты, которые могут быть выбраны первичными ключами, называются кандидатами в ключевые атрибуты (потенциальные атрибуты). Кандидаты в ключи должны уникально идентифицировать каждую запись сущности. В соответствии с этим, ни одна из частей ключа не может быть NULL, не заполненной или отсутствующей. Поэтому при создании сущности в IDEF1X модели, одним из главных вопросов, на который нужно ответить, является: « Как можно идентифицировать уникальную запись?» . Для этого в сущности требуется уникальная идентификация каждой записи, позволяющая правильно создать логическую модель данных. Например, для того, чтобы корректно использовать сущность СОТРУДНИК в IDEF1X мо-дели данных (а позже в базе данных), необходимо иметь возможность уникально идентифицировать записи. Правила, по которым выбирается первичный ключ из списка предполагаемых ключей, очень строги, однако могут быть применены ко всем типам БД и информации. Правила устанавливают, что атрибуты и группы атрибутов должны:

• уникальным образом идентифицировать экземпляр сущности;

• не использовать NULL значений;

• не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр;

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

Процесс определения первичного ключа, приведен на сущности « СОТРУДНИК» :

• атрибут « ID сотрудника» является потенциальным ключом, так как он уникален для всех экземпляров сущности СОТРУДНИК;

• атрибут « Имя сотрудника» не подходит для потенциального ключа, так как среди служащих на предприятии может быть, к примеру, двое Иванов Петровых;

• атрибут « Номер страхового полиса сотрудника» является уникальным, но имеется большая вероятность того, что у СОТРУДНИКА может не иметься страхового полиса;

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

После проведенного анализа можно назвать два потенциальных ключа - первый « Номер сотрудника» и комбинация, включающая поля « имя сотрудника» и « Дата рождения сотрудника» . Так как атрибут « Номер сотрудника» имеет самые короткие и уникальные значения, то он лучше других подходит для первичного ключа. При выборе первичного ключа для сущности, разработчики модели часто используют ДО--ПОЛНИТЕЛЬНЫЙ КЛЮЧ (суррогатный), т.е. произвольный номер, который уникальным образом определяет запись в сущности. Атрибут « Номер сотрудника» является примером суррогатного ключа. Суррогатный ключ лучше всего подходит на роль первичного ключа потому, что яв-ляется коротким и быстрее всего идентифицирует экземпляры в объекте. К тому же суррогат-ные ключи могут автоматически генерироваться системой так, чтобы нумерация была сплошной, т.е. без пропусков. Потенциальные ключи, которые не выбраны первичными, могут быть использованы в качестве вторичных или альтернативных ключей. АЛЬТЕРНАТИВНЫЙ КЛЮЧ - это атрибут (или группа атрибутов), несовпадающий с первичным ключом и уникально идентифицирующий экземпляр сущности. Атрибуты, составляющие альтернативный ключ, однозначно (уникально) идентифицируют экземпляры сущности. Например, для сущности служащий (идентификатор служащего, фамилия. имя, отчество) группа атрибутов « фамилия» , « имя» , « отчество» может являться альтернативным ключом (в предположении, что на предприятии не работают полные тезки). С помощью альтернативных ключей часто отображают различные индексы доступа к данным в конечной реализации реляционной базы. Одни и те же атрибуты сущности могут входить в несколько различных групп ключей. Если сущности в IDEF1X диаграмме связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами (Foreign Key), , которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. ВНЕШНИЕ КЛЮЧИ определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь. Передаваемые атрибуты называются МИГРИРУЮЩИМИ. Внешний ключ изображается с помощью помещения внутрь блока сущности имен атрибутов, после которых следуют буквы FK в скобках. При разработке модели, приходится встречаться с сущностями, уникальность которых зависит от значений атрибута внешнего ключа. Для уникального определения каждой сущности внешний ключ должен быть частью первичного ключа дочернего объекта.

Дочерняя сущность, однозначная идентификация которой зависит от атрибута внешнего ключа (от отношения к другой сущности), называется ЗАВИСИМОЙ СУЩНОСТЬЮ. Зависимая сущность представляет данные, зависящие от других сущностей в системе. Поэтому она всегда должна иметь отношения с другими сущностями. В примере на рис.1 сущность СОТРУДНИК является зависимой сущностью потому, что его идентификация зависит от сущности ОТДЕЛ. В обозначениях IDEF1X зависимые сущности представлены в виде закругленных прямоугольников. Зависимые сущности далее классифицируются на сущности, которые не могут существовать без родительской сущности и сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации). Сущность СОТРУДНИК принадлежит ко второму типу зависимых сущностей, так как сотрудники могут существовать и без отдела. Существуют ситуации, в которых сущность зависит от существования другой сущности. Например, имеется две сущности: ЗАПРОС, используемый для отслеживания запросов покупателей, и ПОЗИЦИЯ ЗАПРОСА, который отслеживает отдельные элементы в ЗАПРОСе. Связь между этими двумя сущностями может быть выражена в виде ЗАПРОС <содержит> один или несколько ПОЗИЦИЙ ЗАПРОСА. В этом случае, ПОЗИЦИЯ ЗАПРОСА зависит от существования ЗАКАЗА. Зависимая сущность может наследовать один и тот же внешний ключ от более чем одной родительской сущности, или от одной и той же родительской сущности через несколько связей. УНИФИКАЦИЯ - это объединение двух или более групп атрибутов внешних ключей в один внешний ключ (группу атрибутов), в предположении, что значения одноименных атрибутов в дочерней сущности всегда одинаковы. Например: сущность « сотрудник» имеет первичный ключ «код сотрудника» и связан идентифицирующей связью с сущностями « супруга» и « дети» . При этом происходит миграция первичного ключа в зависимые сущности. В свою очередь, сущность « супруга» связана неидентифицирующей связью с сущностью « дети» . Имеются два пути миграции ключа, однако в сущности « дети» атрибут « код сотрудника» появляется один раз в качестве элемента первичного ключа. Сущность в методологии IDEF1X является независимой от идентификаторов или просто независимой, если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. НЕЗАВИСИМАЯ СУЩНОСТЬ - сущность, неза-висящая от других объектов в модели при своей идентификации. Независимая сущность пред-ставляет данные, которые всегда присутствуют в системе. При этом отношения с другими сущ-ностями могут как существовать, так и отсутствовать. В вышеописанном примере сущность ОТДЕЛ можно считать независимой. В IDEF1X независимые сущности представлены в виде прямоугольников. Экземпляры независимой сущности могут быть уникально идентифицированы без опре-деления ее связей с другими сущностями; зависимая сущность, наоборот, не может быть уникально идентифицирована без определения ее связей с другими сущностями. Некоторые сущности определяют целую категорию объектов одного типа. В таком случае создается сущность для определения категории и для каждого элемента категории, а затем вводится для них связь категоризации. Родительская сущность категории называется супертипом, а дочерние - подтипом. Например, сущность « сотрудник» может содержать данные как о штатных работниках, так и о временно нанятых. Первые и вторые имеют различные, частично пересекающиеся наборы атрибутов (минимальное пересечение подтипов составляет первичный ключ). Общая часть этих атрибутов, включая первичный ключ, помещается в сущность-супертип « сотрудник» . Различная часть (например, данные почасовой оплаты для временных работников и данные о зарплате и отпуске для штатных работников) помещается в сущности-подтипы. В сущности-супертипе вводится атрибут-дискриминатор, позволяющий различать конкретные экземпляры сущности - подтипа. В зависимости от того, все ли возможные сущности-подтипы включены в модель, категорийная связь является полной или неполной. Продолжая пример, если супертип может содержать данные об уволенных сотрудниках, то эта связь - неполной категоризации, так как для него не существует записи в сущностях - подтипах. АССОЦИИРОВАННАЯ СУЩНОСТЬ представляет данные, которые ассоциируются с отношениями между двумя и более сущностями.

Если факты из одной сущности ссылаются, или некоторым образом связаны, с фактами из другой сущности, то считается, что между данными сущностями существует отношение/связь. Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются отношения (связи). Отношение - это ассоциация или «связь» между двумя сущностями. Это функциональная зависимость между двумя сущностями (в частности, возможна связь сущности с самой собой). Каждая связь соединяет сущность и отношения и может быть направлена только от отношения к сущности. Связь - это понятие логического уровня, которому соответствует внешний ключ на физическом уровне. Связи между сущностями в IDEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Например, важно знать фамилию сотрудника, и не менее важно знать, в каком отделе он работает. Таким образом, между сущностями « отдел» и « сотрудник» существует связь «состоит из» (отдел состоит из сотрудников). Неограниченное отношение (обязательное) представляет собой безусловное отношение, то есть отношение, которое всегда существует до тех пор, пока существуют относящиеся к делу сущности. Ограниченное отношение (необязательное) представляет собой условное отношение между сущностями. Существенно-ограниченное отношение используется, когда существующие сущности взаимно-зависимы в системе. Отношение представляется в модели линией между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка и глагольной конструкцией, отображае-мой над линией, которая описывает, как две сущности зависят друг от друга. Связи это суть глаголы, которые показывают, как соотносятся сущности между собой. Примеры связи между сущностями:

• отдел <состоит из> нескольких сотрудников;

• редуктор <преобразует> крутящий момент;

• автобус <перевозит> нескольких пассажиров;

• инженер <проектирует> разные изделия;

• служащий <совершает> продажи.

В этих примерах взаимосвязи между сущностями соответствуют схеме «один ко многим» . Это означает, что один экземпляр первой сущности (родительской) связан с несколькими экземплярами второй сущности (дочерней). Глагольная конструкция - механизм описания бизнес-правил, определяющих отношение. Хорошая глагольная конструкция описывает отношение в терминах бизнеса, а не на языке технических спецификаций. На рисунке 1 показано отношение между двумя сущностями. Экземпляр сущности банановый десерт может иметь один, два, три или ни одного экземпляра сущности верхушка бананового десерта. Экземпляр сущности верхушка бананового десерта может принадлежать одному, и только одному экземпляру сущности банановый десерт.

Отношения используются и в логической и в физической модели, и представляются в них в виде одного или нескольких мигрирующих атрибутов внешнего ключа. Отношения двунаправлены и представляют значимые ассоциации между двумя сущностями или сущности самой с собой. Поддержание непротиворечивости функциональных зависимостей между сущностями называется ссылочной целостностью. Сссылочная целостность - это обеспечение требования, чтобы значения внешнего ключа экземпляра дочерней сущности соответствовали значениям первичного ключа в родительской сущности. Ссылочная целостность может контролироваться при всех операциях, изменяющих данные. Поскольку связи содержатся «внутри» реляционной модели, реализация ссылочной целостности может выполняться как приложением, так и самой СУБД (с помощью механизмов декларативной ссылочной целостности, триггеров). Чтение отношений на основе использования структуры, называемой ПАРНАЯ СВЯЗЬ, сущность - отношение - сущность является полезным механизмом для представления отношений. Парные связи сущностей двунаправлены. Так что сущности связаны в обоих направлениях. Таким образом, Потребитель покупает Смеси то же самое, что и Смеси продаются Потребителю. Такой способ прочтения отношений обеспечивает проверку корректности разработанной логической модели. Хотя отношения и не описывают полностью все бизнес-правила, они позволяют бизнес-партнерам просматривать модель для понимания взаимосвязей между сущностями.