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

Александр Карпов, архитектор решений SWG IBM EE/A, IBM

Photo Aleksandr KarpovАлександр Карпов является специалистом в области интеграционных решений для банковских систем, прежде всего в области консолидации платежей и интеграции с системой SWIFT, имеет 13 летний опыт работы в ИТ индустрии, в том числе более 3 лет работы с крупными клиентами IBM в России в финансовом секторе. Начинал карьеру программистом в проектах розничных услуг и создании систем безопасности. Имеет опыт руководства разработкой архитектур распределенных ИТ систем в банковской области и финансовых рынков. Участвовал во внедрении централизованного управления НСИ в крупном банке. 3 года работал в крупном российском банке. Имеет высшее техническое образование, сертифицирован по TOGAF 8 (2009), сертифицированный архитектор IBM (2009).



08.02.2012

МДМ Проект.

В статье под МДМ проектом понимается проект создания в организации IT системы, поддерживающей процессы Мастер Дата Менеджмента (МДМ). МДМ это фреймворк, включающий в себя набор процессов, инструментов и ролей и определяющий подход к управлению основными данными предприятия. Основной задачей МДМ является создание и поддержание достоверной, актуальной и непротиворечивой информации, которая часто описывается термином «золотая запись» (“single version of truth”, ”golden record”). Чаще всего архитектура МДМ проекта представляет собой схему типа «звезда», в центре которой находится МДМ система, к которой подключены IT системы предприятия.

В МДМ проектах особенно заметно наличие различных типов данных. Это связано с несколькими моментами:

  1. Проект МДМ имеет распределенную структуру, данные содержатся в различных системах.
  2. Центром МДМ проекта является новая модель данных МДМ.
  3. Стоит задача обмена данными в гетерогенных IT системах, имеющих собственные модели данных.
  4. Характеристики интегрируемых данных зачастую совершенно различны.

Часть I. Типы данных в МДМ проектах.

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

Рассмотрим вымышленную IT систему Интернет магазина, поддерживающую процесс оформления покупки товаров через Интернет. Модель данных такой системы в IDEF1X нотации приведена на рисунке ниже. Каждый объект в модели представлен прямоугольником, пунктирными линиями обозначены связи «один-ко-многим». Например у одного Клиента может быть несколько Заказов и на модели этот факт отображен взаимосвязью «один Клиент»-«много Заказов».

Рисунок 1 Транзакционная система Интернет магазина и её данные.
Транзакционная система Интернет магазина и её данные.

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

Рассмотрим более реальную ситуацию, когда в Интернет магазине эксплуатируются несколько автоматизированных систем:

  1. Система «Заказы Интернет Магазина» отвечает за заказ товаров через Интернет.
  2. Система «Складской Учет» отвечает за поддержку работы склада Интернет Магазина.
  3. Система «Маркетинговые Акции» поддерживает рассылку клиентам Интернет магазина информации о скидках, новых поступлениях и пр.

В каждой системе присутствует собственная модель данных, поддерживающая внутренние процессы этой системы. Так, в системе «Маркетинговые Акции» присутствуют объекты «Клиент», по отношению к которому проводится та или иная акция. Объектом «Акция» представлен перечень возможных действий (рассылка по электронной почте, «обзвон» и пр.). «Состав Акции» содержит последовательность действий и ответственных менеджеров для каждого цикла.

В системе «Заказы Интернет Магазина» находятся собственные объекты, поддерживающие процесс оформления заказа через WEB форму Интернет магазина. Объект «Корзина» содержит факт и параметры заказа, а объект «Состав корзины» содержит перечень заказанных товаров с количеством и ценой.

Все три системы с моделями данных изображены на рисунке ниже.

Рисунок 2 Различные транзакционные системы Интернет Магазина
Различные транзакционные системы Интернет Магазина.

В каждой из систем можно заметить наличие различных типов данных. Так, в системе «Заказы Интернет магазина» присутствуют данные, которые используются только в этой системе, например «Корзина», «Состав Корзины». В системе «Маркетинговые Акции» присутствуют объекты «Состав Акции» которые не важны для системы «Складской Учет», так как маркетинговые акции не затрагивают (в рассматриваемом примере) состояние склада. Такие данные, специфичные для каждой системы, относятся к Транзакционным данным.

