Особенности построения моделей данных в семантических MDM-системах

Андрей Андриченко
К.т.н., генеральный директор ООО «ЭсДиАй Рисёчь» (дочерняя компания ЗАО «ЭсДиАй Солюшен») — резидент Инновационного центра «Сколково»

Александр Топаж
Д.т.н., ведущий аналитик ООО «ЭсДиАй Рисёчь»

Одним из самых критичных и, в определенной мере, «проклятых» вопросов, с которым приходится сталкиваться при построении интеграционных решений в области комплексной автоматизации бизнес­процессов предприятия, является проблема управления так называемыми общими данными. Действительно, в любой, даже сравнительно некрупной компании, как правило, используется множество предметно­ориентированных информационных систем, решающих актуальные задачи различных служб и подразделений — инженерных, производственных, планово­финансовых, управленческих и т.д. Подобная специализация решений зачастую оправдывается соображениями эффективности. Действительно, при отсутствии необходимости постоянного оперативного взаимодействия между различными подразделениями этот подход позволяет достичь «локального максимума» производительности. Однако разнородные приложения от разных поставщиков оперируют собственными хранилищами и базами данных. При этом данные, содержащиеся в информационных моделях этих приложений, зачастую пересекаются между собой, а один и тот же физический объект или понятие оказываются по­разному описанными в различных системах. В результате образуется дублирование представления информации, а единый целостный взгляд на объект утрачивается.

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

В составе любой корпоративной системы имеются данные, которые подразделяются на три типа:

• метаданные — структура информационной модели;
• мастер­данные — условно­постоянные данные произвольного характера, формирующие состав автоматизируемой предметной области (информация о потребителях, поставщиках, оборудовании, организационной структуре предприятия, топологии сети и т.д., а также НСИ — нормативно­справочная информация, то есть справочники, классификаторы, словари, каталоги продукции и другие источники, содержащие сведения, не претерпевающие существенных изменений в процессе повседневной деятельности компании);
• транзакционные данные — находящиеся в процессе перманентных оперативных изменений сведения о выполнении текущих бизнес­операций — накладные, наряд­заказы, результаты измерений, бухгалтерские проводки, извещения об изменениях объекта проектирования и т.д.

В сферу ответственности специализированных MDM­систем попадают все нетранзакционные данные — в том числе и метаданные, так как внутри этих систем неизбежно используется понятийный аппарат и онтология соответствующей предметной области. А их базовая функциональность должна обеспечивать процесс согласованного и синхронизированного внесения изменений в выделенные обобщенные и централизованные реестры данных перечисленных типов. Согласно определению аналитического агентства Gartner, «MDM — это поддержка глобальной идентификации, связывание и синхронизация информации об объектах в гетерогенных источниках данных через семантическое согласование мастер­данных». Иными словами, MDM — это системный подход к построению единого информационного пространства предприятия для решения задач консолидации условно­постоянных данных справочного характера, унификации сервисов по работе с этими данными и стандартизации форматов их представления и обмена. Укрупненные прецеденты взаимодействия активных агентов корпоративной системы (людей и предметно­ориентированных приложений) с MDM­ядром сводятся к следующим функциям:

• ведение моделей мастер­данных (аналитика, гармонизация…);
• управление изменениями мастер­данных (очистка, выверка, дедубликация…);
• распространение мастер­данных и их изменений по всем компонентам интеграционного решения (синхронизация, репликация…).

В последнее десятилетие, когда повсеместное внедрение электронного документооборота во многих отраслях привело к достижению критической точки «информационного насыщения», существенно возрос интерес к специфическим интеграционным решениям, призванным упорядочить и структурировать многочисленные потоки справочных данных, в частности — к MDM­системам. Так, потенциальная капитализация мирового рынка программных продуктов этого рода по данным на 2015 год оценивается в 3,2 млрд долл. Ключевыми потребителями MDM­систем являются концерны, холдинги и корпорации, заинтересованные в централизованном управлении НСИ. В настоящее время на рынке присутствуют как мощные промышленные решения от ведущих игроков отрасли программного обеспечения Oracle, IBM, SAP, так и специфические разработки сравнительно мелких клиент­ориентированных софтверных компаний: TIBCO, Semarchy и др. Вместе с тем, специфика машиностроительной отрасли выдвигает ряд дополнительных требований к структуре и функциональности подобных продуктов. Представляется, что большинство из них носят критический характер и являются обязательными условиями востребованности и успешного внедрения MDM­систем в сегменте промышленного производства. Далее авторы перечисляют некоторые из этих требований, а также проводят краткий анализ методов и подходов, позволяющих удовлетворить их в рамках соответствующих программных решений.

