• Статья

Семантический корпоративный оптимизатор и сосуществование разных моделей данных

П. А. Сундарараджан (P. A. Sundararajan),
компания Infosys Technologies Ltd.

Анупама Нитьянанд (Anupama Nithyanand),
компания Infosys Technologies Ltd.

С. В. Субраманья (S.V. Subrahmanya),
компания Infosys Technologies Ltd.

Декабрь 2009 г.

Краткое содержание.

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

Принятая в качестве стандарта на корпоративном уровне онтология данных (на языке веб‑онтологий [Web Ontology Language, OWL] и на языке правил семантической паутины [Semantic Web Rule Language, SWRL]) необходима для реализации автоматизированной платформы данных, которая повышает возможности работы нынешней системы Microsoft Enterprise Search в течение жизненного цикла и расширяет возможности Microsoft SQL Server благодаря различным механизмам работы с неструктурированными типами дан­ных, а также благодаря множеству типов предметных областей, которые настраиваются пользователями с помощью семантического оптимизатора запросов при использовании Microsoft Office SharePoint Server (MOSS) в качестве хранилища контента и метаданных для связывания всех этих компонентов воедино.

Введение

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

Название модели данных Назначение  
Иерархическая Сложные иерархии основных данных (1:M). Очень высокое соотношение схематичности к объему данных
Сетевая Сложные связи основных данных (M:M). Пространственные сети, науки о жизни, химические структуры, распределенная сеть реляционных таблиц  
Реляционная Простые плоские транзакции. Очень низкое соотношение схематичности к объему данных                
Объектная Сложные связи основных данных с вложенными повторяющимися группами              
XML Интеграция разнородных компонентов; каноническая; эластичная              
Файловые системы Структурированный поиск                        
Ориентированная на записи Получение первичного ключа – оперативная обработка транзакций – последовательная обработка                
Ориентированная на столбцы Получение вторичного ключа; аналитика; сводные показатели; большой объем данных; требует сжатия          
Сущность – атрибут – значение Гибкость; незнакомая предметная область; частые изменения структуры; разреженные данные; одновременная работа с разными типами        
                           

Таблица 1. Модели данных для разных назначений

Выбор модели определяется следующими факторами:

  1. Простота представления и понятность структуры для характера данных.
  2. Гибкость или удобство сопровождения представления данных.
  3. Простота доступа и понятность способов получения данных, в том числе выполнения и языка запросов, навигации или поиска.
  4. Легкость интеграции, которая зависит от удобства сопровождения и понятности.
  5. Вопросы производительности.
  6. Вопросы объема данных.

В зависимости от требований – будь то точный структурированный поиск или основан­ный на подобии неструктурированный неточный поиск – мы можем использовать разнородное сочетание структурированной, полуструктурированной и неструктурирован­ной информации, чтобы предоставить нужный контекст корпоративным пользователям.

Если реляционная база данных облегчает совместное использование данных, то совместное использование метаданных само по себе – проблема. И корпоративная онтология является одним из способов обеспечить интеграцию метаданных, она позволяет улучшить стабильную интеграцию корпоративной информации (Enterprise Information Integration, EII) и возможность взаимодействия, несмотря на неопределенный тип предприятия.

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


Эволюция интеграции на корпоративном уровне

Интересно проследить эволюцию интеграции на корпоративном уровне – от простых приложений для каждой конкретной задачи, которыми пользовались в прошлом, до появ­ления приложений в Интернете, которые могут взаимодействовать друг с другом, что рас­ширяет функциональные возможности для бизнеса и стирает границы внутренних сетей, Интернета и предприятий:

  1. Совестное использование файлов с данными в файловых системах.
  2. Базы данных.
  3. Системы ERP, CRM и MDM.
  4. Технология ETL – хранилище данных.
  5. Интеграция корпоративной информации (Enterprise Information Integration, EII).
  6. Интеграция корпоративных приложений (Enterprise Application Integration, EAI) – сервис-ориентированная архитектура (service-oriented architecture, SOA).
  7. Семантические веб-службы.

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

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

