XML и базы данных? Доверьтесь своей интуиции

Мы возобновляем рубрику "Технологии XML" и предлагаем вашему вниманию
статью, рассказывающую об одном интересном подходе: XML-базах данных. Эта
статья - своеобразное резюме дискуссии о перспективности этого направления и
целесообразности его развития.

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

Решения, решения

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

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

Так, Брайен Мэджик (Brian Magick), столкнувшись с необходимостью выбрать подходящую технологию баз данных для XML-приложения, обратился к сообществу XML-DEV с вопросом: не пытался ли кто-нибудь собрать соответствующее "дерево решений" ("decision tree"). Позднее он конкретизировал свою задачу.

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

Хотя никто еще пока не создал этого "монстра", нескольким членам XML-DEV удалось поделиться своими мыслями по рассматриваемому вопросу. Это вылилось в продолжительный обмен мнениями, многие из которых сопровождались ценной информацией. Оценка технологии в условиях вакуума трудновыполнима - необходимо иметь некоторые представлениями о предъявляемых требованиях; принятие решения, как правило, подразумевает учет различных факторов. Вот почему достаточно сложно синтезировать в дерево решений обсуждения такого рода - для построения структуры дерева пришлось бы оценивать факторы относительно друг друга, помещая один над другим (в противном случае, все закончилось бы неким месивом, переплетенным сложными внутренними ссылками). Поэтому, чтобы подвести итог состоявшейся на этой неделе дискуссии, было решено использовать другой подход, а именно: "Признаки кода".

Если вы из числа "экстримальных" программистов или знакомы с реорганизацией кода (code refactoring) Кента Бека (Kent Beck) и Мартина Фаулера (Martin Fowler), концепция признаков кода (code smells) будет вам не в новинку. Вот несколько подсказок (code hints), которые помогут вам выяснить, что в коде что-то не так и требуются изменения; например, слишком большое количество параметров у метода. Признаки кода, подобно паттерному проектированию (design patterns), являются сосредоточием программистского опыта. Поэтому, мы могли бы прибегнуть к схожей методике - "необходимые признаки" ("requirement smells") и поделиться с вами некоторыми соображениями, которые могли бы помочь вам принять правильное решение.

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

Если же вам есть что добавить, поделитесь своими соображениями, поместив их на XML.com (см. ниже) или отправьте их на XML-DEV, где они, вероятно, будет прочитаны большинством членов сообщества.

Выбирая базу данных

В каждом из нижеследующих подразделов рассматривается по одному фактору, который следует учитывать при принятии решения, а также приводятся ценные замечания и комментарии, прозвучавшие в ходе недавнего обсуждения. Некоторые из них частично совпадают, а другие, возможно, противоречат друг другу. Некоторые касаются типа данных, который вы храните, другие - то, как вы собираетесь манипулировать данными; часть их носит конкретный характер, тогда как другая - более общий. Что же касается терминологии, XML-база данных (Native XML Database, NXD) и База данных, поддерживающая XML как тип данных (XML Enabled Database, XED) определены в часто задаваемых вопроса по XML базам данных (XML:DB FAQ)

В XML-кругах принято различать документы и данные. Ориентированный на данные (Data-oriented) XML описывает такую информацию, как, например, коммерческие транзакции или записи в телефонной книге, то есть информация такого вида обычно предназначена для приложений. Документоориентированный (document-oriented) XML, в том числе и документы XHTML, наоборот, как правило, представляют интерес для пользователей. В своей статье "XML и база данных" (XML and Database) Рональд Бурре (Ronald Bourret) конкретизирует это различие. В большинстве случаев ориентированный на данные XML легче преобразуется в реляционную базу данных, хотя, бесспорно, следует учитывать сложность описания шаблона документа (DTD). В связи с этим реляционная система управления базами данных (РСУБД) очевидно может претендовать на роль средства хранения данных. Возможно, XED располагает функциональностью, которая поможет автоматизировать преобразование в и из XML. Вероятно, чтобы определить реляционное преобразование для вашей схемы, особенно если она нетривиальна, потребуются некоторая работа по программированию.

"Если у вас XML-"данные", которые легко нормализуются в таблицы реляционной базы, РСУБД или база, поддерживающая XML, вероятно, выполнит эту задачу, по крайней мере, не хуже чем XML-СУБД".(Майкл Чэмпион (Michael Champion))