В системах «Маркетинговые Акции» и «Заказы Интернет магазина» присутствуют одни и те же объекты, которые важны для обоих из систем, например объект «Клиент». Это один и тот же клиент, который является как покупателем товаров в Интернет магазине, так и «объектом» применения маркетинговой акции. То есть в обоих системах хранится одна и та-же критическая для бизнеса информация. Это же относится к объекту «Товар», который используется и в системе «Заказы Интернет магазина» и в системе «Складской Учет». Такие данные, представляющие собой основные данные предприятия относятся к Мастер данным. Заметим, что экземпляр объекта типа «Клиент» может появится как в системе «Маркетинговые Акции», так и в системе «Заказы Интернет магазина». В этом случае встает задача синхронизации данных и выявления ошибок и потенциальных дублей, так как подобные данные часто заводятся оператором со свойственным ему «человеческим фактором».

И в каждой системе мы можем выделить большое количество статичных справочников, которые являются самым базовым уровнем данных. Справочник «Ед. Изм.» представляет собой справочник единиц измерения товарной единицы (метр, штука, паллета) и представлен в системе «Заказы Интернет магазина» и в «Складской Учет». Это же относится и к объектам «Пол», «Страна». Объекты «Город» и «Улица» с одной стороны определяют адрес доставки в системе «Заказы Интернет магазина», а с другой стороны задают местоположение товарного склада в системе «Складской Учет». В реальности, подобные общие справочники используются практически во всех IT системах предприятия. Такие данные относятся к Справочным данным (НСИ).

Сравнивая пример на Рисунке 1, где данные расположены в одной системе, можно отметить, что первые различия в типах данных проявляются тогда, когда несколько IT систем используют в своих процессах одни и те же данные. В примере на Рисунке 2 на первом плане стоит задача синхронизации объектов Мастер данных и Ссылочных данных (НСИ) в отдельных транзакционных системах. Причем Мастер данные «Клиенты» необходимо синхронизировать относительно часто (например раз в день), тогда как справочник «Улицы» меняется очень редко. Но в случае изменения наименования улицы, необходимо актуализировать все справочники «Улицы» в транзакционных системах, где этот справочник используется.

Резюмируя вышеприведенные примеры, определим три основных типа данных в МДМ проектах.

Транзакционные Данные – данные, отображающие результат выполнения транзакции и относящийся непосредственно к бизнес операции. Типичный пример – банковская операция, счет за использование услуг, накладная к отгрузке и пр. Часто называются также как «Transactional Data», «Application Specific Data», «Operational Data».

Мастер Данные– основные данные предприятия, основной актив, представляющие собой ключевые объекты деятельности предприятия. Типичные Мастер Данные – информация о клиентах, поставщиках, номенклатуре. Мастер Данные также имеют синонимы «Master Data», «single version of truth», «golden record».

Ссылочные Данные (НСИ) – базовые данные для всех информационных систем, часто представляющие собой нормативы, сокращения, акронимы, стандарты, словари и пр. Типичные Ссылочные Данные – справочники счетов, тематические классификаторы. Ссылочные данные имеют синонимы «Reference Data», «Lookup Data», «Dictionaries», НСИ.

Следует отметить, что встречается путаница и под термином НСИ понимается совокупность обоих типов данных: как Мастер Данных так и Ссылочных данных (НСИ). Это связано с отсутствием четких определений и наличием сходных характеристик у обоих типов.

Наряду с выше перечисленными типами данных, в МДМ проекте присутствуют и другие данные, к примеру, метаданные, неструктурированные данные и пр. Это могут быть внутренние справочники, таблицы с настройками, отчетные таблицы и пр. В примере Интернет магазина это, к примеру, объекты «Статус» каждой из систем. Рассмотрение таких данных выходит за рамки статьи, так как не относится непосредственно к специфике МДМ проекта.


Расположение и связь между данными в МДМ проекте.

Обобщая приведенный выше пример, приведем общую схему МДМ проекта, взаимосвязи и расположение различных типов данных. Для удобства подчеркивания связей между объектами данных, расположенных в разных IT системах, схема приведена в «Relation Model» нотации, стрелками обозначены ссылки и зависимости одних данных от других. Для упрощения количество элементов отношения для связей не указаны.

Рисунок 3 Топология МДМ проекта
Топология МДМ проекта.