Для решения проблемы несоответствия в схеме или структуре пытались применить подход к данным как к службе с SOA, сервисную шину предприятия (enterprise service bus, ESB) и канонические модели данных, но не обращались к полной семантической совместимости до появления семантических веб-служб.

Семантическая интеграция на корпоративном уровне при помощи корпоративного языка веб-онтологий (OWL) может решить задачу полной семантической совместимости в компании.

Повод для этой статьи: тенденции в отрасли

Многообразие аккомодации и сосуществования

Хранение всех данных в рамках реляционной схемы, ориентированной на строки с третьей нормальной формой (third normal form, 3NF), может быть не оптимальным. Мы видим множество тенденций, например, разные типы механизмов хранения данных, которые можно настраивать и расширять для конкретных типов данных предметной области, создание специальных индексов для предметной области и использование оптимизатора, который может их учитывать, чтобы соответствовать разнородным требованиям относительно типов данных. Эти объектно-ориентированные семантические расширения создаются как приложения поверх ядра базы данных, и существуют API для разработчиков, чтобы настраивать и добавлять собственные неструктурированные или полуструктурированные типы данных. Это используется в поставляемых с продуктом расширениях для пространственных и медиаданных, а также для обработки текста. В некоторых случаях также поддерживаются внутренние типы данных XML.

Microsoft Enterprise Search – это пример решения для поиска разнородных данных в диапазоне от электронных писем в Microsoft Exchange Server до профилей пользователя в Active Directory и каталога бизнес-данных в Microsoft SQL Server RDBMS, а также документов Microsoft Office.

Ведущие игроки предложили решения для работы с неструктурированными данными в виде систем управления контентом, которые опять-таки надо включать в соответствую­щий контекст с традиционными структурированными данными предприятия – как на уров­не метаданных, так и на уровне контента.

Разгрузка во вспомогательные модули

Многие системы управления базами данных поддерживают хранение обновленных строк в строчно-ориентированном виде в соответствии с оперативной обработкой транзакций (Online Transaction Processing, OLTP), хранение данных, сжатых по столбцам и доступных только для чтения, или хранение данных на жестком диске только для записи и хранение в памяти только для чтения. В зависимости от стадии жизненного цикла и характеристик способы хранения часто меняются. Перекладывание части нагрузки на вспомогательные обработчики, которые специализируются на обработке SQL, – это один из приемов, которые мы видим в хранилищах данных.

Рациональное автономное проектирование

Многие системы позволяют оптимально выполнять проектирование или давать рекомен­дации на основе следующих исходных данных:

  • логической схемы;
  • выборочных данных;
  • загрузки запросами.

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

По статистике, лучшие планы предлагают Oracle Query Advisor и Access Advisor.

Рассогласование интерфейсов и семантическая совместимость

Объектно-реляционное отображение (Object-Relation mapping, ORM) – это классическая модель, содержащая два разных инструмента, которые можно использовать для организа­ции одних и тех же данных двумя разными способами. Здесь одни и те же корпоративные данные должны быть представлены через иерархию наследований в объектно-ориенти­рованном решении или в виде одной или нескольких таблиц в реляционной базе данных. LINQ to SQL и LINQ to Entities (платформа Entity Framework) – некоторые из инстру­ментов, которые служат для этих целей.

Что если база данных является иерархической или построена по простой модели «сущ­ность – атрибут – значение»?

Если используемый язык – один из функциональных языков программирования, а исполь­зуемая база данных – одна из объектно-ориентированных баз данных, может возникнуть рассогласование интерфейсов иного рода.

Итак, если между собой должны взаимодействовать разные парадигмы, лучше иметь посредника между ними.

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

