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

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

1.3    Модели данных


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

1.3.1 
Концептуальная модель данных

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

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

.        Сбор и анализ данных. Построение локальных представлений, отражающих представление отдельного пользователя.

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

При разработке концептуальной модели следует определить:

-       сущности;

-       атрибуты сущности;

-       связи между сущностями.

Обычно концептуальная модель разрабатывается в виде диаграммы сущностей - связей или ER-диаграммы (entity - relationship). На следующем этапе концептуальная модель данных преобразуется в логическую модель данных.

1.3.2  Логические модели данных

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

)        иерархическая;

)        сетевая;

)        реляционная;

)        многомерная;

)        гибридная;

)        объектно-ориентированная;

)        сервис-ориентированная.

Иерархическая модель представляет набор элементов, связанных между собой по определенным правилам. Графически иерархическая структура изображается в виде дерева [8].

Основным достоинством иерархической модели является удобство работы с иерархически упорядоченной информацией.

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

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

Достоинством сетевой модели является возможность создания произвольных связей.

К недостаткам сетевой модели относятся:

)        жесткость и сложность схемы базы данных, спроектированной на основе сетевой модели;

)        трудность обработки информации в базе данных пользователем.

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

К достоинствам реляционной модели относятся:

)        простота моделирования предметной области;

)        наличие математического аппарата;

)        удобство практической реализации базы данных.

К недостаткам реляционной модели относятся:

)        сложность описания иерархических и сетевых связей;

)        сложность применения в нетрадиционных областях.

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

Агрегируемость - возможность анализа данных с разными уровнями обобщения.

Историчность обеспечивает высокий уровень статичности данных и их взаимосвязей, а также привязку данных к временным точкам.

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

Основное достоинство многомерной модели - удобство и эффективность аналитической обработки больших объемов данных, связанных с временными интервалами.

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

Гибридная модель (HOLAP) сочетает в себе принципы реляционной и многомерной моделей. Главным принципом построения HOLAP является то, что детализированные данные хранятся в реляционной структуре (ROLAP), которая хранит большие объемы данных, а агрегированные данные хранятся в многомерной структуре (MOLAP).

К достоинствам гибридной модели относятся:

)        хранение данных в реляционной структуре делает их в большей степени системно независимыми;

)        устойчивые и непротиворечивые опорные точки для многомерного хранилища;

)        обеспечение передачи актуальной и корректной информации в многомерное хранилище.

Недостатком гибридной модели является сложность администрирования базы данных (согласование изменений и в реляционной, и в многомерной структурах).

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

Преимущества объектно-ориентированной модели:

)        реализация сложных типов данных;

)        связь с языками программирования.

Недостатки объектно-ориентированной модели:

)        высокая понятийная сложность;

)        отсутствие развитого математического аппарата.

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

1.3.3 Физическая модель данных

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

Корпоративная Информационная Система (КИС) - это масштабируемая система, предназначенная для комплексной автоматизации всех видов хозяйственной деятельности компаний. Главная задача КИС - эффективное управление всеми ресурсами предприятия (информационными, финансовыми, материальными и кадровыми) для получения максимальной прибыли и удовлетворения материальных и профессиональных потребностей сотрудников предприятия.

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

-       информационные (данные, файлы, документы);

-       финансовые (деньги, ценные бумаги);

-       материальные (оборудование, сырье, материалы);

-       кадровые (персонал).

Существуют классы систем, которые позволяют управлять этими ресурсами.

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

Существуют системы, направленные на управление конкретной группой ресурсов (Таблица1.2).

Таблица 1.2. Системы управления ресурсами

Процесс

Система

Описание

Управление информационными ресурсами

EDM (Electronic Document Management)

Система, обеспечивающая отслеживание и хранение электронных документов и образов бумажных документов


ECM (Enterprise Content Management)

Система управления корпоративным контентом, который предназначен для создания единого информационного пространства предприятия


CMS (Content Management System)

Система обеспечения и организации совместного процесса создания, редактирования и управления контентом


MDM (Master Data Managemen)t

Система согласования данных различных информационных систем и создания целостного представления о клиентах, поставщиках, партнерах, продуктах, услугах или учетных записях

Управление финансовыми ресурсами

FMS (Financial Management System)

Система управления денежными потоками организации

Управление материальными ресурсами

MES (Manufacturing Execution System)

Система отслеживания этапов производственного цикла в режиме реального времени


EAM (Enterprise Asset Management)

Система управления процессами эксплуатации производственных фондов предприятия


SCM (Supply Chain Management)

Система управления цепочками поставок (управление запасами)


PLM (Product Lifecycle Management)

Система управления жизненным циклом продукта

Управление трудовыми ресурсами

CRM (Customer Relationship Management)

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


HRM (Human Resource Management)

Система учета персонала, его поиска, оценки, обучения, мотивации


Другой класс систем, используемых на предприятии, - системы анализа и поддержки принятия решений (Таблица1.3).

Таблица 1.3. Системы анализа и поддержки принятия решений

Процесс

Система

Описание

Анализ и поддержка принятия решений

BSC (Balanced Scorecard)

Система сбалансированных показателей, позволяющая измерить эффективность компании при помощи специально подобранных сбалансированных индикаторов


BI-приложения

Системы бизнес-анализа и генерации отчетов


СППР

Система интеллектуальной поддержки процессов разработки и реализации управленческих решений


Отдельный класс систем - управление процессами предприятия. Системы такого класса называются BPMS (Business Performance Management System). BPMS содержат набор мощных возможностей многомерного анализа и бизнес-планирования.

Каждому классу систем соответствует определенная логическая модель данных (Рисунок 1.1).

Рисунок 1.1. Соответствие моделей системам

1.4    Процесс формирования архитектуры данных


Процесс формирования архитектуры предприятия представляет совокупность взаимосвязанным проектов, необходимых для преобразования существующей архитектуры в целевое состояние. Выделяют 3 подхода к процессу разработки архитектуры предприятия [10]:

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

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

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

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

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

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

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

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

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

1.5 Методы проектирования архитектуры предприятия


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

-       применение гибридного подхода (комбинирование нескольких методик для создания одной архитектуры);

-       применение популярных методологий (т.е. методологий, являющихся стандартом де-факто, например, FEAF - методология, используемая при создании архитектуры Правительства);

-       применение собственной методологии;

-       применение методологии, предложенной консалтинговой фирмой.

Согласно исследованию «Analyzing the current trends in enterprise architecture frameworks», проведенному Cameron B.H. и McMillian E. в 2013 г. [12], использование вышеуказанных подходов распределилось следующим образом (Таблица 1.4).

Таблица 1.4. Выбор подхода при разработке архитектуры предприятия

Поход

Количество фирм (% от числа опрошенных)

Применение гибридного подхода

54

Применение популярных методологий

26

Применение собственной методологии

9

Применение методологии, предложенной консалтинговой фирмой

5

Другое

6