На схеме изображены четыре транзакционных системы (аналогичные примеру с Интернет магазином), в каждой из которых есть собственная модель данных. В центральной МДМ системе содержатся объекты Мастер данных, например объект «Товар», связанные с соответствующими объектами в транзакционных системах. Почти во всех системах присутствуют экземпляры объектов данных типа Ссылочные данные (НСИ).

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

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

  1. Связь между моделями различных транзакционных систем. Данные одной транзакционной системы связаны с данными другой транзакционной системой. Из примера Интернет магазина это данные объекта «Состав Корзины» из системы «Заказы Интернет Магазина», который связан с объектом «Товар на складе». Практический смысл подобной связи в том, что заказанный клиентом товар должен резервироваться на складе.
  2. Связь между транзакционными данными в Транзакционной системе и Мастер данными в МДМ. В этом случае Транзакционные данные хранят ссылку (идентификатор) на Мастер данные в МДМ. Для получения профиля клиента транзакционная система должна запросить МДМ систему, используя эту ссылку. Подобной типом может быть реализована связь между объектами «Адрес доставки» и «Клиент» в системе «Заказы Интернет Магазина».
  3. Связь между Мастер данными в МДМ системе и Мастер данными в Транзакционной системе. В реальной жизни очень редкая система может работать в режиме, когда Мастер данные находятся удаленно в МДМ системе(вариант №2 выше). Часто транзакционная система хранит собственную копию Мастер данных в той части, которая укладывается в модель этой транзакционной системы. Заметим, что собственная копия может быть ограничена как по атрибутному составу (горизонтально), так и по количеству данных (вертикально).
  4. Связь между Транзакционными данными и Ссылочными данными (НСИ). Эта связь между объектами «Улица» и «Адрес Доставки» из примера Интернет Магазина на Рисунке 2.
  5. Связь между Транзакционными данными и Мастер данными в рамках одной системы. Это связь между объектами «Клиент» и «Состав Акции» из системы «Маркетинговые Акции».
  6. Связь между Мастер данными и Ссылочными данными (НСИ). Эта связь между объектами «Товар» и «Ед. Изм».

Суммируя вышесказанное, отметим основные различия типов данных с точки зрения мест расположения и использования. Транзакционные данные чаще всего расположены в своих системах, Мастер данные консолидированы в МДМ системе, частично в Транзакционных системах, Ссылочные данные (НСИ) растиражированы по IT системам в виде полных копий. Также можно отметить, что МДМ система агрегирует в себе данные из различных транзакционных систем. Например, Мастер данные «Клиент» могут появится независимо в системах «Заказы Интернет Магазина» и «Маркетинговые Акции», но в конечном счете эти данные поступят в МДМ систему. В результате самый полный список объектов «Клиент» содержится в МДМ системе, тогда как в случае со Ссылочными данными (НСИ) каждая транзакционная система содержит полную копию соответствующих справочников.


Преобразования различных типов данных друг в друга.

Развивая тему различия типов данных, отметим, что данные могут быть определены по разному, в зависимости от вариантов их использования. Например, справочник «Общероссийский классификатор территорий муниципальных образований» (ОКТМО) ведется централизованно РОССТАНДАРТом России. Для РОССТАНДАРТа работа со справочником ОКТМО является одним из основных направлений деятельности, это по сути их продукт. В общем случае, для внутренних систем РОССТАНДАРТа справочник ОКТМО является Мастер данными, так как только внутри РОССТАНДАРТа производится сбор, обработка, согласование и в конечном счете формирование единого справочника ОКТМО. Для любой другой организации, импортировавшей данный справочник и использующей его в своей работе, ОКТМО является Ссылочными данными (НСИ), и используется в качестве справочной информации. Не только РОССТАНДАРТ может выпускать Ссылочные данные (НСИ). К примеру, ФГУП ГНИВЦ выпускает классификатор адресов КЛАДР, а Министерство Здравоохранения централизованно ведет Государственный реестр лекарственных средств. Для ФГУП ГНИВЦ справочник КЛАДР является Мастер данными. Сторонняя организация импортирует КЛАДР и начинает использовать его внутренние идентификаторы улиц и городов в своих IT системах и для этих транзакционных систем КЛАДР будет являться Ссылочными данными (НСИ).


Часть II. Оценочные критерии, которые можно использовать для идентификации различных типов данных.

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