Специфика машиностроительной отрасли с точки зрения MDM

Принципиальной особенностью информационной модели данных промышленного предприятия дискретного производства, а конкретнее — машиностроительной отрасли, является повышенная значимость нормативно­справочной информации по сравнению с «общепринятыми» мастер­данными (организационная структура, контрагенты и т.д.). Действительно, в данном случае к условно­статической информации общего пользования должна быть отнесена вся номенклатура выпускаемой продукции, а также все средства производства (стандартные изделия, материалы, сырье, оборудование, инструмент, технологическая оснастка), поскольку их учет тем или иным образом присутствует во всех информационных системах, используемых в различных службах предприятия. Причем даже наличие в компании успешно внедренной системы класса ERP (SAP, BAAN, MS Axapta, «1C:Предприятие»), в которых, как правило, реализуется функция ведения НСИ, не исключает необходимости в специализированном MDM­решении. Это объясняется тем, что архитектура даже самой функционально насыщенной ERP ориентирована на решение прикладных задач материального и финансового учета, а управление НСИ рассматривается в ней как вспомогательный сервис, в котором не поддерживаются характерные регламентные процедуры ведения корпоративных мастер­данных. Более того, специфика данных и знаний о номенклатуре и средствах производства в машиностроении обусловливает ряд дополнительных требований и вызовов, которые должны быть в обязательном порядке учтены при проектировании и реализации MDM­системы для данной предметной области. Кратко перечислим наиболее важные из них.

Большой объем и повышенная «динамичность» данных

Количество типов номенклатурных единиц, являющихся продукцией или средствами производства среднего машиностроительного предприятия, исчисляется десятками тысяч. Более того, прямым следствием наличия в информационной системе огромного числа записей о номенклатурных позициях является необходимость постоянного проведения большого числа изменений. Это объясняется тем, что, хотя соответствующие данные формально считаются статическими (в рамках MDM­системы не ставится жесткого требования по отслеживанию полного жизненного цикла описаний соответствующих компонентов), каждая учетная единица время от времени подвергается изменениям — меняются государственные и отраслевые стандарты, в каталогах продукции самого предприятия или его поставщиков появляются новые и исчезают старые позиции и т.д. И если изменения для каждого отдельно взятого элемента можно считать довольно редким событием, для рассматриваемой генеральной выборки элементов в масштабе предприятия суммарная интенсивность запросов на изменение оказывается довольно значительной. В то же самое время, в любой системе MDM, как в централизованном сервисе ввода данных общего назначения, по определению предусматривается довольно жесткая и ответственная процедура редактирования единицы информации, состоящая из множества этапов (предварительный анализ валидности, проведение изменений, синхронизация, согласование, репликация во внешние системы­потребители и т.д.) В случае большого числа изменений проведение всех этих рутинных процедур может потребовать значительного времени от участников данного бизнес­процесса. Кроме того, в дискретном производстве существует определенная неоднозначность в отделении НСИ от типично транзакционных данных, связанная с переходом изделий от «проектных» к «эксплуатационным» этапам жизненного цикла.

Описание семейств однородных изделий

Подавляющую часть номенклатуры машиностроительного предприятия составляют не уникальные изделия и материалы (собственного производства или получаемые по кооперации), а стандартизованные («гостируемые») стандартные изделия. Характерной чертой таких объектов является то, что они группируются в семейства однородных элементов и описываются единым документом — государственным или отраслевым стандартом. При этом все многообразие допустимых конечных экземпляров задается в этих документах в виде типоразмерных таблиц и правил сочетаемости типоразмеров, материалов, покрытий и дополнительных свойств (например, условий поставки). В результате одно такое семейство может содержать в себе описания нескольких десятков тысяч потенциальных экземпляров. Здесь же, то есть на уровне описания семейства, задаются правила формирования уникального обозначения, служащего для уникальной идентификации конечных его представителей. Причем здесь существует две традиции: соответствующие семейства изделий могут быть типоразмерными (при этом обозначение формируется для каждого элемента исходя из значений его ключевых свойств по специально определенному шаблону) или номерными (в стандарте в табличной форме перечислены все возможные сочетания определяющих параметров, и каждому виртуальному изделию присвоен условный номер). Типоразмерными стандартными изделиями являются, например, резьбовой крепеж, сортовой и фасонный прокат, большинство конструкционных материалов. Примерами номерных изделий могут быть многие виды режущего инструмента (резцы, фрезы), подшипники, электронные компоненты. В области проектирования реляционных баз данных аналогами двух этих практик идентификации могут считаться составные естественные или, напротив, синтетические первичные ключи таблиц.