"Я видел описания типа шаблона документа с сотнями элементов, и определение приемлемого преобразования от них к базе данных - это явно нетривиальная задача, особенно когда многие элементы являются обертками, которые не отображают реальную структуру в базе данных". (Рональд Бурре)

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

"Если у вас XML-"документы" со смешанным контентом, модели с рекурсивным контентом, сложный смешанный состав элементов и атрибутов, и вы желаете выполнять поиск по структуре XML *и* контенту, XML- СУБД, безусловно, практически всегда лучший выбор". (Майкл Чэмпион)

"... смешанный контент плохо преобразуется с помощью объектно-реляционного преобразования. (Я не собираюсь вдаваться в подробности. Более детально об этом написано в разделе 3.3 и 3.4, "Преобразование описаний шаблона документа в базы данных" [Mapping DTDs to Databases]. (Рональд Бурре)

"Гораздо легче поддерживать совокупность XML-документов, используя XML-базу данных, чем преобразовывать эти документы в реляционную базу данных или даже хранить их как "блоб". (Том Брэдфорд (Tom Bradford))

Реляционные базы данных чрезвычайно хороши для хранения высоко структурированной информации и не слишком хороши для управления полуструктурированными данными. Документоориентированный XML обычно имеет изменяющуюся структуру для учета гибкости, характерной для обычной прозы. Однако, не все полуструктурированные данные являются документоориентированными (например, списки материалов). Хотя полуструктурированную информацию можно преобразовать в реляционную модель, возможны накладные расходы на исполнение, особенно при выполнении запросов. NXD или XED с возможностью индексации XML-данных великолепно подходят для такого типа информации.

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

Полуструктурированные данные сложно хранить в реляционной базе данных, поскольку в этом случае у вас либо много различных таблиц (что означает многочисленные соединения и продолжительное время поиска), либо единственная таблица с множеством пустых колонок. Полуструктурированные данные очень легко хранить как XML, и они великолепно подходят для XML-базы данных"(Рональд Бурре)

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

"Структурированные данные крайне негибки. То есть все записи имеют одинаковые поля. Примером структурированных данных может служить телефонный справочник: каждая запись имеет имя, адрес и номер телефона". (Рональд Бурре)

"... Реляционные базы данных, как правило, лучший способ хранения высоко структурированных данных. Хотя, большинство XML-поставщиков, с которыми я обращался, говорят то же самое, никто из них не может сказать точно, где можно провести границу". (Рональд Бурре)

Обычно, чтобы представить структуру заголовок-тело (head-body structure), в XML-схемах используется проектный шаблон, при этом метаданные включаются в заголовок документа, а контент - в тело. В этом случае часто необходимо индексировать именно метаданные в заголовке и обращаться к ним с запросом. Этот шаблон довольно легко преобразовать в реляционную базу данных или XED, поскольку, в частности, метаданные редко используют смешанный контент специально. Если ваша(и) схема(ы) соответствуют этому шаблону, тогда этот способ хранения - подходящее решение. Можно использовать возможность поддержки XML, если необходимо манипулировать контентом тела или обращаться к нему с запросом. Однако, если вам требуется делать сложные запросы к контенту вашего документа, тогда, возможно, лучше выбрать XML-базу банных.

"Если у вас "документ" XML, и схема без труда разделяется на легко нормализуемые метаданные и произвольно структурированный текстовый контент, а большинство запросов будут выполняться по метаданным, тогда, возможно, РСУБД с поддержкой XML, которая извлекает одни элементы в таблицы, а другие - в BLOBs, наиболее подходящий выбор. Если же вам требуется выполнять частые запросы к фактической структуре документа и контенту, XML-СУБД, возможно, окажется более приемлемой". (Майкл Чэмпион)

При рассмотрении технологии базы данных очень важно учесть, каким образом будет происходить доступ к данным. Если у вас ориентированный на данные XML, вероятно, РСУБД - лучший выбор, как и для XML-документов, которые имеют очевидные метаданные. Однако, как только вам потребуется выполнить поиск по всему тексту или манипулировать моделью рекурсивного контента, NXD или XED с подходящим языком XML-запросов кажутся более приемлемым решением.