Таблица 1.
КритерийСсылочные данные (НСИ)Мастер ДанныеТранзакционные Данные
Типичные данные.Справочники, нормативы, сокращения, кодификаторы, акронимы, стандарты, словари, «бизнес-правила» в виде диапазонов, пороговых значений, констант, последовательностей и пр. Могут использоваться для нормализации в БД. Часто являются связующим звеном между мастер-данными и транзакционными. Выражают «факт». Самодостаточны.Основные объекты организации, прошедшие процедуры «очистки» и согласования. Определяются типом МДМ системы (CDI, PIM см. Ссылки в конце статьи). Выражают «базовые объекты».Данные, отражающие транзакцию в системе. Содержат собственно результат транзакции. Часто представлены комбинацией Мастер Данных и Ссылочных данных (НСИ) и дополнительных специфичных для данной транзакции атрибутов. Выражают «действие-результат».

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

Таблица 2.
КритерийСсылочные данные (НСИ)Мастер ДанныеТранзакционные Данные
Скорость изменения модели данных.Модель данных практически стабильна на протяжении использования.Модель данных меняется редко и в основном как ответ на адаптацию к новым бизнес требованиям и расширению моделей в транзакционных системах в части, относящейся к основным данным предприятия.Модель данных меняется часто в зависимости от новых бизнес-требований к системе.

Комментарии. Модель данных Ссылочных данных (НСИ) практически неизменна. Из приведенного выше примера с Интернет магазином, справочник «Единицы Измерения» (ID, «кг.», «Килограмм») состоит из 3 полей (код, сокращение, расшифровка) и полностью описывает суть объекта. Модель Мастер данных изменятся редко и в своем развитии стремится к виду, максимально полно описывающему объект основной деятельности предприятия. К примеру, объект «Клиент» в реальной модели достаточно детально описывается при помощи порядка 300 атрибутов и расширение этой модели может быть вызвано только экзотическими требованиями. Модель транзакционных данных меняется при любом качественном изменении бизнес-процессов организации, требующем доработки данных и их взаимосвязей. В примере Интернет магазина может появится необходимость создания подразделения, предоставляющего сервис обслуживания проданной техники. Это может повлечь изменения в моделях данных введением новых объектов, типа «Специалист», «Наряд», «ЗИП», связанных с существующими объектами Мастер данных «Клиент», «Товар» и пр.

Таблица 3.
КритерийСсылочные данные (НСИ)Мастер ДанныеТранзакционные Данные
Скорость изменения данных.Очень низкая. Практически не изменяются.Низкая, данные меняются в момент изменения мастер данных в одной из IT систем (или МДМ системе) и формирования «золотой записи». Высокая. Меняются в каждой бизнес транзакции.

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

Таблица 4.
КритерийСсылочные данные (НСИ)Мастер ДанныеТранзакционные Данные
Критичность к качеству данных.Очень высокие требования к качеству данных. Недопустима путаница, разночтения и дублирование данных.Высокие требования к качеству.Высокие требования. Качество данных определяется транзакционной системой, в которой, как правило, заданы механизмы "компенсации" ошибок.

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

Таблица 5.
КритерийСсылочные данные (НСИ)Мастер ДанныеТранзакционные Данные
Время жизни.В случае внешних для огранизации данных - существовали по факту до начала создания/эксплуатации IT систем организации. В случае внутренних данных - существуют все время существования бизнеса предприятия.Появляются и поддерживаются на протяжении всего времени существования бизнеса предприятия.Чаще всего время жизни определяется временем жизни соответствующей транзакционной системы.

Комментарии Упрощенная временная диаграмма жизненного цикла для каждого типа данных приведена на рисунке.

Рисунок 4
Рисунок 4.

К примеру, Ссылочные данные (НСИ) «Типоразмер труб» зависят не от какого-то конкретного предприятия, а скорее от отрасли, а поэтому существовали до начала деятельности предприятия (верхняя синяя стрелка). Некоторые Ссылочные данные (НСИ) могут появится в момент работы предприятия – например внутренняя оргструктура организации (нижняя синяя стрелка). Но с началом деятельности производства и выпуском первой трубы появляется первый экземпляр Мастер данных – «Труба №1», информация о которой хранится даже после снятия ее с производства. Транзакционные данные каждой системы живут только внутри жизненного цикла этой системы (не рассматриваем вариант когда данные передаются из системы в систему, или агрегированы в хранилище данных).

Таблица 6.
КритерийСсылочные данные (НСИ)Мастер ДанныеТранзакционные Данные
Количество данных.Небольшое, часто отражает реальные "факты", количество которых заведомо конечно.Изначально достаточно большое. Конечное множество..Количество данных не ограничено.