Рис. 1. Место и функции MDM-системы
в информационном пространстве промышленного предприятия

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

Аналитическая модель данных

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

Рис. 2. Фрагмент информационной модели режущего инструмента

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

Однако реальная практика ведения справочных информационных систем на предприятии серьезно расходится с идеальными представлениями. Во­первых, зачастую спроектировать жесткую предопределенную структуру системы невозможно из­за того, что заранее неизвестно, объекты каких типов могут составить ее содержание в будущем. А во­вторых, даже если полный перечень потенциальных объектов известен заранее, проектирование системы «сверху вниз», то есть от общего к частному, требует долгой и высококвалифицированной предварительной аналитической проработки. Результатом этих усилий, в конечном счете, может стать академичная, полностью выверенная модель данных с отсутствием дублирования, инкапсуляцией общих атрибутов в абстрактных классах­предках, четкой иерархией наследования и делегирования свойств и т.д. Но обычно в практике реального производственного процесса никогда не находится ни временных, ни интеллектуальных ресурсов для проведения этой работы в полном объеме. Более того, любые новые потребные данные, как правило, необходимо использовать «здесь и сейчас», а их появление ни в коем случае не должно приводить к коренному пересмотру всей имевшейся до этого структуры. В результате, широкое распространение получает политика заведения данных «как есть, а потом упорядочим», которую приходится рассматривать как неизбежную данность при внедрении систем управления мастер­данными.

Семантическая «насыщенность» системы — поддержка связей между разнородными сущностями

Проблема формулируется следующим образом: должна ли система уровня MDM представлять собой нечто большее, нежели централизованное место хранения и глобальной идентификации для огромного списка разрозненных и никак не связанных между собой сущностей? Действительно, полная информация о том или ином информационном домене (онтология предметной области) предполагает не просто знание набора объектов и их атрибутов, но и тех логических связей (отношений), которые связывают эти объекты между собой. Вопрос лишь в том, в чьей сфере ответственности — системы MDM или предметно­ориентированного приложения — реализуется хранение знаний о наличии и семантике соответствующих связей и управление ими. Некоторые специализированные MDM­решения разрешают этот вопрос в свою пользу, предоставляя в этих продуктах функционал для связывания элементов учета логическими отношениями и задания семантики этих отношений. Представляется, что данный подход особенно актуален в предметной области машиностроения. Действительно, вопросы совместимости различных элементов между собой в контексте той или иной деятельности составляют важнейшую часть функциональности конструкторских и, в первую очередь, технологических приложений. Например, подбор оборудования, инструмента, оснастки под конкретную операцию всегда остается одной из самых нетривиальных задач проектирования технологического процесса. Наличие в технологическом САПР элементов экспертной поддержки, упрощающих выбор оптимальной конфигурации инструментальной системы, резко повышает конкурентные возможности и востребованность подобного решения. Но если сами объекты, составляющие технологические ресурсы проектируемого процесса, ведутся в системе, внешней по отношению к предметно­ориентированному САПР, то логично предположить, что и за установление, редактирование и удаление семантических связей между элементами должна отвечать среда управления мастер­данными. Благодаря наличию в «семантически насыщенной» MDM­платформе объектно­ориентированной модели данных, позволяющей хранить знания о правилах совместимости материально­технических объектов (рис. 3), САПР как клиентское приложение в ходе своего взаимодействия с ней может организовать «осмысленный» расширенный поиск объекта, в котором принимают участие как параметры искомого объекта, так и правила его взаимодействия с другими объектами.

Адекватный ответ на перечисленные вызовы и проблемы требует нетривиальных подходов как на «идеологическом», так и на «техническом» уровне создания MDM­платформы в области машиностроения, то есть на стадии и проектирования ее информационной модели, и ее программной реализации. Далее авторы приводят ряд соображений о возможных решениях на каждом из указанных уровней.

