Материал: Методы проектирования целевой архитектуры данных при формировании BPMS систем

Эту диаграмму можно считать логическим уровнем архитектуры данных.

2.2.3 Определение источников данных

После установления связей между данными, можно перейти к описанию источников хранения этих данных. Источник данных - это хранилище набора данных, необходимых для выполнения задачи. По отношению к системе BPMS, выделяют внешние и внутренние источники данных. Внешние источники данных включают:

.        Корпоративное хранилище данных.

.        Учетные системы.

.        Аналитические системы.

.        Системы ERP.

.        Web-источники.

.        Файлы.

.        Бумажные документы.

К внутренним источникам данных относятся:

.        База данных системы.

.        Внутренние переменные.

К внешним источникам данных обращается операция web-сервис. К внутренним источникам можно обратиться из пользовательской задачи или скрипта. На модели BPMN графически источники обозначаются элементом хранилище данных. Хранилище данных - это место, где данные хранятся. Это может быть электронная база данных, программа, папка на жестком диске.

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

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

Вначале определим все источники. Для более удобного визуального восприятия, эту информацию можно представить в виде матрицы «Приложения/Данные» (Таблица 2.4).

Таблица 2.4. Матрица Приложения/Данные

2.2.4 Интеграция данных

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

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

Так как схемы баз данных разрабатываются независимо друг от друга, они зачастую имеют различную структуру и терминологию. Например, базы данных приложений для автоматизации работы бухгалтерии и управления взаимоотношениями с клиентами (CRM-системы) моделируют разные предметные области, понятийные аппараты которых пересекаются. В итоге возникают проблемы омонимии, синонимии, абсолютного несоответствия понятий.

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

Для отображения интеграции данных между системами, сервисами, приложениями TOGAF предлагает использовать диаграмму передачи данных (Data Dissemination Diagram). Цель диаграммы передачи данных - показать связь между сущностями данных, бизнес-службами и компонентами приложений. Диаграмма отображает, как логические сущности физически реализованы программными компонентами, что в дальнейшем позволит измерить необходимый размер памяти приложений и рассчитать их мощность. Нотация диаграммы передачи данных приведена в Таблице 2.5.

Таблица 2.5. Нотация диаграммы передачи данных

Пример диаграммы передачи данных представлен на Рисунке 2.6.

Рисунок 2.6. Диаграмма передачи данных

2.2.5 Преобразование данных

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

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

По степени структурированности выделяют следующие формы представления данных [22]:

-       неструктурированные (данные, произвольные по форме, включающие тексты и графику, мультимедиа (видео, речь, аудио);

-       структурированные (базы данных, списки, графы, структуры);

-       слабоструктурированные (публикации, RDF, XML).

Все структурированные данные делятся на пять типов:

-       целый (количество товара, код товара и т. п.);

-       вещественный (цена, скидка и т. п.);

-       строковый (фамилия, наименование, адрес, пол, образование и т. п.);

-       логический;

-       дата/время.

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

Можно выделить несколько источников для входных преобразований:

.        Неэлектронный документ. В этом случае происходит распознавание в том или ином виде: распознавание текста отсканированных бумажных документов, распознавание речи, введенной с микрофона и т.д.

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

.        Структурированный документ. Здесь необходимо преобразование данных из одного формата в другой, например, из DBF в XML.

2.2.6 Доступ к данным

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

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

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

Таким образом, на данном этапе требуется определить, во-первых, какие операции будут выполняться над данным, во-вторых, необходимо распределить права между пользователями.

TOGAF использует диаграммы защиты данных для описания доступа к данным. Цель диаграммы защиты данных - отобразить, какой актор может иметь доступ к данным. Доступ к информации определяется 4 категориями действий: создание (C), чтение (R), изменение (U), удаление (D). Основной акцент делается на акторе, поэтому рекомендуется строить диаграммы защиты данных отдельно для каждого актора.

Диаграмма защиты данных может быть также представлена CRUD-матрицей. Нотация диаграммы защиты данных указана в Таблице 2.6.

Таблица 2.6. Нотация диаграммы защиты данных

Пример диаграммы защиты данных приведен на Рисунке 2.7.

Рисунок 2.7. Диаграмма защиты данных

2.2.7 Синхронизация данных по времени

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

Синхронизация на модели визуально отображается с помощью шлюзов и событий.

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

-       эксклюзивные условия и объединения. Могут быть исключающими и основываться на событиях. Данный тип Шлюзов может отображаться как с маркером «X», так и без него;

-       шлюзы, основанные на событиях, и параллельные шлюзы, основанные на событиях, инициируют появление нового экземпляра процесса;

-       шлюзы, включающие условия и объединения;

-       комплексные шлюзы, представляющие собой сложные условия и ситуации;

-       параллельные шлюзы, представляющие собой раздвоение и слияние.

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

-       стартовое событие указывает на то, в какой точке берет начало тот или иной процесс;

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

-       конечное событие указывает на то, в какой точке завершится тот или иной процесс.

Помочь в анализе синхронизации может матрица зависимости «Данные/Функции» (Таблица 2.7).

Таблица 2.7. Матрица Данные/Функции

2.3    Методика проектирования архитектуры данных для BPMS-систем с помощью TOGAF

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

.        Этап формирования концептуального уровня:

.1.     Определение объекта управления.

-       Что является результатом выполнения процесса?

-       Как связаны данные с операциями?

-       Из каких составляющих состоит объект управления?

.2.     Описание потоков данных.

-       Как связаны данные между собой?

.        Этап формирования логического уровня:

.1.     Определение источников данных.

-       Какие используются источники данных?

-       Как связаны данные с источниками?

.2.     Интеграция данных.

-       Как передаются данные между системами, приложениями, сервисами?