Существующие решения систем управления данными в формате XML – Часть1

1. Microsoft SQL Server

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

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

Рисунок 1. Структура платформы данных SQL Server 2005

В SQL Server 2005 добавлены два новых компонента: SQL Server Management Studio (набор инструментов управления базами данных) и SQL Server Business Intelligence Development Studio (набор инструментов разработки приложений интеллектуальной обработки данных). Другие основные компоненты интеллектуальной обработки данных - Integration Services, Analysis Services OLAP, Analysis Services Data Mining и Reporting Services - в SQL Server 2005 значительно изменены и улучшены.

2. Реляционное хранилище данных

Ядро реляционной базы данных обеспечивает безопасные, надежные, масштабируемые, высокодоступные операции над реляционными данными и позволяет работать как со структурированными, так и с неструктурированными XML-данными. Ядро базы данных обеспечивает поддержку .NET CLR (возможность создания хранимых процедур, функций и триггеров на управляемом коде, а также определяемых пользователем типов и агрегатных функций) и расширений ADO.

Реляционное ядро БД хранит подробные записи о транзакциях, генерируемых системами оперативной обработки транзакций (online transaction processing (OLTP) systems), а также осуществляет оперативную аналитическую обработку данных (online analytical processing, OLAP) по запросу специализированных хранилищ данных. Реляционное ядро БД обеспечивает достоверность и защиту хранимых данных, отказоустойчивость, динамически оптимизирует производительность, а также налагает блокировки для реализации параллелизма.

Ядро реляционной базы данных SQL Server 2005 включает несколько интересных возможностей для создания и поддержки различных приложений с хранилищами данных.

Эти возможности включают:

• Табличные секции, обеспечивающие быструю загрузку данных и упрощенную поддержку очень больших таблиц.
• Простое создание сервера отчетности
• Улучшения в Transact-SQL, включая новые типы данных и новые аналитические функции
• Выполнение онлайновых операций над индексами
• Гранулированные операции резервного копирования/восстановления
• Быстрая инициализация файлов

3. SQL Server: поддержка XML

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

В SQL Server 2005 для решения подобных проблем был реализован новый внутренний тип данных. SQL Server 2000 позволяет хранить XML на сервере в виде текста в поле BLOB (Binary Large Objects – бинарные большие объекты), поэтому нет возможности работать с XML или ссылаться на XML на сервере. Для того чтобы работать с данными XML, мы должны были бы извлечь его на уровень приложения, затем воспользоваться стандартным анализатором XML или Document Object Model (DOM) - программным объектом для обработки документов XML. Microsoft SQL Server 2005 предоставляет принципиально новый подход к использованию XML. Введен новый тип данных XML. В этом типе используются методы query (), exist (), value (), nodes () и modify (), которые представляют собой подмножество спецификации XML Query (XQuery). XML-документ перестал быть чем-то неделимым. Благодаря новому типу данных механизм SQL Server понимает данные XML точно так же, как он понимает целые числа или строковые данные. Тип данных XML позволяет создавать как таблицы, которые хранят только XML, так и таблицы, которые хранят и XML, и реляционные данные. Эта гибкость позволяет получить максимальную отдачу от реляционной модели для структурированных данных и пополнить эти данные полуструктурированными данными XML.

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

Для поддержки типа данных XML были добавлены ключевые слова для регистрации и управления схемами XML. Центральные инструменты для работы с XML, FOR XML и OPENXML расширены поддержкой типа данных XML, что позволяет делать запросы к части XML-документа и проверять, что документ соответствует схеме 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 и реляционных данных, мы имеем возможность учесть эту неизбежную неопределенность, что позволит системам более чутко реагировать на изменения и продлит их жизненный цикл. Теперь с содержимым XML-документа можно работать непосредственно, обращаясь к нему по правилам работы с XML-документом, выполнять поиск информации по правилам Xquery и, при этом, пользоваться всей мощью системы индексации SQL Server.

4. Перевод с реляционного языка в XML и наоборот