Другая область рассогласования интерфейсов – это несогласованность реляционной модели SQL и многомерных выражений (Multidimensional Expressions, MDX) куба OLAP. MDX – это язык, в котором уровни иерархических размерностей семантически содержательны в отличие от SQL, основанного на исчислении кортежей. Здесь снова требуется перевод.

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

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

Модель предметной области является концептуальной и может заменить или использовать в переработанном виде концептуальную связь между сущностями или классово-объект­ные структурные диаграммы UML.

Архитектура потоков данных для семантической корпоративной модели

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

Рисунок 1. Семантический корпоративный оптимизатор и сосуществование моделей данных (щелкните рисунок, чтобы увеличить изображение)

Автономное эволюционное логическое и физическое проектирование

Мы можем предложить автоматическое логическое и физическое проектирование модели данных в зависимости от интенсивности использования, объема данных и стадии жизнен­ного цикла.

На ранней стадии, когда конкретные требования для предметной области еще неизвестны, всегда хорошо начать с модели «сущность – атрибут – значение». Здесь структура задается в окне управления посредством параметров, она основана на определении структуры записи и хранит метаданные и данные по ассоциации.

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

Компонентная модель семантического корпоративного оптимизатора

Семантический корпоративный оптимизатор

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

Службы семантических данных

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

Репозиторий корпоративной семантической онтологии рабочих процессов и правил

Для каждого систематизированного типа данных мы можем определить связи, которым он должен следовать. Например, мы можем сказать, что основная запись сотрудника будет использоваться в компании в качестве исходных данных. Будет применяться семанти­ческая модель инфраструктуры описания ресурсов (Resource Description Framework, RDF), в которой определяются связи этого сотрудника с другими сотрудниками в организации. Основная запись сотрудника также будет распределенной, чтобы сведения о посещае­мости были в инстанции, которая отчитывается, а сведения о зарплате – в центральном офисе, откуда производятся выплаты. Запись сотрудника будет храниться в онлайновых системах транзакций до окончания работы сотрудника в организации. После ухода сотрудника его запись будет сохраняться около года для годовой отчетности, а потом она переносится в репозиторий управления записями, где будет храниться в сжатом виде для особых запросов. Затем через три года она переносится в архивное хранилище, где хранится в сильно сжатой форме. Но ключ, определяющий информацию, хранится в режиме онлайн в репозиториях метаданных, чтобы позволять проводить любые фоновые, асинхронные или автономные проверки, которые могут потребоваться в отно­шении этого сотрудника позже в период существования предприятия.

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

Агент генератора событий

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

Навигатор связей метаданных экземпляра

Каждый экземпляр данных имеет связанные с ним метаданные. Сюда входят такие атри­буты, как дата создания, создатель, создавшая система, адрес, по которому экземпляр доступен на каждом этапе изменения стадии жизненного цикла, и т. д. Сюда также входят различные переводы, которые потребуются для нахождения этих данных в разных систе­мах. Этот компонент помогает находить эти данные.

Область моделей данных

Это разнородное собрание моделей данных, из которых может выбирать оптимизатор при создании и последующих изменениях состояния элемента данных:

  1. Основные и справочные данные – в основном статические; MDM; иерархия; связи; граф; сеть; RDF.
  2. Механизм OLTP – транзакционный; нормализованный.
  3. Механизм куба OLAP – аналитика; жизненный цикл транзакций завершен; анали­тика RDF для связей и семантических отношений.
  4. Управление записями или механизм работы с файлами – архивированные данные; для анализа данных, отчетов о соответствии.
  5. Объектные и объектно-реляционные базы данных для неструктурированной информации – базы данных изображений; получение информации в зависимости от контента.
  6. Текстовые базы данных для анализа текстов, полнотекстовый поиск, обработка естественного языка.
  7. Механизм XML для интеграции обработки распределенных транзакций.
  8. Потоковая обработка – XML.
  9. Метаданные – включают RDF, XML, иерархию, графовую интеграцию разно­образных унаследованных баз данных на уровне ручной и автоматической обработки и кооперацию для предоставления решений для совместной работы.

