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

Проблемы, связанные с основными данными

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

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

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

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

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

Основные функции служб Master Data Services

Задача MDS — решение проблем, связанных с рабочими и аналитическими основными данными, путем формирования узла основных данных, на котором централизуется упорядочение, хранение и управление. Данный узел поддерживает необходимые функции за счет масштабируемой и расширяемой архитектуры, основанной на SQL Server и API Windows Communication Foundation (WCF). Централизация основных данных во внешней системе позволяет упростить унификацию рабочих приложений для работы с единым достоверным источником. Бизнес-процессы можно привести к использованию узла основных данных в качестве входной системы, что в итоге приведет к распространению изменений на связанные системы. Другой вариант — использовать его как систему хранения для интеграции данных из нескольких исходных систем в консолидированном виде, чтобы упростить и централизовать управление ими. В любом случае централизация основных данных помогает повысить и сохранить качество данных.

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

Помимо гибкости, службы MDS позволяют вести проактивное управление основными данными. Вместо обнаружения ошибок в данных по сбоям ETL или неточностям в отчетах можно задействовать бизнес-пользователей в роли управляющих отдельными элементами данных. В этой роли они получают доступ к диспетчеру основных данных — веб-приложению, предоставляющему права владения процессами, выявляющими и устраняющими проблемы с качеством данных. Например, управляющий может задать условия запуска действий, например создание значения по умолчанию для отсутствующих данных, отправку сообщения электронной почты или запуск рабочего процесса. Управляющие могут использовать диспетчер не только для устранения проблем в данных, но и для изменения основных данных путем добавления новых элементов или изменения значений. Они также могут расширять основные данные дополнительными атрибутами или иерархическими структурами без обращения в службу ИТ-поддержки. С помощью диспетчера основных данных управляющие также могут отслеживать изменения в основных данных с помощью системы ведения журнала транзакций, позволяющей видеть, кто и когда внес изменение, в какой записи оно сделано и в чем оно состояло. При необходимости управляющий также может откатить изменение.

Службы MDS используют встроенную инфраструктуру безопасности Windows для проверки подлинности и детализированную систему ролей для авторизации, что позволяет администраторам предоставлять нужным пользователям доступ для управления основными данными и их изменения. Администратор может предоставить широкий доступ ко всем объектам модели или ограничить доступ несколькими строками или столбцами в наборе данных.

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

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