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

Попытаемся сформулировать некоторые принципы, которые должны учитываться в процессе проектирования хранения данных в АИС, особенно в условиях наличия во многих из них “лоскутной” автоматизации, ведущей к информационной несовместимости. На наш взгляд, необходимо, кроме чисто технической информации, детально отражать в компонентах АИС и “взгляд” заказчика, ее пользователя. Это важно для обеспечения сопоставимости данных и методов работы с ними, что, соответственно, позволит обеспечить возможность интеграции подобных систем не только на “техническом”, но и на самом общем “смысловом” уровне. Многие задачи должны являться как бы “продолжением друг друга” с точки зрения пользователя и не требовать знания сложных технических особенностей для своего сопряжения.

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

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

Рассмотрим более подробно компоненты АИС, в которых обычно хранится ее семантика. Они представлены на Рис.1.

Рис.1. Компоненты, в которых хранится семантика АИС

Это, прежде всего, словарь данных – “база данных о базе данных”. Традиционно в нем хранится информация, необходимая для функционирования базы данных, а не для принятия решения об использовании этой информации в информационной системе.

Средством отражения требований к системе и ее проектирования являются CASE-средства. Они предоставляют средства для наглядного представления объектов базы данных и связей между ними. Важной особенностью имеющихся CASE-средств является возможность осуществлять с их помощью унифицированное графическое отображение различных реализаций базы данных на физическом уровне в единую логическую модель и тем самым способствовать концептуальной согласованности различных применений одной и той же структуры данных. Важной особенностью в рассматриваемом ключе можно считать наличие в некоторых CASE-средствах (например в ERwin) макроязыка, который может быть использован для обобщения процесса генерации объектов базы данных, формирования “следующего уровня обобщения” структуры и ограничений данных.

Приложения также неявно содержат информацию о семантике АИС. Она находит свое выражение в реализации интерфейсов приложений, экранах помощи, инструкциях по работе с приложением.

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

Любая АИС включает в том или ином виде документацию, выполненную с учетом имеющихся нормативных документов: государственных стандартов, ведомственных и корпоративных нормативных документов. Проблема заключается в том, что требования нормативных документов носят чрезмерно общий характер и не вполне успевают за развитием технологий разработки основных элементов АИС. Кроме того, документация фактически дублирует семантику уже содержащуюся в компонентах АИС: коде приложения, структуре базы данных, типовых элементах данных. В связи с этим в любой АИС существует проблема синхронизации документации и содержания системы. Однако, в последнее время все чаще встречается мнение, что документация как элемент вторичный не является необходимой. Предлагаются также технологии, в которых документация динамически формируется постоянным реинженирингом в процессе разработки и сопровождения АИС. Представляется, что такой подход имеет право на существование при наличии достаточной поддержки в средствах разработки АИС.

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

Из приведенного выше описания составляющих АИС, представленных на Рис.1, что семантика АИС рассредоточена в различных ее компонентах и имеются возможности дальнейшей унификации ее представления и тиражирования с использованием современных коммуникационных возможностей. Это относится как унификации информации о семантике АИС внутри самой системы, так и к унификации метаинформации между взаимодействующими независимыми системами. Так, в частности, ничто не мешает расширить словарь данных СУБД дополнительным семантическим описанием хранимых в нем данных. Для этого необходимо унифицированное “внешнее дополнение” словаря данных, откуда в него могли бы при необходимости заимствоваться семантические описания данных. Содержание и форма представления подобного описания может быть позаимствована, в частности, из наиболее удачных CASE средств, применяемых для разработки баз данных. Однако это не решает полностью проблемы. Необходимо, чтобы семантика баз данных различных систем, использующих одни и те же структуры данных, была согласована.

Имеющиеся CASE-средства и RAD-технологии, применяемые для разработки приложений для работы с данными, также в том или ином наглядном, виде, отражают структуру и логику обращения к БД, хранят в явном и опосредованном виде другую информацию о ней. В средствах разработки приложений в той или иной степени поддерживается отображение структур и ограничений данных, логики работы с ними, доступное для постановщика задачи и понимания квалифицированным пользователем-заказчиком системы. Сам интерфейс приложения включает информацию для пользователя по смысловому содержанию системы в виде включенных в интерфейс подсказок, помощи и инструкций в различном виде. То есть, в приложениях, работающих с базой данных, в том или ином виде отображается информация о базе данных в виде описания структур данных, объектов, их поведения с той или иной степенью обобщения (обусловленной особенностями используемого средства разработки и стилем программирования) с целью поддержки разработки и эксплуатации приложений.