"Если вам нужно выполнять запросы, которые будут обращаться к рекурсивной структуре ваших данных, XML-СУБД кажется более подходящей, чем "сырая" РСУБД. Например, если вам необходимо выяснить, какие изделия состоят из сборок или подсборок, или элементарных подсборок... которые включают определенную деталь, то XPath лучше обработает такие запросы по сравнению с SQL. (Хорошо известно, что запрос к "списку материалов" - это непростая задача для SQL, для XPath же это пара пустяков.) Полагаю, справедливости ради я должен сказать: "Если вам нужно делать запросы, которые подразумевают соединения по метаданным в различных совокупностях, использование РСУБД, похоже, более приемлемо, чем применение XML-СУБД, по крайней мере, пока разновидность XQuery не получит всеобщей поддержки". (Майкл Чэмпион)

"... SQL располагает гораздо более богатым набором операторов для манипулирования данными по сравнению с XPath (а XQuery лишь до некоторой степени) и (свободно) опирается на общую теорию данных, XML же гораздо более нерегламентирован... если у вы не располагаете относительно сложным XML-документом, то возможности *поиска* XML-СУБД вас не сильно прельстят по сравнению с СУБД, поддерживающей XML как тип. Однако, если у вас "интересная" XML-схема, например с рекурсивными элементами, простые запросы XQuery могут справиться с проблемами, которые трудноразрешимы с помощью SQL". (Майкл Чэмпион)

Хотя, наиболее популярным языком запросов - считается XPath (как правило, с расширениями для запросов ко многим документам), поддерживаются и многие другие языки запросов (все они фирменные). Это справедливо как в отношении реляционных баз данных, поддерживающих XML, так и XML-баз данных.

На это есть свои причины - XPath в достаточной мере развит, чтобы выполнить все запросы, которые необходимы пользователю, а XQuery пока еще не закончен. У меня есть подозрение, что, когда работы по над XQuery будут завершены, появится множество его реализаций". (Рональд Бурре)

Очень часто случается так, что вы располагаете готовым хранилищем данных (в которое сделаны соответствующие капиталовложения), данные которого вы собираетесь использовать вместе со своими XML-данными. В этом случае, возможно, потребуется рассмотреть преимущества интеграции в масштабе предприятия с помощью NXD. Кроме того, могут возникнуть вопросы целостности данных. Помимо этого, возможность использования данных совместно с приложениями, не поддерживающими XML, относится к основным требованиям; зачастую это справедливо в отношении ориентированного на данные XML, и такая ситуация обычно возникает при добавлении XML-отображения в готовую базу данных или репозиторий. С учетом этого, РСУБД или XED - это идеальный выбор.

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

"Данные в реляционной базе данных, поддерживающей XML, доступны как для XML, так и не XML-приложений - что, за редким исключением, нельзя сказать о XML-баз данных. То есть почти ни одна XML-база данных не поддерживает возможность возврата данных в формате, отличном от XML". (Рональд Бурре)

"Другой вопрос - могут ли не XML-приложения использовать данные, не понимая XML. Да - если XML преобразован в таблицы, и нет - если XML хранится в BLOB". (Рональд Бурре)

"Если вы предоставляете данные как существующим приложениям РСУБД, так и XML-приложениям, вероятно, их лучше оставить в РСУБД; XML просто не располагает категорией "целостности ссылочных данных", что может дорого вам обойтись". (Майкл Чэмпион)

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

"Если вы сделали существенные капиталовложения в объектно-ориентированную СУБД (Oracle, MS, IBM) и научились работать с ними, дополнительная поддержка XML может оправдать затраты. Если же вы начинаете с нуля, XML-базы данных в целом дешевле, проще и ими легче управлять по сравнению с СУБД на "универсальном сервере". (Майкл Чэмпион)

",,,"…Ради чего люди, использующие РСУБД для хранения своих классических ключевых корпоративных данных, должны переходить к XML, как модели данных? В конце концов, реляционная модель весьма хорошо удовлетворяет их потребности. Никто еще не сообщал о кризисе, вызванным недостатками реляционной подели. Далее, в таких системах переход от реляционной модели данных к какой-либо иной - рискованное предприятие, которое потребует массы усилий. Для этих баз данных была создана обширная суперструктура: генераторы отчетов, отчеты, написанные для этих генераторов, всевозможные инструментальные средства и расширения, предлагаемые поставщиками, тот факт, что огромная армия людей была воспитана в духе третьей обычной формы, языка SQL, и так далее и тому подобное.

