XML-документы хорошо подходят для хранения данных в объектных СУБД
Джереми Бертон: «Занести XML-документ в базу, сделав его постоянным, можно очень быстро, и при этом производительность практически не страдает»

На прошедшей в начале декабря пользовательской конференции Oracle OpenWorld было объявлено о выходе корпорации на рынок Web-служб. Чтобы Oracle смогла закрепиться на рынке серверов приложений на базе J2EE, в Oracle9i Application Server была введена поддержка ряда стандартов Web-служб, улучшены функции кластеризации, добавлена возможность обмена данными с устройствами беспроводной связи, усилена безопасность. Сделать Web-службы, основанные на XML, неотъемлемой частью реляционной СУБД призван проект XDB (XML database support), в рамках которого разрабатывается высокоэффективный механизм хранения XML-документов. Вице-президент корпорации Oracle по глобальному маркетингу Джереми Бертон изложил журналистам еженедельника InfoWorld Майклу Визарду и Стиву Гилмору взгляды руководства Oracle на новые программные технологии и архитектуры.

Одна из острых тем сейчас — хранение XML-документов непосредственно в реляционных базах данных. Можно ли выделить различные по «степени поддержки XML» уровни?

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

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

Так что большинство существующих СУБД просто сохраняют документ в базе, и поиск внутри него производить нельзя. Базы данных и Oracle и, вероятно, IBM позволяют индексировать документ при его сохранении. Допустимая степень структурирования и глубины индексации — предмет серьезных споров. Наша СУБД в этом отношении чуть лучше, чем СУБД IBM, но это преимущество преходящее.

Поэтому мы собираемся решить проблему радикально — этой цели и служит, в частности, проект XDB. Один из краеугольных камней нашей новой системы — объекты. XML-документ представляет собой набор вложенных структур. А что такое объекты в базе данных? Это тоже набор вложенных структур. При этом объект в базу можно занести очень быстро — не нужно выполнять синтаксический разбор в больших объемах и приводить структуры к двухмерному виду, чтобы впоследствии их восстанавливать. Удобство здесь в том (и оно обеспечивается также за счет нашего способа реализации объектов), что для приложения не будет иметь значения, работает ли оно с обычными реляционными таблицами или со структурированными XML-данными. Кроме того, документ сохраняется в очень сжатой форме. Система структурирует его и преобразует к объектному виду. Все теги при этом сохраняются в отдельном каталоге для метаданных. Поскольку туда заносятся все теги, используемые в конкретной компании, это во многих случаях позволяет сохранять информацию в очень сжатом виде.

То есть теги индексируются, а XML-фрагменты документа, так сказать, превращаются в объекты?

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

Много ли дополнительной работы потребуется провести, чтобы организовать преобразование XML-документа к объектному виду?

Нет, для этого требуются лишь стандартные функции объектно-ориентированной базы данных. Мы разработали объектную технологию еще в середине 90-х, в процессе конкурентной борьбы с Illustra. Не знаю, помните ли вы, но в то время как раз шла грандиозная шумиха по поводу объектно-ориентированных баз данных. Когда мы завершили разработку, оказалось, что на самом деле пользователям требуются объекты не в базе данных, а в приложениях. Тогда получил развитие язык программирования С++, а сейчас — Java и EJB. Возможно, это случайное совпадение, но XML-документы идеально подходят для хранения в объектных базах данных, потому что они представляют собой наборы вложенных структур, как и объекты. Занести XML-документ в базу, сделав его постоянным, можно очень быстро, и при этом производительность практически не страдает.

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

Каковы области применения объектных СУБД? Ими пользуются те, кому требуется составлять химические формулы или моделировать сетевые топологии; например, объектные базы данных применяются в индустрии телекоммуникаций. Но ведь все это — не более чем ниши. Вопреки тогдашней шумихе, объекты не стали повсеместно применяемой технологией. Скорее они оказались молотком, ищущим гвоздь, чтобы забить; так вышло, что этим самым гвоздем оказался XML. А мы свой «молоток» смастерили еще три-четыре года назад и, в общем-то, уже давно внедрили его в свою реляционную СУБД.

Пока еще ваша система выполняет синтаксический разбор XML-страниц, но ведь в будущем это уже не понадобится?

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

Вы разрабатываете какую-то особую разновидность SQL для XML-объектов?

