Моделирование данных и XML

Использование языка XML для хранения постоянной информации

Проекты сообщений определяются в основном динамическими информационными моделями. Но при использовании языка XML для хранения постоянной информации особенно важны статические модели.

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

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

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

Что делать, если пользователь хочет каждый раз видеть новый небольшой фрагмент информации? Одно из решений: сохранить весь документ DOM в памяти на сервере в области действия приложения. В ответ на запросы пользователей можно фильтровать его и создавать меньшие по размеру документы XML, более точно отвечающие его потребностям. Этот меньший документ можно затем направить клиенту для обработки.

Отображение информационной модели на язык XML

Представление типов объектов

В общем случае тип объекта в информационной модели будет транслирован в тип элемента в структуре XML.

В качестве имени элемента можно использовать название типа объекта или, если нужно сберечь место на диске, это имя можно сократить. Часто для тегов элементов применяются такие короткие имена. Это связано не с экономией дискового пространства, а с тем, что документ XML становится более читаемым: такие теги не слишком отвлекают внимание от содержания.

Если тип объекта входит в состав иерархии типов, нужно определить, на каком уровне иерархии основать элементы XML.

Представление связей

Для представления некоторых связей модели используются вложенные элементы структуры документа XML. Очевидными кандидатами на подобное представление являются связи "содержания".

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

Представление свойств

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

Рассмотрим практические преимущества и недостатки каждого подхода.

Баланс всех факторов зависит от конкретного приложения.

Языки схемы и нотации

Роль схемы

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

Используя слово "допустимость" ( validity ) в этом контексте, следует быть очень осторожным. В соответствии со стандартом XML допустимость означает соответствие документа правилам, содержащимся в DTD. Но сейчас мы говорим о таких ограничениях, которые не могут быть выражены в DTD, а некоторые из них не могут также быть выражены и в схемах XML.

Схемы как набор ограничений

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

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

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

Схемы как объяснение

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

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

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