Автор: Bладимир Энгельс, Oracle СНГ
Что такое модель мастер-данных
Среди всей совокупности данных, используемых в компаниях, есть определенная специфичная категория (15-20% от всего объема), которая используется как "язык бизнеса", лежащий в основе самого бизнеса компании. Такие данные называют мастер-данными. Именно сами эти данные являются ценностью для бизнеса, а не средства управления ими (например, программно-аппаратная инфраструктура). Целью данной статьи является разговор о мастер-данных с содержательной точки зрения, а не как о "придатке" к обеспечивающей инфраструктуре.
Первой задачей, стоящей перед архитектором (или аналитиком) при построении или развитии информационной системы предприятия или бизнеса, является выделение (идентификация) мастер-данных. Идентифицируются мастер-данные с помощью модели мастер-данных. Под моделью мастер-данных понимается следующая совокупность, составляющая "язык бизнеса", на котором "говорят" между собой все информационные системы:
- определение типов данных (бизнес-данных, справочников, вспомогательных и технологических данных);
- определение событий;
- определение исключительных ситуаций.
При разработке SOA-решений, в том числе подсистем, рекомендуется модель мастер-данных выделять в самостоятельный компонент SOA-решения, оформляя работу над ним в отдельный проект или набор проектов. Все прикладные компоненты SOA-решения, в том числе и разработка модели сервисов, рекомендуется поставить в зависимость от модели мастер-данных, что позволит в дальнейшем существенно уменьшить количество работ по согласованию компонентов системы.
В то же время это абсолютно не означает, что модель мастер-данных разрабатывается раз и навсегда. В процессе развития SOA-решения (или интеграции различных решений) всегда необходимо пересматривать требования к модели мастер-данных и планировать работы по развитию модели мастер-данных вместо того, чтобы определять подмодели данных внутри прикладных компонентов.
Таким образом, поскольку модель мастер-данных является основанием всего SOA-решения, следует очень тщательно и ответственно подходить к первичному определению модели мастер-данных, а также к определению процессов и процедур ее развития. Неудачное планирование модели мастер-данных может существенно увеличить стоимость всего решения и, наоборот, правильное, планомерное развитие модели мастер-данных помогает избавиться от целого спектра ненужных проблем и дополнительных требований в прикладных проектах.
Каноническая модель мастер-данных
Каноническая модель данных - это версия модели мастер-данных, независимая от приложений и прикладных систем предприятия.
Компании часто используют свои внутренние канонические модели мастер-данных, но хорошей практикой при построении SOA-решений является использование отраслевых или других стандартных моделей в качестве основы собственной модели мастер-данных. При таком подходе удается сразу "убить нескольких зайцев":
- архитекторам нет необходимости начинать "с чистого листа";
- основные сущности модели мастер-данных уже отлажены на прикладных проектах;
- снижается частота изменения модели мастер-данных;
- снижаются риски в проектах по разработке моделей мастер-данных, позволяя им выполняться быстрее и с большей вероятностью завершения в срок;
- единое представление данных вместе с моделью сервисов позволяет еще на ранних этапах разработки распараллелить прикладные проекты, а также сделать ненужными дополнительные соглашения между проектными группами;
- снижается зависимость "количество преобразований между приложениями от числа приложений" с экспоненциальной на линейную (в предельном случае);
- увеличивается шанс повторного использования модулей (или таблиц) трансформации в процессе эксплуатации.
В случае существования на предприятии приложений со своей внутренней моделью мастер-данных, архитектор или интегратор взаимодействуют с владельцами таких приложений на предмет приведения внутренних моделей мастер-данных к канонической форме. Если изменение внутренней модели мастер-данных приложения невозможно, то они могут использовать средства интеграции для преобразования вызовов при взаимодействии с такого рода приложениями из канонической формы во внутреннюю форму и наоборот. Наиболее используемыми средствами здесь являются сервисы или функции трансформации и маршрутизаторы на основе содержимого сообщения (Content-based Routers).
Существует множество попыток в различных отраслях выработать стандарт на представление бизнес-данных, которые находятся на различной стадии завершения. Например, во время расцвета идей по электронной коммерции компания ComerceOne сделала популярным формат xCBL, компания Ariba продвигала формат cbXML, а RosettaNet использовала Partner Interface Processes (PiP). В финансовой сфере часто используются форматы FIX и SWIFT, а в здравоохранении - HIPPA и HL7.
Роль такого рода стандартов трудно переоценить, особенно когда необходимо организовать взаимодействие с партнерами, а потенциальные партнеры также используют единый отраслевой стандарт.
В качестве основного средства поддержания канонических моделей мастер-данных в SOA-решениях могут использоваться инструмены класса Enterprise Service Bus (ESB), а именно следующие инструменты продукта Oracle ESB:
- средства по управлению канонической формой модели данных (Domain Value Maps);
- маршрутизаторы на основе заголовков и тела сообщений;
- поддержка расщепления потока данных (Splitter);
- поддержка функций фильтрации и трансформации сообщений в правилах маршрутизаторов.
Модели мастер-данных в форме XML и ее расширение
Поскольку модель данных является основой SOA-решений, а SOA-решения, как правило, гетерогенные и распределенные по своей сути, то важным является вопрос: на сколько модель мастер-данных может успешно использоваться в гетерогенныех распределенныех средах. Разработка подходящей формы модели мастер-данных долгое время занимала архитекторов распределенных систем. Итогом многолетних работ и множества соглашений стала выработка формата XML.
Ранее уже было сказано, что модель мастер-данных разрабатывается отнюдь не раз и навсегда. Более того, для повышения жизнеспособности решений необходимо не только разработать общесистемную модель мастер-данных, но и обеспечить поддержку ее жизненного цикла. В частности, необходимо предусмотреть такие механизмы и средства развития модели данных во времени, которые бы не приводили к разрушению уже реализованных проектов, но обеспечили удовлетворение новых потребностей бизнеса. В случае использования XML, как средства определения модели мастер-данных, по большому счету есть только два механизма корректного расширения модели мастер-данных:
- расширение типов путем наследования или доопределения необязательными типами;
- использование версионности модели данных.
Первый путь мягче и при грамотном построении модели мастер-данных может позволить достаточно долго развивать ее без необходимости перевода всех компонентов системы на новую версию модели мастер-данных.
Второй путь кардинальнее и, как правило, сопровождается структурными изменениями модели мастер-данных и, вследствие, этого приводит к изменению "мажорной" версии всех компонентов, которые используют новую версию модели данных.
Здесь работает тот же принцип расширения, что и для интерфейсов в распределенных системах: изменения совместимые снизу-вверх можно проводить обоими механизмами, а все остальные только через механизм версионности
.
Как же работает расширения типов путем наследования или доопределения необязательными типами? XML позволяет расширять существующие типы данных
новыми необязательными полями и атрибутами, а также определять новые типы данных, содержащие обязательные расширенные поля и атрибуты. В этом случае только приложения использующие расширения должны быть переработаны и смогут их обрабатывать. Для остальных же приложений изменения пройдут прозрачно, и они могут продолжать функционирование без внесения изменений. Рассмотрим несколько сценариев.
Пример 1. Например, Вы решили повысить эффективность обработки определенных заказов. Для этого Вы можете ввести в тип данных "информация о заказе" необязательный параметр "уровень обслуживания":
<ShipInfo serviceLevel="high"> ... </ShipInfo>
Приложения, которые ничего не знают о данном атрибуте, просто игнорируют его и все продолжает функционировать, т. к. остальная структура типа осталась неизменная.
Пример 2. Для того чтобы еще больше повысить эффективность обработки определенных заказов за пределами Ваших бизнес процессов, Вы можете для заказов, отправляемых в США, к обязательным пяти цифрам индекса указать дополнительные четыре цифры. Тогда почтовая служба сможет более точно маршрутизировать заказ конечному получателю. Для этого можно расширить тип "почтовый индекс" необязательным полем:
<ShipInfo> … <Address> … <PostalCode> 01234 <PCExt>5678</PCExt> </PostalCode> </Address> </ShipInfo>
Как и в первом случае, приложения, которые ничего не знают о данном поле, просто игнорируют его. Если же такие приложения тоже нуждаются в дополнительной информации, хорошо бы привести их в соответствие с моделью. Но данный подход снижает техническую необходимость внесения изменений в приложения, оставляя только бизнес-необходимость, что уменьшает количество реализуемых проектов доработок.
Может показаться, что система, в которой отсутствие информации не является ошибкой, плохо спроектирована. Но это абсолютно не так, до тех пор, пока Вы на уровне модели закрепляете необязательность данных с точки зрения бизнеса (например, средствами XMLSchema).
В противном же случае, когда данные обязательны, но по каким-либо соображениям проектного или управленческого характера нет желания разрабатывать новую версию модели, можно в качестве исключения использовать расширение. Чтобы сохранить устойчивость системы в такой ситуации как бы временно неправильного дизайна системы, можно использовать вспомогательные техники.
Использование пространств имен
Использование пространств имен при разработке модели мастер-данных в форме XML описано подробно статье "Практика использования пространств имен XML в проектах, содержащих несколько XML-схем".