... Достаточно просто представить, как XML-СУБД пытаются вытеснить реляционные СУБД, стараются взять над ними вверх и заменить их, и вы поймете, как все это несерьезно". (Дэн Уэйнреб)

"Если через пять лет поставщики основных РСУБД будут поддерживать средства автоматического импорта/преобразования XML-схемы, возможности бесшовного разрезания/хранения XML-экземпляров и XQuery как язык запросов, чем эти базы будут отличаться от XML-СУБД? У Oracle 9i уже есть XML SQL тип". XML-СУБД появятся, хотя, возможно, мы и не будем НАЗЫВАТЬ их так..." (Майкл Чэмпион)

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

"В целом XML-СУБД кажутся более гибкими для обработке данных при отсутствии схем, как и при привлечении схемы, по сравнению с решениями, основанными на нормализации XML в таблицы РСУБД". (Майкл Чэмпион)

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

"В случае многочисленных источников данных может быть очень выгодно использовать XML для описания структурированных данных... Если вы не полностью контролируете "схему" или форму информации, которая поступает с различных серверов..., использование XML-базы данных, независящей от схемы уменьшит время на разработку и ослабит "бремя" будущего сопровождения: вам будет не нужно создавать и преобразовывать [ряд] реляционных схем, чтобы представить все свои различные... источники, также от вас не потребуется поддерживать эту схему в случае изменений". (Боб Лорд (Bob Lord))

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

"Если вы хотите, чтобы XML-представление отражало копию реального мира (например, XML-заказ на поставку - это "контракт", на который поставлена электронная подпись, чтобы гарантировать невозможность аннулирования этого заказа), а также чтобы это XML-представление изменялось (нарушая электронную подпись!), если меняются базовые данные, в общем XML-СУБД более приемелема". (Майкл Чэмпион)

"Если вы ХОТИТЕ, чтобы ваше XML-представление менялось при изменении базовой информационной единицы (например, адрес клиента в заказе на поставку должен меняться при изменении адреса клиента в базе данных), те или иные решения, основанные на РСУБД, в общем, более приемлемы". (Майкл Чэмпион)

"... у XML просто нет правильной нотации "целостности ссылочных данных", и это может дорого вам обойтись". (Майкл Чэмпион)

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

"XML-СУБД *являются* решениями для всех типов обсуждаемых проблем, особенно в мире, где XML - это "лингва-франка" электронной коммерции. Вы *можете* с помощью "армии" программистов и администраторов баз данных нормализовать XML-заказ на поставку, который приходит в 20-30 таблиц РСУБД из SOAP, Web-страниц и тому подобного... или же это можно сделать гораздо более простым способом - посредством XML-СУБД. (Майкл Чэмпион)

XML-базы данных кажутся отличным способом интегрирования данных из различных обработчиков (backends), и я думаю, что будущее за XML-базами данных - они сделают это прозрачно и реверсивно. (Некоторые делают это уже сегодня.) У реляционных баз данных в этом вопросе могут быть сложности, поскольку результатом интеграции данных из различных источников, вероятно, являются полуструктурированные, а не структурированные данные". (Рональд Бурре)

"Я полностью согласен с тем, что интегрирование данных из различных обработчиков - одна из сильных сторон XML-СУБД, а способность обрабатывать полуструктурированные данные - их основное преимущество.

Некоторые XML-СУБД также прекрасно подходят на роль постоянного транзакционного распределенного кэша среднего слоя". (Дэн Уэйнреб)

"Будь то физический XML или виртуальное представление, интеграция данных - одна из основных причин использования XML, а обеспечение функциональности базы данных для XML-представления - один из неопровержимых доводов в пользу XML-базы данных". (Джонатан Роуби (Jonathan Robie)

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

... если этот жуткий беспорядок связан с модными сегодня словечками типа метаязыки где-то там в Web-е через запутанный клубок CGI/ASP/JSP/SOAP, вызванный различными XML B2B/B2C/A2A-сообщениями, как же вы будете отслеживать, что действительно происходит с точки зрения задач управления, или, как внятно объяснить клиентам, почему они не получили товар, которую заказали в вашем виртуальном магазине, хотя деньги с кредитной карты были сняты? Регистрация же "переходных" XML-данных может помочь". ". (Майкл Чэмпион)

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

Автор: Ли Доддз (Leigh Dodds)