Здесь должен формироваться запрос и должен быть реализован доступ в реальном вре­мени с соответствующим семантическим переводом.

Когда меняется жизненный цикл данных, есть датчики или системы машинного обучения, запрограммированные, чтобы определять состояние при смене стадии жизненного цикла. Когда подобные изменения обнаруживаются, запись соответствующим образом пере­носится из системы управления транзакциями в OLAP, модуль анализа данных или место архивного хранения в зависимости от связей.

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

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

Заключение

Мы видим, что на корпоративном уровне господствует распределенная сеть GRID на основе графов для разнородных моделей, которые семантически интегрируются в организации; кроме того, корпоративные данные постоянно развиваются за счет логического и физического проектирования на основе данных об использовании, происхождении и характеристиках жизненного цикла.

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

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

Кроме того, динамическая интеграция ограничений предприятия позволит быстрее прини­мать подкрепленные информацией решения во все более динамичном бизнесе.

Благодарности

Первые двое авторов признательны третьему автору, вице-президенту по образованию и науке компании Infosys Technologies Ltd. С. В. Субраманья за выбор и поддержку этой идеи и главному научному сотруднику отдела образования и науки компании Infosys Technologies Ltd. Т. С. Мохану (T. S. Mohan) за всестороннюю и глубокую рецензию.

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

Ссылки

  1. Larson, James A., and Saeed Rahimi. Tutorial: Distributed Database.
  2. Management. Silver Spring, MD: IEEE Computer Society Press, 1985.
  3. Hebeler, John, Matthew Fisher, Ryan Blace, Andrew Perez-Lopez, and Mike Dean (foreword). Semantic Web Programming. Indianapolis, IN: Wiley Publishing, Inc., 2009.
  4. Powers, Shelley. Practical RDF. Beijing; Cambridge: O’Reilly & Associates, Inc., 2003.
  5. Chisholm, Malcolm. How to Build a Business Rules Engine: Extending Application Functionality Through Metadata Engineering. Boston: Morgan Kaufmann; Oxford: Elsevier Science, 2004.
  6. Vertica Systems. Домашняя страница, доступна по адресу http://www.vertica.com(обращение 16.10.2009 г.).
  7. Microsoft Corporation. Enterprise Search for Microsoft. Доступно по адресу https://www.microsoft.com/enterprisesearch/en/us/default.aspx(обращение 16.10.2009 г.).
  8. G-SDAM. Grid-Enabled Semantic Data Access Middleware. Доступно по адресу http://gsdam.sourceforge.net/(обращение 18.10.2009 г.).
  9. W3C. “A Semantic Web Primer for Object-Oriented Software Developers.” Доступно по адресу http://www.w3.org/TR/sw-oosd-primer/(обращение 18.10.2009 г.).
  10. Oracle. Oracle Exadata. Доступно по адресу http://www.oracle.com/database/exadata.html(обращение 21.10.2009 г.).

Об авторах

П. А. Сундарараджан (sundara_rajan@infosys.com) – ведущий сотрудник лаборатории ECOM Research Lab в отделе образования и науки компании Infosys Technologies Ltd. У него почти четырнадцатилетний опыт разработки приложений и архитектуры данных в областях дискретного производства, ипотеки и гарантийного обслуживания.

Анупама Нитьянанд (anupama_nithyanand@infosys.com) – ведущий сотрудник отдела образования и науки Infosys Technologies Ltd. У нее почти двадцатилетний опыт работы в области образования, науки, консультирования и развития персонала.

С. В. Субраманья (subrahmanyasv@infosys.com) ныне занимает должность вице-прези­дента компании Infosys Technologies Ltd. и возглавляет лабораторию ECOM Research Lab в отделе образования и науки Infosys. Он автор трех книг и нескольких докладов, опубли­кованных в рамках международных конференций. У него почти двадцатитрехлетний опыт работы в этой отрасли и в научной области. Специализируется на архитектуре про­граммного обеспечения.