Комментарии . Количество данных каждого типа объекта в модели Ссылочные данные (НСИ) заведомо ограничено, и часто описывает факт, имеющий подтверждение в реальном мире. Например, справочник муниципальных районов города Москвы содержит несколько десятков экземпляров объектов. Количество Мастер данных изначально довольно большое (тысячи однотипных объектов), именно при таком количестве возникают комплексные задачи МДМ, связанные со сбором, «очисткой» и консолидацией данных. Нет смысла в построении МДМ системы для пары сотен клиентов – качество данных в этом случае может быть поддержано одним-двумя «операционистами». Количество Транзакционных данных не ограничено ничем, только спецификой бизнеса или нефункциональными требованиями к системе. Грубый пример. На одной улице (Ссылочные Данные (НСИ)) могут проживать сотни клиентов (Мастер данные) сотового оператора, которые совершают сотни звонков (Транзакционные данные) по телефону. Различия в количестве данных для каждого типа в данном примере как минимум на 2 порядка.

Таблица 7.
КритерийСсылочные данные (НСИ)Мастер ДанныеТранзакционные Данные
Взаимосвязь с другими типами данных.Не включают в себя и не ссылаются ни на какие другие типы данных.Включают в себя или ссылаются на Ссылочные данные (НСИ).Включают в себя или ссылаются на любые другие типы данных.
Рисунок 5
Рисунок 5.

Комментарии. Ссылочные данные (НСИ), являются базовым уровнем данных, на ссылаются все остальные данные. Мастер данные, являются базовыми для транзакционных систем, оперирующих с этими данными. Заметим, что обратных связей, например, ссылок объектов Справочных данных (НСИ) на объекты Транзакционных данных, нет. Упрощенная схема взаимосвязей приведена на рисунке.

Таблица 8.
КритерийСсылочные данные (НСИ)Мастер ДанныеТранзакционные Данные
Типичные способы распространения Распространяется централизовано и однонаправленно - чаще списками, файлами, выгрузками. Реже - репликацией между БД. Диктуется "мощностью" интеграции между МДМ и транзакционной системой. В общем случае должны быть построены двунаправленные каналы связи, работающие в режиме "онлайн" и "офлайн".Определяется спецификой транзакционной системы. Возможно использование всех типов интеграции..

Комментарии. Способ распространения важен для того, чтобы избежать необоснованных усилий при работе с теми или иными типами данных. Ссылочные данные (НСИ) являются относительно статичной информацией, для их распространения не требуются особые интерфейсы. Достаточно осуществлять выгрузку в общее место хранения актуальных наборов справочников в виде файлов, откуда его могут забирать системы по мере необходимости. В случае с МДМ требуется более тесная интеграция с транзакционными системами. Например, если данные меняются в МДМ, эти изменения должны быть (в общем случае) быстро растиражированы по системам - подписчикам. И наоборот, если в какой-то транзакционной системе у клиента изменились атрибуты, эти изменения должны быть максимально быстро доведены до МДМ и зафиксированы им. К примеру, если на предприятии уже существует МДМ система, то возникает соблазн разместить все объекты Справочных данных (НСИ) в МДМ, тем более, что функционала МДМ системы с лихвой хватит для такой работы. Однако что делать, если какой-то транзакционной системе требуются Ссылочные данные (НСИ), но у неё нет возможности создать интерфейсы к МДМ, потому что рассматриваемая транзакционная система не работает с Мастер данными ? И как быть с утилизацией МДМ системы, изменением ее модели для работы с новым типом данных, лицензированием, дополнительной нагрузкой, вносимой обслуживанием Справочных данных (НСИ) ?

Таблица 9.
КритерийСсылочные данные (НСИ)Мастер ДанныеТранзакционные Данные
Места появления данных внутри Предприятия.- Транзакционные системы.
- МДМ система.
- Часто "прошиваются в код" исполняемых модулей IT систем.
- Глоссарий Предприятия.
- МДМ система.
- Транзакционные системы.
- Транзакционные системы

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

Таблица 10.
КритерийСсылочные данные (НСИ)Мастер ДанныеТранзакционные Данные
Особенности модели Объекты с небольшим количеством атрибутов. Неглубокий уровень вложенности в классификаторах. Наличие натуральных ключей. Не развитые механизмы поддержки историчности. Объекты с большим количеством атрибутов и сложными взаимосвязями. Развитые механизмы для хранения истории изменений.Определяется спецификой транзакционной системы. В общем случае модель содержит много объектов с различным количеством атрибутов.