ERP системы являют собой пример “комплексной” унификация семантики системы “в целом”, в пределах системы автоматизации управления предприятием, кругом предприятий, применяющих некоторую ERP-систему. Различные ERP, вследствие конкуренции производителей, в возможной степени защищены от заимствования конкурентами применяемых в них решений. Однако они разрабатываются с возможностями тиражирования компонентов среди различных пользователей собственной системы. Объективно решение вопросов интеграции различных ERP-систем в общем виде невыгодно производителям, заинтересованным в увеличении доли рынка собственного продукта. Это не способствует решению проблем интеграции АИС, построенных на их основе. Конкуренция на рынке подобных систем очень жесткая. Достаточно вспомнить продолжающуюся историю по приобретению фирмой Oracle компании People Soft, в которой даже коммерческие интересы акционеров People Soft находятся не на первом месте.

Традиционно вопрос об интеграции семантики АИС возникает в рамках одной организации, холдинга, другой иерархической управленческой структуры. Для решения этих проблем используются различные технические решения для “технической” интеграции информации АИС. Для решения вопросов, связанных с “технической” несовместимостью данных появляются механизмы, позволяющие эффективно решать эти проблемы. К таким решениям, например, относится Oracle Streams, появившийся в системе Oracle 10G. Этот механизм позволяет осуществлять все виды обмена информацией между взаимосвязанными базами данных на “системном” уровне, используя единую систему обмена очередями сообщений, что минимизирует объем передаваемых данных и позволяет исключить решение этой проблемы разработчиками на уровне отдельных приложений. Однако уровень семантической совместимости информации он не затрагивает.

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

• Среда, в которой разрабатываются и эксплуатируются приложения, различается на разных уровнях. Это различия в применяемых программных средствах, в частности СУБД, то есть “системная” несовместимость данных.
• Семантика данных изначально не увязывается. Каждый разработчик понимает смысл одних и тех же данных по-своему.
• Различная “жесткость ограничений данных”, вызванная как особенностями приложений, так и субъективными факторами. Кроме того, одни и те же ограничения могут быть сформулированы по-разному и не иметь взаимно однозначных соответствий. Примером могут служить классификаторы АИС, которые могут иметь и семантические отличия в целом, в своем определении, и не вполне семантически совместимые конкретные значения.
• Структурирование информации осуществляется с взаимно не согласованных позиций и вызвано объективно различными подходами к постановке задачи. Одна и та же информация отображается в различные структуры данных, в разные по структуре и встроенной функциональности объекты.

Для решения перечисленных проблем, связанных с интеграцией независимо разработанных приложений можно рассмотреть возможности введения дополнительного унифицирующего репозитория, позволяющего облегчить интеграцию данных различных приложений. Те элементы семантического описания, которые могут быть формализованы и являются общими для различных систем и приложений, работающих с этими же типами объектов, могут быть вынесены во внешнюю инфраструктуру “репозитории семантики” баз данных и приложений. Это своего рода “внешний” словарь данных для проектировщиков систем и приложений. Было бы логичным ожидать появления поддержки этого подхода в том или ином виде в различных СУБД и RAD – системах, в том числе и в программных продуктах, поставляемых Oracle.

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

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

Рассматриваемый подход позволяет еще более “повысить” уровень разработки приложений за счет внедрения укрупненных компонентов со встроенной и динамически согласуемой с репозитарием семантикой.

Возможно, СУБД и средства разработки приложений для работы с данными постепенно будут получать инструменты для описания семантики базы данных через обращения к внешним репозиториям. Например, в виде соответствующих механизмов информационной поддержки, встроенных в язык (разработки приложений и описания встроенной логики базы данных), дополнительных атрибутов описания данных, средств унифицированного представления данных и др.

Рис.2 Семантика “вне” и “внутри” автоматизированной информационной системы

Получаемое из сети “Внешнее семантическое дополнение” (External Semantic Extension или сокращенно ESE) словаря данных АИС (см. Рис.2) необходимо, ввиду появления семантических описаний одновременно в разных местах. Оно должно отвечать следующим требованиям:

• содержать достаточную для использования информацию;
• быть стандартным, удобным для стандартизации, содержать механизмы для стандартизации информации в автоматизированном режиме;
• иметь средства встраивания в имеющиеся приложения для обеспечения “прозрачности” взаимодействия с внешней инфраструктурой в автоматизированном режиме.

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

Постараемся определить некоторые примеры факторов, обеспечивающих “достаточность” информации о семантике базы данных в ESE для практической деятельности. Это:

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

Возможна полная и “неполная” совместимость данных об объектах, отражаемых в АИС. Понятно, что поскольку эти системы уже существуют и стандартизация осуществляется “постфактум”, то возможны ситуации, когда достижение полной совместимости семантики информации не достижимо сразу и возможна только частичная ее совместимость. Например: семантика подобных по смыслу справочников не вполне совпадает; целесообразные ограничения в наполнении данных не были первоначально предусмотрены и некорректно введенные данные не могут быть быстро исправлены.

Если полная совместимость не может быть достигнута сразу, полезна ли “неполная” совместимость? Полезна, так как является способом отражения смысловых ассоциаций между данными. Она также может послужить основой для дальнейшей автоматизации способов осуществления информационной совместимости. К тому же современные СУБД позволяют смягчать требования к единообразию данных. Например, в Oracle Database имеется возможность принудительно включать ограничения целостности данных, даже если есть записи, нарушающие общие правила. Поэтому требование “мгновенной” унификации данных, неприемлемое во многих работающих системах, может быть смягчено различными способами.

Применение механизма ESE позволяет получить следующие преимущества:

• обеспечить полноту целесообразных ограничений данных;
• стимулировать внедрение эффективных вариантов структур данных, предлагаемых в идеале их “первоисточником”;
• иметь готовые описания для размещения данных в различных средах хранения;
• сформировать “библиотеку” готовых интерфейсов для работы с данными, включающие формы для ввода, модификации и получения отчетов с использованием стандартизованных данных.

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

Программное обеспечение Oracle постепенно включает в себя все новые тенденции и решения в обработке данных. Поэтому было бы естественно ожидать появления еще одного интегрирующего начала в поставляемом компанией ПО для разработки информационных систем. Внедрения каких качеств можно прогнозировать в СУБД и обрамляющих их программных средствах для разработки АИС в ближайшем будущем в связи с изложенным выше? Это:

• Расширение возможностей по стандартизованному представлению семантики базы данных в рамках словаря данных системы.
• Наличие возможности доступа к информации о семантике данных из средств разработки приложений и языковых средств самой базы данных.
• Расширение коммуникационных возможностей в части обмена согласованными описаниями семантики базы данных. “Повышение уровня” механизмов взаимодействия между базами данных и обрамляющими их интерфейсами на различных этапах построения и эксплуатации АИС за счет учета семантики данных.
• Появление внешних репозитариев семантических описаний баз данных, позволяющих согласованно сопровождать семантику взаимодействующих баз данных.
• Расширение языковых средств, появление “мета-языка”, позволяющего учитывать семантику данных в запросах. Основанные на семантике данных генераторы запросов. Например, основываясь на семантических описаниях можно формировать “мета-запрос”. Полученный с его помощью запрос с использованием SQL (с автоматически сгенерированными комментариями) доработать, при необходимости, вручную.
• Внедрение унифицированных средств описания интерфейсов с использованием репозитариев данных. Унифицированные структуры данных будут стимулировать разработку унифицированных интерфейсов для работы с ними.
• Постепенное внедрение “динамической”, а не “статической” стандартизации различных элементов информационных технологий. То есть, новые стандарты смогут формироваться не “предварительно”, а непосредственно в процессе функционирования информационных систем и в значительной степени в автоматическом режиме.

В настоящее время разработчики АИС часто включают различную информацию, касающуюся семантики информации в базе данных собственными “доморощенными” средствами. Однако следует ожидать появления новых решений в этом направлении. В них необходимо совмещение противоречивых тенденций: сохранение гибкости семантического описания системы, отсутствия проприетарности, но в то же время и формализации, достаточной для беспроблемного встраивания этих описаний в АИС. Более подробно некоторые практические подходы к решению рассмотренных выше вопросов приведены в монографии автора (Л.А.Рейнгольд "Структурирование информации: системный подход"), информация о которой была размещена в предыдущем номере журнала.

04.08.04