Реляционный язык – это язык кортежей (неупорядоченных множеств пар «ИмяРеквизита-ЗначениеРеквизита») и отношений (неупорядоченных множеств кортежей, имеющих одинаковый набор имен реквизитов). Внешним представлением сообщений на реляционном языке является набор двухмерных таблиц. Конкретное приложение, работающее с реляционными базами данных, делает разметку отношений, кортежей и значений в таблицы, строки (записи) и клетки (поля) и придает им некоторый внешний вид, обычно по опциональному выбору пользователя.

Внешним представлением сообщений на языке XML является набор реальных документов (и электронных, и бумажных), визуализация которых происходит при помощи универсального браузера (например, Internet Explorer 5) на основании XSL и CSS.

Перевод сообщений с реляционного языка на XML синтаксически не однозначен. Для иллюстрации рассмотрим простой пример, состоящий из 3 отношений, 5 реквизитов и 5 кортежей

Рисунок 2. Пример реляционных данных

В простейшем и наиболее компактном варианте получается следующая конструкция (вариант 1):

<DataBase>

<Tab1 A=”a1” C=”c1”/>

<Tab2 B=”b1” D=”d1”/>

<Tab2 B=”b2” D=”d2”/>

<Tab3 A=”a1” B=”b1” E=”e1”/>

<Tab3 A=”a1” B=”b2” E=”e2”/>

</DataBase>

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

<DataBase>

<Tab1><A>a1</A><C>c1</C></Tab1>

<Tab2><B>b1</B><D>d1</D></Tab2>

<Tab2><B>b2</B><D>d2</D></Tab2>

<Tab3><A>a1</A><B>b1</B><E>e1</E></Tab3>

<Tab3><A>a1</A><B>b2</B><E>e2</E></Tab3>

</DataBase>

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

Направленные связи от записей Tab1 к записям Tab3 и от записей Tab2 к записям Tab3 (Tab3 обычно называют таблицей-связкой для реализации связей типа «многие-ко-многим») указываются одинаковыми значениями ключевых реквизитов A и B. В языке XML связи обычно указываются явно путем вложения тегов друг в друга и путем применения ссылок. Это позволяет в нашем примере убрать ссылочные ключи в Tab3 и установить ссылки на одного родителя путем вложения тега Tab3 в Tab2 и на второго родителя (Tab1) с помощью атрибутов Id и Ref (вариант 3):

<DataBase>

<Tab1 Id=”#1”>

<A>a1</A>

<C>c1</C>

</Tab1>

<Tab2>

<B>b1</B>

<D>d1</D>

<Tab3 Ref1=”#1”>

<E>e1</E></Tab3>

</Tab2>

<Tab2>

<B>b2</B>

<D>d2</D>

<Tab3 Ref1=”#1”>

<E>e2</E></Tab3>

</Tab2>

</DataBase>

Для того чтобы выполнить обратную операцию – привести произвольные XML-данные к реляционным – в первую очередь их необходимо преобразовать к одному из описанных выше вариантов. Для примера возьмем вариант 3.

1. Для каждого тега (в общем виде) вынесем все атрибуты, кроме Id и Ref, и все фрагменты текста в отдельные вложенные теги. Получится следующая структура:

<ИмяУзла Id=”Указатель” Ref1=”Указатель” Ref2=”Указатель”...>

<ИмяАтр1> Значение </ИмяАтр1>

<ИмяАтр2> Значение </ИмяАтр2>...

<ИмяТекста1> Только текст </ИмяТекста1>

<ИмяТекста2> Только текст </ИмяТекста2>

... Только вложенные теги

</ИмяУзла>

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

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

4. Узлы последнего уровня иерархии, которым соответствуют значения реквизитов, не могут содержать ссылочных атрибутов Id и Ref, так как в реляционных данных связи по ключам существуют только на уровне кортежей.

Преобразование варианта 3 в вариант 2 происходит путем включения ключевых тегов, в качестве которых, в общем случае, удобно использовать суррогатные ключи.

Как видно из рассмотренного примера, если данные размещать как текст и «размечать» их именами тегов, а атрибуты использовать только для ссылок, то получается весьма однородная структура, синтаксически несколько более широкая, чем реляционная.