Нет. Тут вот в чем дело. XML в чистом виде представляет собой лишь формат для временного хранения данных. Информация хранится в виде XML-документа, только когда она передается от одного предприятия к другому. После того как XML-документ попадает на место назначения, он, вообще говоря, не остается в чистом виде в файловой системе. Полученный документ нужно сохранить так, чтобы им легко было манипулировать или чтобы некоторое приложение могло что-то с ним сделать. Вопрос в том, насколько оперативно можно сохранить документ таким образом. Технология, разрабатываемая нами в рамках проекта XDB, позволяет сохранить XML-документ в таблице точно так же, как и любую реляционную информацию, и производительность при этом не пострадает. XML-документы, объекты в базе данных и реляционные таблицы — это три принципиально разные вещи. Если вы хотите пользоваться обычным языком SQL, замечательно. Инструмент для выдачи запросов даже и знать не будет, что он производит поиск по XML-документам. Если у вас есть какое-то приложение, специально предназначенное для работы с XML, проблем тоже не будет. Оно даже не заметит, что имеет дело с реляционной СУБД.

Немного сменим тему. Производители серверов приложений пытаются создать впечатление, что их продукция является как бы центром вселенной Web-служб. Какова точка зрения Oracle на это? И как в действительности связаны база данных, серверы приложений и Web-службы?

Web-службы играют важную роль в стандартизации интерфейсов обмена данными с приложениями. Однако сами по себе Web-службы — лишь один из фрагментов большой мозаики. Я хочу сказать, что сейчас, как и раньше, 95% времени уходит на разработку бизнес-логики, и только 5% — на реализацию возможности доступа к некоторым составляющим бизнес-логики через Web-службы. Думаю, в основном Web-службы будут использоваться для интеграции слабосвязанных приложений. На мой взгляд, Web-службы имеют большое значение для обеспечения коммуникаций между предприятиями, но идеи типа «построить приложение, связав три тысячи Web-служб», мне кажутся совершенно неосуществимыми. Сказать по правде, реализация стандартов Web-служб — SOAP, UDDI, WSDL — никакого труда не составляет; наши программные продукты все их поддерживают. Инструментарий JDeveloper позволяет быстро построить требуемое приложение, и никаких сложностей не возникнет. Гораздо труднее реализовать поддержку Java или J2EE, чем перечисленные стандарты Web-служб.

По-вашему, Web-служба — это просто слой интеграционного ПО, функционирующего поверх сервера приложений и связанного с СУБД?

Верно. У разработчиков, как и раньше, 90-95% времени будет уходить на написание кода на Java, бизнес-логики. После завершения этой работы определенные части созданного приложения делаются доступными в качестве Web-служб, чтобы компании могли опрашивать его или выполнять с его помощью транзакции. Однако само создание Web-служб — это меньше 5% всей работы. И, как я уже сказал, Web-службы весьма полезны для стандартизации протоколов обмена данными между приложениями. Однако Web-службы не решат все вопросы в сфере создания приложений уровня предприятия. Повторюсь: сборка корпоративного приложения из 3000 слабо связанных компонентов — из области фантастики. Тем не менее, в отличие от многих других производителей Web-служб, мы действительно строим бизнес-приложения. Об этом мы наметили рассказать на конференции Apps World в начале 2002 года: основные функции нашего пакета приложений для электронного бизнеса будут доступны в виде Web-служб. Сейчас же мы с вами говорим всего лишь о достаточно крупных компонентах бизнес-логики и Web-службах, которые позволяют осуществлять к ним доступ.

Означает ли это, что крупномасштабные ERP-приложения можно будет приобретать в модульной комплектации, поскольку ваша система уже поддерживает часть соответствующих функций в виде Web-служб?

Мне кажется, ERP-приложения и сейчас поставляются в виде отдельных модулей, но думаю, что интерфейсы обмена данными с ними будут лучше стандартизованы. Вследствие этого «барьер», через который передается информация между предприятиями, станет гораздо ниже, что позволит повысить КПД межкорпоративных бизнес-процессов. Microsoft, похоже, навязывает всем идею, что Web-службы помогут увеличить оборот предприятия. Oracle же, как производитель приложений, настаивает на том, что Web-службы повысят эффективность бизнес-процессов, обеспечив тем самым экономию. Другими словами, Web-службы — компонент бизнес-приложения, необходимый для обеспечения эффективности процесса.

Считаете ли вы, что Web-службы снимают барьеры, мешающие объединению крупномасштабных систем?

Фундаментально проблему они не решают; не следует считать, что Web-службы — это панацея в области интеграции. Конечно, они помогут переместить транзакцию из пункта А в пункт Б. Допустим, я пользуюсь маркетинговой системой Epiphany; я могу передать информацию о том, какой прирост объема продаж обещает конкретная маркетинговая кампания, в ПО автоматизации деятельности торговых агентов Oracle. Однако на сколько в действительности увеличились продажи, вы не узнаете — для этого потребуется построить хранилище данных и т.д. Другими словами, Web-службы всего лишь позволяют автоматизировать передачу транзакций, не более. К тому же они не решают проблемы несовпадения форм данных.

Итак, в 2002 году Web-службы будут применяться для обеспечения связи между приложениями?

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