Развитие XML в SQL Server 2005

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

XML стал стандартным форматом пересылки данных через Internet, а также нашел свое место в других областях, связанных с проектированием приложений (например, хранение данных). Стандарты XML упрощают совместную работу данных различных систем, делая ее независимой как от платформы, так и от архитектуры. Еще одно преимущество состоит в том, что XML - самоописательный формат. Традиционные двоичные форматы хранения данных требуют наличия приложения, которое понимает формат. Но в случае с XML вы описываете и храните данные в одном и том же формате. Кроме того, XML является удобным для человеческого восприятия форматом хранения данных. Доступность для чтения является преимуществом, потому что это избавляет от необходимости явно описывать данные в файле XML перед совместным использованием данных. Поскольку файл XML содержит данные вместе с описанием данных, можно посылать данные, содержащие дополнительную информацию для отдельных частей. Этот тип данных, часто называемый полуструктурированными данными, имеет некоторую внутреннюю структуру, но атрибуты элементов XML могут различаться.

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

Эта структура хранения отличается от реляционного хранилища, состоящего из таблиц, столбцов и строк. Хотя непохоже, что XML когда-нибудь полностью вытеснит двоичные форматы данных или традиционную модель реляционного хранилища данных, отсутствие необходимости заранее определять, какие элементы данных будут содержать или не содержать данные или типы данных перед чтением данных, дает существенные преимущества. При комбинировании данных XML с реляционными данными появляется возможность создавать более гибкие проекты приложений. Например, представьте себе таблицу, которая хранит данные о журнальных статьях. Каждая статья связана с элементами данных, такими как заголовок, текст, автор и редактор. В слабой реляционной модели нам пришлось бы создать таблицу Articles с полями для каждого элемента данных. Но что если у некоторых статей несколько авторов или редакторов, кроме названия есть подзаголовок, или они являются серией статей? Реляционная структура внезапно становится более сложной. Теперь таблица Articles должна содержать дополнительное поле для подзаголовка, таблицу Authors, таблицу Editors и таблицу для серий статей. Помимо этих дополнительных таблиц нам, вероятно, понадобятся несколько связующих таблиц, поскольку редакторы и авторы могут быть связаны со многими статьями. При том, что такие сложные реляционные модели широко распространены, XML может предоставить механизм хранения получше. Все возможные данные о статьях можно представить в виде одного XML файла, наподобие того, который представлен в Листинге 1.

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

В SQL Server 2005 для решения подобных проблем был реализован новый внутренний тип данных. SQL Server 2000 позволяет хранить XML на сервере в виде текста в поле BLOB, поэтому нет возможности работать с XML или ссылаться на XML на сервере. Для того чтобы работать с данными XML, мы должны были бы извлечь его на уровень приложения, затем воспользоваться стандартным анализатором XML или Document Object Model (DOM) - программным объектом для обработки документов XML. Данные, имеющие тип SQL Server 2005 XML, устраняют это ограничение, поскольку этот тип данных является встроенным типом данных первого класса. Благодаря новому типу данных механизм SQL Server понимает данные XML точно так же, как он понимает целые числа или строковые данные. Тип данных XML позволяет создавать как таблицы, которые хранят только XML, так и таблицы, которые хранят и XML, и реляционные данные. Эта гибкость позволяет получить максимальную отдачу от реляционной модели для структурированных данных и пополнить эти данные полуструктурированными данными XML. В нашем примере со статьями мы придерживаемся реляционной модели для хранения статей и добавляем столбец XML к этим данным для хранения информации, которая не является необходимой или может меняться, как, например, подзаголовки.

Чтобы помочь нам извлечь максимальную пользу из этой комбинации полуструктурированных и реляционных данных, внутренний тип данных SQL Server 2005 XML поддерживает несколько встроенных методов, позволяющих запрашивать и модифицировать данные XML. Эти методы воспринимают Xquery, новый стандартный язык консорциума World Wide Web Consortium (W3C), а также навигационный язык XPath 2.0 и язык модификации данных XML. Имеется возможность комбинировать запросы к методам типа данных XML со стандартным T-SQL, создавая запросы, которые возвращают и реляционные данные, и данные XML.

Для большей структурированности или целостности XML-данных SQL Server позволяет связывать схему с конкретным столбцом XML. Если некоторая схема XML связана с некоторым столбцом XML, схема проверяет, правильно ли данные XML вставлены в поле. Но SQL Server 2005 поддерживает несколько схем, сгруппированных в коллекцию, что позволяет применять к столбцу XML разные схемы. Сервер будет проверять правильность всех входящих данных XML по всем схемам. Если XML верен с точки зрения любой из схем коллекции, он может быть сохранен в поле XML.

Для улучшения производительности при наличии XML SQL Server 2005 позволяет создавать индексы по данным XML. Эти индексы работают так же, как стандартные индексы SQL Server и могут существенно увеличить производительность системы во время работы с XML-данными.

Внутренний тип данных XML в SQL Server 2005 позволяет создавать более качественные модели данных, имеющих структуру естественного происхождения. В реальной жизни никакой определенности нет; но сегодня, благодаря комбинированию XML и реляционных данных, мы имеем возможность учесть эту неизбежную неопределенность, что позволит системам более чутко реагировать на изменения и продлит их жизненный цикл. В одной из следующих статей я покажу, как поддержка внутренней службы Web Service в SQL Server 2005 в сочетании с возможностями XML еще больше стирает грань между базой данных и приложениями, которые ее используют.

Мэт Нан (mattnunn@microsoft.com) - старший менеджер группы SQL Server в Microsoft, ответственный за техническую подготовку разработчиков для SQL Server 2005. В прошлом - технический менеджер и консультант в области разработки приложений для SQL Server на различных платформах, включая Visual Basic, Visual Basic .NET и Borland Delphi.

Листинг 1. Файл XML, иллюстрирующий упрощенную структуру реляционных данных.

<feature FeatureID="0-1234-5678-3">
   <author num="1">
        <alias>brand</alias>
     </author>
   <author num="2">
      <alias>mattnunn</alias>
   </author>
   <editor num="1">
      <alias>jamesh</alias>
   </editor>
   <content num="1">
      <Title>The Crowds Go Wild for XML - Part 1</Title>
        <PublishDate>1/1/2005</PublishDate>
        <contentbody> Body of the article here </contentbody>
   </content>
   <content num="2">
      <Title>The Crowds Go Wild for XML - Part 2</Title>
        <PublishDate>2/1/2005</PublishDate>
        <contentbody> Body of 2nd article goes here </contentbody>
   </content>
   <content num="3">
      <Title>The Crowds Go Wild for XML - Part 3</Title>
      <contentbody> Body of 3rd article goes here</contentbody>
   </content>
</feature>