Рис. 3. Консолидация данных и знаний в «семантической» MDM-системе

Принципы и подходы к реализации MDM­систем в области машиностроения

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

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

Напротив, все промышленные системы, создаваемые крупными софтверными компаниями, носят универсальный характер и спроектированы так, чтобы допускать максимальную степень настраиваемости на нужды и бизнес­модель потенциального потребителя. Наиболее частым решением, обеспечивающим гибкость системы, является жесткое разделение ее функциональности на модуль настройки (конфигурирования) системы и модуль непосредственной работы с конечными данными. Внутренняя объектная модель подобных приложений содержит двухуровневую схему абстрагирования, разделяя все информационное пространство на данные и метаданные, при этом информация на верхнем уровне абстракции (метаданные) определяет логику и модель работы с информацией нижнего уровня абстракции (конечными данными как таковыми). Понятно, что в рамках подобного подхода можно достичь очень высокого (в пределе — абсолютного) уровня универсальности. Обратной стороной медали здесь является неизбежно высокий порог вхождения и повышенные требования к квалификации специалиста, осуществляющего и поддерживающего конфигурирование системы для работы в ней конечных пользователей. Достаточно сказать, что для «больших» масштабируемых систем класса PDM или ERP стоимость проектов внедрения зачастую на порядок превышает цену программного продукта, а длительность подобных проектов может исчисляться годами. В реальной практике машиностроительных предприятий, как правило, весьма затруднительно отыскать необходимые для этого временные и интеллектуальные ресурсы.

Все вышеизложенное впрямую проецируется на системы класса MDM. Требования универсальности коробочного решения предполагают полный или частичный отказ от априорной жесткой модели данных и наличие встроенного механизма конфигурирования, который реализован в большинстве существующих продуктов (Convergence в Semarchy, Repository Designer в TIBCO и т.д.) При этом среди пользователей системы должна быть явно выделена роль системного аналитика или архитектора, в сферу ответственности которого входит проведение всей предварительной аналитической работы и создание в конфигураторе системы полного описания онтологии, наиболее адекватно описывающей реалии конкретного предприятия. Только после завершения этих подготовительных операций, требующих, как уже было сказано, значительных затрат времени и высокой квалификации исполнителей, может быть запущена непосредственная работа по вводу конечных данных в рамках созданной и выверенной информационной модели. Таким образом, порог вхождения оказывается очень высоким, а временной промежуток от установки системы до начала получения от нее реальной отдачи — весьма протяженным.

В качестве альтернативного решения, в какой­то мере снимающего остроту противоречия между гибкостью и удобством применения MDM, можно предложить отказ от безусловного доминирования аналитического подхода, то есть от желания получить идеальную модель данных в самом начале введения системы в эксплуатацию. Вместо этого предлагается использовать двунаправленный (смешанный) синтетически­аналитический подход к ведению данных и управлению ими. Процесс взаимодействия пользователя и приложения в рамках этого подхода основывается на следующих принципах. В MDM­системе по­прежнему выделяются функциональные модули разного уровня абстракции, причем некоторые из них отвечают за построение метамодели или онтологического словаря предметной области (определения атрибутов и принципов классификации элементов справочников, задание стереотипов связей между элементами и т.д.), а другие предназначены для ввода и редактирования конечных «производственных» данных. Однако последовательность работы в этих модулях может быть произвольной, и внесение в систему конкретных позиций номенклатуры может осуществляться до их строгой типизации. Иными словами, система реализует как объект­ориентированную, так и факт­ориентированную парадигмы.

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

