Моделирование данных и XML. Принципы построения статической и динамической модели

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

Еде один способ уменьшения стоимости анализа больших документов —егокэширование в памяти. Например, с помощью страниц ASP компании Microsoft или Java Server Pages можно сохранять данные в сфере действия приложения — вы читаете их в память при загрузке Web-сервера и оставляете там до его закрытия. Подобное хранение гигабайтных документов в памяти дорого стоит (большинство реализации DOM используют приблизительно 10 байт в памяти на каждый байт исходного кода XML), но для данных в мегабайтном диапазоне это достаточно практично, а покупка дополнительной памяти, вероятно, обойдется дешевле, чем покупка программного обеспечения XML Server.

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

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

Сколько типов документов надо создать?

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

Если концептуально в модели используется несколько различных типов документов, представить их на языке XML также можно различными способами:

• Каждый раз создавать свое определение DTD. Если различные типы документов имеют общие компоненты, можно определить внешние параметрические объекты, совместно используемые этими DTD.

• Для всех типов документа использовать одно и то же определение DTD,нодля каждого раздела применять свой тег элемента верхнего уровня. Поскольку в DTD не говорится, какой элемент является элементом документа, в одном определении DTD можно описать несколько типов документа. Затем на компоненты из различных типов документов легко установить ссылки из других типов.

Само определение DTD не должно быть монолитным объектом. С помощью внешних параметрических объектов DTD может содержать определения