Системы управления нормативно-справочной информацией и мастер данными (MDM-системы, Master Data Management) – класс программных продуктов, существующий на рынке уже более 20 лет. Функционал большинства решений этого класса примерно одинаков. Он включает механизмы синхронизации данных между бизнес-приложениями и MDM, консолидации и очистки данных, поддержку выполнения процессов согласования изменений в мастер-данных.
Хранение данных в MDM при этом может быть организовано разными способами. Обычно MDM использует реляционную СУБД для хранения эталонных записей, которые в ней содержатся. Структура мастер-данных считается достаточно простой и стабильной, а объем – относительно небольшим, что позволяет обойтись без сложных решений в области хранения информации.
Однако на практике такая простота часто достигается путем искусственного сужения сферы применения MDM и упрощения структуры данных, что снижает ее ценность для бизнеса. Примеры можно найти в двух наиболее популярных областях применения MDM – управлении данными о клиентах (контрагентах) и об изделиях (продуктах).
Один из первых шагов при внедрении MDM – моделирование структуры данных. При попытке описать структуру информации о клиентах аналитик сразу сталкивается с вопросом: как отразить многообразие типов контрагентов? Их можно разделить на группы по сущности – например, физические лица, юридические лица и индивидуальные предприниматели; по роли – покупатели, поставщики, партнеры. При описании физических лиц каждое из них может выступать в роли сотрудника, члена семьи, покупателя или пользователя определенных продуктов. Каждый конкретный контрагент на практике выполняет сразу несколько ролей. Физическое лицо может зарегистрироваться в качестве индивидуального предпринимателя, а через какое-то время прекратить регистрацию, при этом его свойства как персоны (имя, дата рождения) остаются неизменными, а свойства как ИП (дата регистрации, регистрационный номер) появляются и исчезают. Легко видеть, что со временем меняется не только содержание данных о контрагентах, но и набор свойств, применимых к каждому конкретному контрагенту.
В рамках реляционной модели эту задачу можно решить несколькими способами: созданием одной таблицы с большим количеством столбцов, соответствующих всем возможным свойствам контрагента; разделением информации о контрагенте между несколькими таблицами, в результате чего каждому контрагенту станет соответствовать несколько записей в СУБД; использованием столбцов, хранящих коллекции JSON, что фактически выводит модель хранения данных за рамки реляционной парадигмы. Все эти способы имеют свои недостатки и усложняют управление структурой данных.
При моделировании информации о продуктах (изделиях) типичными сложностями являются:
- Необходимость уложить все изделия в одну иерархию групп продуктов, что приводит к перемешиванию в рамках одной иерархии категорий, выделенных по разным основаниям классификации.
- Необходимость выбрать только одну основную категорию, в которую входит каждый продукт – тогда как на самом деле корректным было бы включение продукта в несколько категорий, выделенных в рамках как одной, так и различных классификационных иерархий.
- Использование различных "костыльных" решений для хранения значений свойств, применимых только к определенным видам изделий.
Все это усложняет работу с информацией о продуктах и фактически приводит к тому, что данные в MDM-системе не адекватно отражают действительность. Обедняется информационная ценность данных, одновременно увеличивается сложность управления ими, что с точки зрения бизнеса существенно снижает ценность MDM-системы.
Отличным способом избежать подобных проблем является использование при создании MDM методов и технологий онтологического моделирования. Такие продукты представлены на рынке. Они выполняют все стандартные функции MDM-системы, но предоставляют ряд существенных преимуществ.
| Классическая MDM | MDM, использующая онтологии |
|---|---|
| Структурирование данных | |
MDM наследует ограничения реляционной модели хранения данных, такие как необходимость отнесения каждого объекта только к одному типу сущностей, отсутствие возможности задать несколько значений для каждого свойства каждого объекта. Чаще всего используется одна иерархия категорий для структурирования каждого справочника. Если MDM-система пытается преодолеть эти ограничения, в ход идут "костыльные" решения, которые существенно усложняют процессы работы с данными и негативно сказываются на скорости работы системы. | MDM использует онтологическую модель хранения данных, в которой:
Использование онтологий позволяет не упрощать содержание данных, отражать все многообразие различных ролей моделируемых объектов и точек зрения на них. При этом обеспечивается простота управления структурой данных. |
| Обмен с бизнес-системами в части структуры модели | |
Чаще всего в классических MDM отсутствует возможность получить описание структуры данных через API. Тем более не реализуется возможность его изменения. | В онтологических технологиях нет разрыва между структурой данных и самими данными, они технологически однородны. Это позволяет распространять описание модели данных бизнес-приложениям по подписке или по запросу. Приложения могут изменять структуру данных с помощью API. Это расширяет сферу применения MDM-системы, добавляя ей функции RDM (Reference Data Model) – хранилища эталонной корпоративной модели данных. |
| Темпоральность | |
Как правило, в MDM-системе хранится только текущее (актуальное) состояние информационных объектов. История значений, если и ведется, доступна только в качестве метаданных, а не собственно данных MDM. Редко реализуется возможность работать с историей значений свойств объектов через API. | MDM-система на основе онтологий может отражать изменения классификационной принадлежности и значений свойств объектов как на уровне самой онтологической модели (для этого существует ряд методик), так и на уровне метаданных. В любом случае это позволяет работать через API MDM-системы не только с описанием текущего состояния бизнес-объектов, но и с любым предшествующим. Это существенно повышает аналитическую ценность данных MDM. |
| Контроль целостности и обогащение данных | |
В классических MDM контроль целостности реализуется с помощью запрограммированных механизмов, позволяющих описывать шаблоны, которым должны соответствовать данные. В лучшем случае используются движки применения правил, такие как Drools. | Важнейшей особенностью онтологий является возможность машинно-читаемого представления правил обработки информации в самой онтологии. Правила контроля логической целостности (форматно-логического контроля), правила обогащения информации (логического вывода) формулируются в терминах структуры онтологической модели и автоматически применяются ко всей информации, хранящейся в MDM. Правила являются неотъемлемой частью онтологической модели, что позволяет распространять их в бизнес-приложения и применять на их стороне. |
| Поддержка во время эксплуатации | |
Бизнес-требования постоянно изменяются, что приводит к необходимости модифицировать структуру данных. Для классической MDM это может стать проблемой – в том числе потому, что структура данных часто явно связана со структурой вызовов API, и изменения в структуре данных приводят к необходимости вносить изменения в код адаптеров обмена или интеграционных процедур между MDM и бизнес-приложениями. | Структура данных в онтологическом мире редактируется так же легко, как и сами данные. Информация об изменениях структуры распространяется в бизнес-приложения. Интеграционные процедуры создаются так, чтобы изменение структуры данных на них не влияло – как максимум, может потребоваться настроить в модели правила сопоставления элементов онтологии элементам схемы данных бизнес-приложений. Это существенно упрощает и ускоряет реализацию новых требований бизнеса. |
Таким образом, MDM-системы, использующие технологии и методы онтологического моделирования, имеют ряд важных преимуществ перед системами, основанными на традиционной реляционной схеме хранения данных. Эти преимущества не оборачиваются недостатками: с точки зрения скорости и объема хранимых данных онтологический MDM опережает классические системы за счет использования технологий виртуализации данных, отсутствия "компромиссных" решений при структурировании информации. Онтологический MDM легко расширить на дополнительные домены данных и области применения. Его поддержка намного проще и дешевле, чем сопровождение громоздкого реляционного MDM – ведь для выполнения многих видов работ с такими продуктами требуется участие программистов вендора или интегратора, тогда как поддержку онтологического MDM в основном осуществляют аналитики.
Перечислим несколько известных в мировой практике проектов по использованию онтологического инструментария для решения задач MDM. Американская компания TopQuadrant сообщает о внедрении системы управления нормативно-справочной информацией (Reference Data) в компании агропромышленного сектора. Компания Metaphacts рассказывает о внедрении MDM в швейцарской энергетической компании, а также о внедрении своих инструментов для управления данными об изделиях и их компонентах в германской промышленной компании . Решение этого же вендора для международного провайдера финансовых услуг фактически выполняет роль клиентского MDM (Customer 360).
Специалисты компании DataVera готовы оказать услуги по внедрению MDM-решений, основанных на онтологиях. Мы обладаем опытом выполнения всех видов работ, необходимых в процессе внедрения – от развертывания ПО и интеграции с источниками данных до формирования модели, очистки данных и создания организационных процедур управления информацией. Если в вашей компании существует несколько бизнес-приложений, обрабатывающих данные об основных объектах, таких как изделия или клиенты – MDM-система вам необходима. Если у вас уже есть MDM, но он слишком дорог в поддержке и не решает всех функциональных задач – задумайтесь о переходе на онтологический MDM. Такое решение сможет не только удовлетворить требования бизнеса, но и станет основой для дата-центрической трансформации всей ИТ-инфраструктуры предприятия.