Описание семейств однотипных типоразмерных и номерных изделий позволяет, помимо прочего, реализовать в машиностроительной MDM­системе функциональность каталогизации и кодификации номенклатуры. Принципиальным вопросом здесь выступает принятый способ описания всего многообразия потенциально доступных к использованию стандартных изделий, составляющих семейство или раздел каталога. Казалось бы, наиболее простое решение — хранение всех возможных вариантов или исполнений как отдельных номенклатурных позиций с выставлением флага применимости у тех из них, которые входят в ограничительный перечень предприятия. Однако при таком подходе число записей в системе становится поистине огромным и даже использование в качестве постоянного хранилища современных СУБД не позволяет обеспечить приемлемой эффективности и производительности операций на выборку и изменение элементов. Альтернативный подход состоит в том, что семейства изделий описываются не набором всех конечных вариантов, а в виде, максимально приближенном к используемому в нормативной документации, то есть как формальный набор правил сочетаемости определяющих характеристик (ограничительные таблицы, формулы и соотношения). При таком подходе всё потенциальное многообразие конечных элементов оказывается «спрятанным» внутри компактного представления, а «настоящими» позициями в информационной системе необходимо оформить только описания экземпляров изделий, реально используемых в производственной деятельности. Декларативное описание семейств типовых элементов в формальных ограничениях позволяет избежать «замусоривания» базы данных огромным количеством записей, но сопряжено с необходимостью разрешения ряда сопутствующих проблем и требований дополнительной функциональности. Так, использование такого подхода предполагает необходимость реализации функционала единичной и пакетной автоматической генерации конечных описаний экземпляров (номенклатурных позиций) в пространстве заданных ограничений, а также возможность поиска элементов с заданными свойствами не только среди действительно применяемых, но и среди потенциально возможных «виртуальных» изделий, составляющих содержание описанных в системе каталогов и стандартов. Кроме того, полноценная поддержка описаний каталогов и кодификаторов невозможна без поддержки парсинга и вычисления формульных и скриптовых выражений, с помощью которых задаются правила формирования обозначений и логические ограничения на валидность значений атрибутов и их сочетаний.

«Семантичность» информационной модели MDM означает описание в ней смысловых информационных связей между объектами системы. В качестве подобной дополнительной смысловой нагрузки совместимости объектов в производственно­ориентированной MDM­системе логично использовать понятие процесса. Это позволяет ввести контекстную точку зрения, согласно которой представление внутренней структуры объекта (компонентов (частей) и «видимых» атрибутов) динамически меняется в зависимости от процессов, в которых он принимает участие. Например, инженер­технолог должен увидеть в металлорежущем станке механизмы перемещения заготовки и режущего инструмента, а инженер­механик — узлы и детали, подлежащие профилактическому осмотру. С помощью той же контекстной точки зрения классифицируются (стереотипизируются) и связи совместимости между объектами, которые распределяются по иерархии описаний вплоть до конечных номенклатурных позиций и их составных частей. В конечном счете формируется семантическая сеть, определяющая взаимосвязи и совместимости объектов, принадлежащие различным категориям. Принципиальным моментом здесь выступает специфическая возможность получения «вычислимой» совместимости в такой сети двух объектов­агрегатов в контексте определенного процесса по совокупной совместимости их составных частей, принадлежащих этому же процессу (Андриченко А.Н. Принципы построения семантических MDM­систем // САПР и графика. 2011. № 5. С. 69­73).

Решения на техническом уровне (на стадии реализации MDM­системы). Для удовлетворения специфических требований, которые предъявляет предметная область машиностроения к системам управления мастер­данными, помимо проектных и идеологических решений можно использовать целый ряд технических приемов на стадии ее программной реализации. Прежде всего это относится к выбору адекватных технических средств и инструментов реализации. Безусловно, требования кроссплатформенности, защищенных протоколов передачи данных, поддержки многопользовательских режимов работы, как десктопных («толстых»), так и сравнительно «тонких» клиентов (в идеале — web­интерфейса для работы в большинстве стандартных интернет­браузеров) не оставляют разработчикам иной возможности, кроме использования специализированных современных платформ создания бизнес­приложений масштаба предприятия в трехзвенной архитектуре. Примером подобной законченной платформы разработки может служить спецификация и стандарт J2EE. При этом многие конкретные аспекты функциональности enterprise­приложения могут быть реализованы с помощью разнообразных и многочисленных средств и сервисов используемой среды (объектно­реляционное отображение, серверы приложений, технология и контейнер EJB и т.д.)

Заключение

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

Принципы построения специализированных систем управления мастер­данными в промышленности, перечисленные в настоящей статье, реализуются в проекте компании ООО «ЭсДиАй Рисёчь» по созданию отечественной MDM­системы нового поколения в области семантического управления корпоративными справочными данными на предприятиях промышленного профиля. Проект компании принят ИЦ «Сколково», прошел внешнюю оценку экспертной коллегии направления «Стратегические компьютерные технологии и программное обеспечение» ИЦ «Сколково», признан инновационным и профинансирован грантом второй стадии.

САПР и графика 6`2015