Комментарии. Ссылочные данные (НСИ) это небольшие объекты. Для примера, объект «Общероссийского классификатора продукции» содержит натуральный ключ, контрольное число, расшифровку. («25 2790»,3,«Виды шинной продукции прочие»). Поддержка историчности часто реализована внесением в модель «даты актуализации» - времени, с которого рассматриваемый факт начинает действовать. Ссылочные данные (НСИ) часто представлены набором плоских справочников, объединенных классификатором с небольшим уровнем вложенности (до 10 уровней). Мастер данные имеют сложную иерархическую структуру. Например, Сборка, состоящая из десятков комплектующих, и десятков технологических шагов, и входящая в состав другой сборки и т.д. Или физическое лицо, являющееся клиентом организации, его родственные связи с другими физ. лицами и с юр. лицами, где он работал (работает). Сложность модели Мастер данных объясняется целью максимально детально представить основные объекты бизнеса (например объект «Клиент») со всех возможных точек зрения. Модель данных транзакционной системы зависит от типа бизнес процессов, которые она призвана поддержать.

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


Различия типов данных в МДМ проекте.

Суммируя вышесказанное, определим ключевые различия Ссылочных данных (НСИ), Мастер Данных и Транзакционных Данных в применении к МДМ проектам:

  1. Различные жизненные циклы, требующие различных подходов для поддержания целостности и непротиворечивости.
  2. Различные свойства: объем данных, сложность модели, взаимосвязи, скорости изменения.
  3. Различные варианты использования.
  4. Хранение в разных местах.

Часть III. Почему важно различать типы данных в МДМ проектах ?

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

Практическая ситуация в реальном мире может быть представлена в виде более чем одного работоспособного набора моделей данных. Чем объемнее модели и сложнее их взаимосвязи, тем сложнее добится качественного результата при интеграции данных ИТ систем в МДМ проекте. Недостаточное понимание «границ» и связей между данными только усугубляет ситуацию.

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

На практике понимание типов данных и их характеристик требуется в следующих случах:

  1. Для проектирования интеграционных взаимодействий в МДМ проекте. Возвращаясь к Рис.3, качественное интегрирование данных невозможно без понимания мест их хранения и взаимосвязей.
  2. Выстраивания и поддержания адекватных жизненных циклов данных. «Смешение» типов данных приведет к необоснованным затратам по их обслуживанию и поддержке актуальности.
  3. Разделения зон ответственности за данные. Каждый тип данных должен быть закреплен за соотвествующим подразделением. Для Транзакционных данных это в первую очередь владельцы этой системы, для Мастер данных и Ссылочных данных (НСИ) это выделенные группы на уровне предприятия. Отсутствие контроля за данными неминуемо ведет к их деградации и потере качества.
  4. Проектирования потоков данных внутри ландшафта IT. Как пример Мастер данные или Ссылочные данные (НСИ) могут передаваться между IT системаи либо целиком, либо ссылками, которые будут «разрешаться» в месте использования.
  5. Поддержания целостности и непротиворечивости основной модели данных предприятия, консолидирующей все типы данных в единое представление.
  6. Адекватной утилизации IT систем, работающих с данными. Обычной ошибкой является выбор одного решения как для работы с Мастер данными так и для работы с Ссылочными данными (НСИ). Как отмечалось выше, это приводит к необоснованным затратам и сложностям в обслуживании.
  7. Помощь в расчете экономических параметров, созданию методик оценки стоимости хранения и обслуживания одного объекта в МДМ системе, стоимости транзакции с участием МДМ и пр.
  8. Созданию внутренних архитектурных стандартов и принципов, принятых и используемых в организации для поддержки и развития ИТ. Качественная поддержка инициатив Data Governance, Enterprise Information Management и пр.

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

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


Подходы компании ИБМ.

Компания ИБМ предоставляет широкий набор решений, при помощи которых возможно реализовать МДМ проект любого уровня сложности, и, как основную подчасть этого проекта – работу с моделями данных. Компания ИБМ предлагает:

  1. Весь спектр решений класса МДМ, как то МДМ-CDI, МДМ-PIM а также референсные модели и подходы для их адаптации.
  2. Готовые модели данных и процессов для конкретных индустрий.
  3. Инструментарий, позволяющий эффективно создавать и развивать модели данных.
  4. IBM MDM BluePrints – опробированные архитектуры и подходы, касающиеся реализации проектов МДМ на предприятии.
  5. Развитые практики создания решений класса Master Data Management и Reference Data Management.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=792199
ArticleTitle=Типы данных в МДМ проектах
publish-date=02082012