Санкт-Петербургский Государственный Университет
Математико-Механический Факультет
Кафедра Системного Программирования
Сравнение различных методов хранения XML в реляционных базах данных и в разных системах
.
Дипломная работа
студентки 545 группы
Нгуен Тхань Хуен.
| Руководитель
|
Б.А. Новиков |
|
| Рецензент
|
||
| «Допустить
|
А.Н. Терехов |
Санкт – Петербург
2007.
Содержание:
1. Введение …………………………………………………………….
3
2. Научная область исследования ……………………………….....
4
2.1 Языки
XML
……………………………………………………...……4
2.2 Основы реляционных моделей ……………………………………..6
2.3
DTD
и
XML
schema
…………………………………………………..7
2.3.1 Определение типа данных – DTD ……………………....…....7
2.3.3 Схема XML ………………………………………………….10
2.4
XMark
и его запросы ……………………………………………….10
2.4.1 Описание базы данных ……………………………………...11
2.4.1.1 Иерархическая структура
……………………...….11
2.4.1.2 Эталонные запросы
………………………………...13
2.5
XQuery
– язык запросов
XML
……………………………….….…20
2.6 Поддержка
XML
в СУБД ………………………………...….…..…21
2.6.1. В SQL Server 2005 ……………………...…………………...21
2.6.1.1
XML
– Тип данных
……………………………….......22
2.6.1.2
XQuery
в
SQL
Server
2005
………….……………......25
2.6.2. В Oracle ...…………………………………………….…....…27
2.6.2.1 Новый тип данных –
XMLType
………………….….27
2.6.2.2
XQuery
в
Oracle
………………………………….......29
2.7 Другие методы для хранения
XML
в реляционных данных…..29
2.7.1 Относительный подход
DTD
………………………………29
2.7.1.1 Побуждение для специальных методов преобразования схемы
………………………….………..….29
2.7.1.2
DTD
Xmark
…………………………………………...30
2.7.1.3 Часть графа
DTD
Xmark
……………………..….…33
2.7.1.4 Отношение схемы от графа
DTD
…………………34
2.7.2 Поход атрибутов…………………………………………….36
2.7.2.1 Подход
Edge
таблицы
……………………………....36
2.7.2.2 Подход атрибута
……………………………..…….37
3. Эксперименты и результаты
……………………………………...…37
4. Заключение
……………………………………………………...............…
4
0
5. Список литературы
…………………………………………...………....
4
2
Аннотация
В данной работе рассматриваются различных методов хранения XML в реляционных базах данных и в различных системах. Предлагается методы и поддержки XML в СУБД.
1.Введение
Расширенный язык разметки (eXtensible Markup Language, XML) широко распространен как платформо-независимый формат представления данных. Он полезен для обмена информацией между различными слабосвязанными системами, как в приложениях business-to-business (B2B), так и в других ситуациях. Обмен данными был главным двигателем развития технологий XML.
XML все больше используется в приложениях уровня предприятия для моделирования частично структурированных и неструктурированных данных. Одно из таких приложений - это управление документами. Документы, такие, как e-mail, являются изначально частично структурированными. Если документы хранятся внутри сервера базы данных в виде XML, то достаточно мощные приложения могут быть разработаны для получения документов, основанные на содержимом документов, объединении документов, и запросах на получение части содержимого документа, как, например, поиск главы документа с заголовком, содержащим слово "background". Такие сценарии становятся все более возможными с ростом количества приложений, которые генерируют и потребляют XML. Например, система Microsoft Office 2003 позволяет пользователям создавать документы Word, Excel, Visio и Infopath в виде XML.
Почему для данных XML используются реляционные базы данных?
· Хранение данных XML в реляционной базе данных имеет свои преимущества при управлении данными и обработке запросов. SQL Server обеспечивает большие возможности для выполнения запросов к реляционным данным и изменения этих данных, которые были расширены для выполнения запросов по данным XML и их изменения. Это позволяет увеличить отдачу от инвестиций, как, например, в областях оптимизации затрат ресурсов и хранилищ данных. Например, методы индексирования в реляционной базе данных хорошо известны, и они были расширены для индексирования данных XML так, чтобы запросы могли быть оптимизированы с учетом затрат ресурсов.
· Данные XML могут взаимодействовать с существующими реляционными данными и приложениями SQL так, чтобы XML мог быть добавлен в систему при возникновении новых потребностей без серьезного изменения существующих приложений. Сервер базы данных также обеспечивает административную функциональность для управления данными XML (например, резервное копирование, восстановление и репликация).
2.Научная область исследования
2.1.Язык
XML
.
XML (eXtensible Markup Language – расширяемый язык разметки) представляет собой подмножество языки SGML (Standard Generalized Markup Language – стандартный обобщенный язык разметки)
2.1.1 Объявление
XML
Документы XML начинаются с необязательного объявления XML, которое в данном примере содержит обозначение версии XML, применяемой автором документа(1.0) и системы кодировки (UTF-8 соответствует стандарту Unicode), а также содержит сведения о том, имеется ли в документе ссылка на внешние объявления разметки (standalone = ‘yes’ указывает, что в документе отсутствуют внешние объявления разметки). Пролог так:
<? xml version=”1.0” encoding standalone =”yes”>
2.1.2
Элементы
XML
.
Элементы XML, называемые также дескрипторами, представляются собой наиболее широко применяемую форму разметки. Первый элемент документа должен быть так называемым корневым элементом, который может содержать другие элементы (субэлементы). Каждый документ XML должен иметь один корневой элемент. Любой элемент начинается с начального дескриптора и оканчивается конечным дескриптором. Элемент XML чувствительны к регистру, поэтому элемент <DOC> отличный от элемента <doc>. Элемент может быть пустым, и в этом случае его можно сокращенно представить одним дескриптором, например <DOC/>. Элементы должны быть правильно вложенными.
2.1.3 Атрибуты
XML
.
Атрибуты представляют собой пары “имя-значение”, которые содержат описательную информацию об элементе. Атрибуты помещаются внутри начального дескриптора после соответствующего имени элемента, а значение атрибута заключаются в кавычки. Каждый конкретный атрибут может присутствовать в дескрипторе только в одном экземпляре, тогда субэлемент в одном и том же дескрипторе могут повторяться. Например, объявления атрибута: <
Doc
id
= “
id
111”>.
2.1.4 Ссылки на сущности.
Сущностями называются элементы документа, которые выполняют следующие основные задачи:
· Служат в качестве сокращений для обозначения часто повторяющегося текста или позволяют включить в документ содержимое внешних файлов.
· Используются для вставки в текст произвольных символов Unicode (например, для представления символов, которые нельзя ввести непосредственно на клавиатуре);
· Позволяют обозначить различие между зарезервированными символами и информационным наполнением. Например, левая угловая скобка ( < ) обозначает начало начального или конечного дескриптора элемента. Чтобы можно было отличить этот символ разметки от символа, содержащегося в самом информационным наполнении, а язык XML введена сущность lt, которая служит для замены символа <.
Каждая сущность должна иметь уникальное имя, и ее применение в документе XML называется ссылкой на сущность
. Любая ссылка на сущность начинается с символа амперсанда (&) и оканчивается точкой с запятой (;), например <
2.
1.5
Комментарии
Комментарии заключаются в дескрипторы <! -- и -- > и могут содержать любые данные, кроме литеральной строки “--”. Комментарии могут помещаться между дескрипторами разметки в любом месте документа XML, но процессор XML не обязательно должен передавать комментарии приложению.
2.1.6 Разделы
CDATA
и команды обработки.
Раздел CDATA является для процессора XML указанием, что процессор должен игнорировать содержащиеся в этом разделе символы разметки и передавать заключенный в нем текст непосредственно приложению без интерпретации. Для передачи дополнительной информации приложению могут также применяться команды обработки. Команда обработки имеет форму, где служит для приложения идентификатором команды обработки. Поскольку команды зависят от приложения, любой документ XML может содержать несколько команд обработки, позволяющих передать разным приложениям команду на выполнение одинаковых действий, он, возможно, различными способами.
2.1.7 Упорядочение.
В языке XML элементе рассматриваются как упорядоченные, таким образом, в языке XML следующие два фрагмента с переставленными элементами FNAME и LNAME считаются разными:
<NAME>
<FNAME>John</FNAME>
<LNAME>White</LNAME>
</NAME>
<NAME>
<LNAME>White</LNAME>
<FNAME>John</FNAME>
</NAME>
Но атрибуты в XML не являются упорядоченными, поэтому следующие два элемента XML считаются одинаковыми:
<NAME FNAME=”John” LNAME =”White”/>
<NAME LNAME=”White” FNAME=”John”/>
2.2. Основы реляционных моделей.
Реляционная модель основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 60-х гг. доктором Е.Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы — в 1970 г. Реляционная модель определяет способ представления данных (структуру данных), методы зашиты данных (целостность данных), а также операции, выполняемые с данными (манипулирование данными).
В общих чертах основные принципы реляционных систем баз данных можно сформулировать так,
· Все данные на концептуальном уровне представляются в виде упорядоченной организации, определенной в виде строк и столбцов и называемой отношением.
· Все значения являются скалярами.
Это означает, что для любой строки и столбца любого отношения существует одно и только одно значение.
· Все операции выполняются над целым отношением, и результатом выполнения этих операций также является целое отношение. Этот принцип называется замыканием.
Основные операции легко определить в терминах универсальной алгебры. Универсальная алгебра – множество всех возможных значений с набором операций, результат которых лежит в том же множестве. Эти операции так,
· Селекция: Среди кортежей выбираем те, которые удовлетворяют определённому предикату (он строится из простых предикатов, которые являются логическими выражениями на значениях атрибутов).
· Проекция: Проектором называется оператор, квадрат которого есть он сам. Проекция производится на подмножество множества атрибутов. При выполнении проекции надо устранить дубликаты, что является весьма трудоёмкой задачей.
· Произведение: При выполнении операции произведения результирующая таблица получается, как правило, очень большой.
· Соединение: - композиция произведения и селекции, играет важную роль в теории баз данных. Эта операция имеет два операнда, может иметь разные виды зависимости от того,что происходить потом - кроме селекции может быть проекция.
· Естественное соединение: Эта операция важна, так как для нее существует эффективный алгоритм. Мы можем конструировать новые отношения из уже имеющихся. Другие операции тоже позволяют конструировать нетривиальные отношения, большие по размерам.
2.3.
DTD
и
XML
schema
С тех пор XML - способ описать структурные данные должно быть средство определить структуру XML документа. Определения Типа документа (DTD) и XML Схемы - различные механизмы. Они используются, чтобы определить допустимые элементы, которые могут произойти в документе. Они могут произойти и сдержать некоторые аспекты этих элементов в порядке. Ниже печатает из различных средств, сдерживания содержания XML документа.
2.3.1 Определение типа документа (
Document Type Definition - DTD)
DTD состоит из объявлений разметки
(markup declarations), начинающихся с пары символов <!. За этими символами идет одно из слов ELEMENT,ATTLIST,ENTITY,NOTATION,указывающих, что именно объявляется: элемент, список атрибутов, сущность или обозначение. Объявление разметки заканчивается символом ”>”. Структура DTD выглядит следующим образом:
<!DOCTYPE root
_
element
[
<!ELEMENT element_name
(component
)>
other
elements’ or attributes’ declarations
]>
· Объявление типа элемента
Каждый элемент документ XML должен быть описан в объявление типа элемента(element type declaration).Объявление типа элемента начинается с символов <!ELEMENT,после которых через пробел идет имя элемента и объявляется его содержимое.
Проще всего объявляется пустой элемент – отмечается словом EMPTY.Пример: <!ELEMENT doc EMPTY>.
Следующее объявление можно считать полной противоположностью объявлению пустого элемента: <!ELEMENT book ANY>.Элемент с обычным текстовым содержимым и без вложенных элементов объявляется так: <!ELEMENT author (#PCDATA)> . Слово #PCDATA (Parsed Character DATA) означает строку символов, просматриваемую программой-анализатором документа XML.
Если объявляемый элемент содержит вложенные элементы, то объявление должно содержать список их имен, перечисленных через запятую, в скобках. Вложенные элементы должны следовать в документе XML в том порядке, в каком они перечислены в объявление. Кроме вложенных элементов, внутри элемента может встретиться обычный текст, и вложенный элемент может встретиться больше один раз. То обстоятельство, что вложенный элемент можно записать в объявляемом элементе несколько раз, отмечается звездочкой, плюсом или вопросительным знаком. И так:
· Оператор * означает, что компонент может повторяться произвольное количество раз или вовсе отсутствовать.
· Оператор + означает, что компонент должен присутствовать не менее одного раза.
· Оператор ? означает, что компонент может отсутствовать или быть использован только однократно.
· Для моделирования списка компонентов используется оператор списка, который представлен парой круглых скобок, в которых через запятую указаны компоненты.
· Кроме того, в определениях элементов в DTD допускается использование оператора выбора |, разделяющего компоненты и позволяющего допускать присутствие только одного компонента, участвующего в выражении с этим оператором.
· Объявление атрибутов
Атрибуты элемента объявляются уже после объявления самого элемента. Все атрибуты одного элемента объявляются сразу, одним списком. Список начинается с символов <!ATTLIST, после них через пробел следует имя элемента, к которому относятся атрибуты. Затем идут объявления атрибутов. Список, как всегда, заканчивается символом “ > ”.
Для каждого атрибута записывается его имя, тип и признак обязательности. Тип атрибута записывается приведенными далее обозначениями.
· CDATA- строка символов.
· ID-уникальный идентификатор, однозначно определяющий элемент, в котором встретился этот атрибут; значения такого атрибута не должны повторяться в документе.
· IDREF- идентификатор, содержащий одно из значений атрибутов типа ID, используется в качестве ссылки не другие элементы.
· IDREFS- идентификатор, содержащий набор значений атрибутов типа ID, перечисленных через пробелы; тоже используется в качестве ссылки сразу на несколько элементов.
· ENTITY- имя непроверяемой анализатором сущности.
· ENTITIES- имена непроверяемых сущностей.
· NMTOKEN- слово, содержащее только символы, применяемые в именах.
· NMTOKENS- слова, перечисленные через пробелы.
· NOTATION- обозначение.
· Список значений атрибута, перечисляемых через вертикальную черту, в скобках.
Атрибуты типа ID играют ту же роль, что и первичные ключи в таблицах баз данных. Они позволяют различать элементы и индексировать их.
Объявление атрибута заканчивается признаком обязательности присутствия атрибута в элементе или подразумеваемым значением атрибута. Признак обязательности- это одно из трех слов, показывающих, всегда ли нужно записывать атрибут и что будет, если его нет в элементе :
a. #REQUIRED – атрибут надо обязательно записывать в элементе.
b. #IMPLIED – атрибут необязателен, у него нет значения по умолчанию.
c. #FIXED – у атрибута есть только одно значение, которое записывается тут же, через пробел.
· Объявление сущности
Все сущности можно разделить на три группы:
a. Внутренние сущности – задаются при объявлении сущности.
b. Внешние сущности – содержатся в отдельных файлах или встроены в программу- анализатор.
c. Параметризованные сущности – используются только внутри описания DTD.
Объявление внутренней сущности (entity declaration) начинается с символов <!ENTITY, после которых идет имя сущности. Через пробел записывается сама сущность – ее значение в кавычках.
После такого объявления программа- анализатор, увидев в документе ссылку на сущность &имя-сущности
, ссылку на сущность можно применять тут же, в описании DTD. Такие сущности называются внутренними
(internal entities), потому что для их объявления не нужен никакой внешний объект.
Для внешних сущностей (external entities) указывается только место их расположения в виде адреса URI. Перед указанием адреса записывается одно из слов SYSTEM или PUBLIC. Разница между пометками SYSTEM и PUBLIC заключается в том, что после слова PUBLIC идет какое-то общеизвестное объявление. Обычно здесь записывается известная ссылка, введенная консорциумом W3C или другой организацией. Если программа-анализатор не найдет эту ссылку, то она воспользуется адресом URI, идущим за ссылкой.
Объявление параметризованных
сущностей (parametric entities), используемых только внутри описания DTD, выполняется точно так же, как объявление внутренних и внешних сущностей, только между началом объявления <!ENTITY и именем сущности вставляется знак процента, отделенный пробелами. Ссылка на параметризованную сущность начинается с амперсанда, а со знака процента.
· Объявление обозначение
Обозначение (notation) объявляется подобно сущности. Обозначения тоже могу быть внутренними и внешними. При объявлении внутренних обозначений после символов записывается имя обозначения, затем в кавычках – его расшифровка.
При объявлении внешних обозначений используются пометки SYSTEM или PUBLIC, причем за словом не обязательно должна следовать общеизвестная ссылка, так что слова SYSTEM и PUBLIC здесь равнозначны.
2.3.2 Схема
XML.
Схемы данных (Schemas) являются альтернативным способом создания правил построения XML-документов. По сравнению с DTD, схемы обладают более мощными средствами для определения сложных структур данных, обеспечивают более понятный способ описания грамматики языка, способны легко модернизироваться и расширяться. Безусловным достоинством схем является также то, что они позволяют описывать правила для XML- документа средствами самого же XML.
Однако это не означает, что схемы могут полностью заменить DTD- описания - этот способ определения грамматики языка используется сейчас практическими всеми верифицирующими анализаторами XML и, более того, сами схемы, как обычные XML- элементы, тоже описываются DTD. Но серьезные возможности нового языка и его относительная простота, безусловно, дают основания утверждать, что будущий стандарт найдет широкое применение в качестве удобного и эффективного средства проверки корректности составления документов.
В настоящее время в W3 консорциуме идет работа над первой спецификацией схем данных. В этом разделе мы рассмотрим основные возможности схем данных, попытаемся использовать их для проверки корректности ранее описываемых XML- документов.
2.4.
XMark
и его запросы
XMark Эталонная описанная Версия 1.0 берет вызов и показывает набор инструментов чтобы оценить выполнение поиска памяти XML и процессоров запроса: спецификация рабочей нагрузки, масштабируемая база данных документа и всесторонний набор запросов. Чтобы помогать пользователям, каждый из запросов предназначен, чтобы бросить вызов процессору запроса с важным примитивом языка запросов. Это полезно множеством способов: Во-первых, мудрая особенностью экспертиза процессоров запроса оказывается выгодной, поскольку процессор запроса может оперировать разнообразие архитектуры, каждая из которой имеет тенденцию быть удовлетворенной для различных прикладных рабочих нагрузок и показывает специальные характеристики.
2.4.1 Описание базы данных
Дизайн XML Эталонного теста требует, чтобы тщательно смоделированная база данных примера делала поведение запросов, предсказуемых и учла формулировку запросов, что и чувствовать себя естественной и представлять краткие вызовы. Позвольте нам сначала выделять характеристики документа и затем иметь более близкий взгляд на технические проблемы производства таких документов.
2.4.1.1 Иерархическая Структура Элемента
Вложение элементов выполняет полную древовидную структуру XML документов. В этом подразделе мы описываем структуру документа, который смоделирован, после базы данных как развернуто сайтом аукциона Internet. Основные объекты: person, open auction, closed auction, item and category
. Отношения между ними выражены через ссылки за исключением annotations
и descriptions
, которые берут после текста естественного языка и - центральные документом структуры элемента, внедренные в поддеревья, которым они семантически принадлежат. Семантика объектов, только упомянутых следующих:
· Items
- объекты, которые идут для продажи или что уже были проданы. Каждый 'item' несет уникальный идентификатор и имеет свойства подобно оплате (credit card, money order,...), ссылка seller,
description т.д.
, весь закодированный как элементы. Каждый item назначен мировая область, представленная родителем item'а.
· Open
auctions
- аукционы в прогрессе. Их свойства - состояние секретности, хронология предложения (то есть
увеличения через какое-то время) наряду со ссылками претендентам и продавцу, текущему предложению, заданному по умолчанию увеличению, тип аукциона (Dutch, Featured, Regular), интервал времени, в пределах которого предложения приняты, состояние сделки и ссылки к продаваемому item'y.
· Closed
auctions
- аукционы, которые закончены. Их свойства - продавец (ссылка person), покупатель (ссылка person), ссылка к соответствующему item’у, цене, количество проданных item , дата, когда сделка была закрыта, тип сделки, и аннотаций, которые были сделаны прежде, в течение и после процесса предложения цены.
· Person
характеризованы по имени, адрес электронной почты, номер телефона, отправляют по почте адрес, домашняя страница URL, номер кредитной карточки, конфигурация их интересов, набор открытых аукционов, которые они наблюдают.
· Categories
показывают имя и описание; они используются, чтобы осуществить классификацию item. Граф
category
связывает категории в сеть. Эти объекты составляют относительно структурную и ориентированную на данные часть документа: схема правильна на в основание объекта и исключения, типа того не, каждый человек имеет домашнюю страницу, предсказуем. Кроме случайных списков типа предлагающих цену хронологий, порядок ввода не особенно уместен. Это находится на абсолютном контрасте потомству annotations
и description элементов, которые восполняют двойной характер, центральную документом сторону, XML. Здесь длина строк и внутренней структуры подэлементов изменяется очень. Пометка теперь включает перечисленные списки, ключевые слова, и даже форматирование команд и символьных данных, подражание характеристикам текстов естественного языка. Это гарантирует, что база данных закрывает полный диапазон XML воплощений образца, от наверх отмеченных структур данных до традиционной прозы. Приложение дает впечатление от документа, показывая некоторые отрывки.
Иерархическая схема изображена в Рисунке:
2.4.1.2 Эталонные запросы
Этот раздел перечисляет запросы, из которых эталонный тест состоит. Мы хотели выражать запросы в XQuery [CFR+01], преемник Quilt [CRF00], который является о быть стандартизированным. Обратите внимание, что запрос, установленный все еще предварителен.
Q1. Возвратите имя
item
'а с идентификатором ‘item20748’ зарегистрированный в
North
America
FOR $b IN document("auction.xml")/site/regions/namerica/item[@id="item20748"]
RETURN $b/name/text()
- Упорядоченный Доступ
Эти запросы должны помочь пользователям вникать, как система управления базой данных справляется со встроенным порядком XML документов и как эффективный они могут ожидать, что система управления базой данных обработает запросы с ограничениями порядка.
Q2. Возвратите начальные увеличения всех
open
auctions
.
FOR $b IN document("auction.xml")/site/open_auctions/open_auction
RETURN <increase> $b/bidder[1]/increase/text() </increase>
Этот запрос оценивает стоимость поисков массива. Обратите внимание, что этот запрос может фактически быть тяжелее, чтобы оценить, чем это взгляды; особенно относительные внутренности, вероятно, придется изо всех сил пытаться с довольно сложными соединениями частей, чтобы выбрать элемент претендента индексом 1.
Q3. Возвратите кулак и текущие увеличения всех
open
auctions
, текущее увеличение которых не дважды столь же высоко как начальное увеличение.
FOR $b IN document("auction.xml")/site/open_auctions/open_auction
WHERE $b/bidder[0]/increase/text() * 2 <= $b/bidder[last()]/increase/text()
RETURN <increase first=$b/bidder[0]/increase/text()
last=$b/bidder[last()]/increase/text()>
Это - более сложное приложение индексных поисков. В случае относительной системы управления базой данных, запрос может использовать в своих интересах оцененные набором агрегаты на индексном атрибуте, чтобы ускорить выполнение. Запросы Q2 и Q3 являются родственными соединениям частей в TPCD [Gra93] эталонный тест.
Q4. Перечислите резервы тех открытых аукционов, где некоторый человек выпустил предложение перед другим человеком.
FOR $b IN document("auction.xml")/site/open_auctions/open_auction
WHERE $b/bidder/personref[id="person18829"] BEFORE
$b/bidder/personref[id="person10487"]
RETURN <history> $b/initial/text() </history>
- Приведение
Строки - универсальный тип данных в XML документах. Запросы, которые интерпретируют строки, будут часто должны привести строки к другому типу данных, который несет больше семантики. Этот запрос бросает вызов системе управления базой данных в терминах примитивов приведения, которые это обеспечивает. Особенно, если нет никакой дополнительной информации схемы, или только DTD под рукой, приведения, вероятно, произойдет часто.
Q5. Сколько проданных
items
стоит больше чем 40?
COUNT (FOR $i IN document("auction.xml")/site/closed_auctions/closed_auction
WHERE $i/price/text () >= 40
RETURN $i/price)
- Правильные Выражения Пути
Правильные выражения пути - фундаментальный стандартный блок фактически каждого языка запросов для XML или слабоструктурированных данных. Эти запросы исследуют, как хорошо процессор запроса может оптимизировать выражения пути и сократить обходы несоответствующих частей дерева.
Q6. Сколько
items
перечислено на всех континентах?
FOR $b IN document("auction.xml")/site/regions
RETURN COUNT ($b//item)
Q7. Сколько частей прозы находится в нашей базе данных?
FOR $p IN document("auction.xml")/site
LET $c1 := count($p//description),
$c2 := count($p//mail),
$c3 := count($p//email),
$sum := $c1 + $c2 + $c3
RETURN $sum;
-
Преследование Ссылок
Ссылки - неотъемлемая часть XML, поскольку они позволяют более богатые отношения, чем только иерархические структуры элемента. Эти запросы определяют горизонтальные обходы с увеличивающейся сложностью. Хороший оптимизатор запроса должен использовать в своих интересах количества элементов наборов, которые будут присоединены.
Q8. Перечислите имена людей и номера
item
'а, которые они купили. (Присоединяется
к
человеку
,
закрытый
аукцион
)
FOR $p IN document("auction.xml")/site/people/person
LET $a := FOR $t IN document("auction.xml")/site/closed_auctions/closed_auction
WHERE $t/buyer/@person = $p/@id
RETURN $t
RETURN <item person=$p/name/text()> COUNT ($a) </item>
Q9. Перечислите имена людей и имен
item
, которые они купили в Европе.
(
Присоединяется
к
person, closed auction, item)
FOR $p IN document("auction.xml")/site/people/person
LET $a := FOR $t IN document("auction.xml")/site/closed_auctions/closed_auction
LET $n := FOR $t2 IN document("auction.xml")/site/regions/europe/item
WHERE $t/itemref/@item = $t2/@id
RETURN $t2
WHERE $p/@id = $t/buyer/@person
RETURN <item> $n/name/text() </item>
RETURN <person name=$p/name/text()> $a </person>
-
Конструкция Сложных Результатов
Построение новых элементов может поместить механизм памяти под напряжением особенно в контексте создания осуществленных обозрений документа. Следующий запрос полностью изменяет структуру отчетов человека, группируя их согласно конфигурации интереса человека. Большие части отчетов человека неоднократно восстанавливаются. Чтобы избегать простого копирования оригинальной базы данных, мы транслируем пометку во французский язык.
Q10. Перечислите всех людей согласно их интересу; используйте французскую пометку в результате.
FOR $i IN DISTINCT
document("auction.xml")/site/people/person/profile/interest/@category
LET $p := FOR $t IN document("auction.xml")/site/people/person
WHERE $t/profile/interest/@category = $i
RETURN <personne>
<statistiques>
<sexe> $t/gender/text() </sexe>,
<age> $t/age/text() </age>,
<education> $t/education/text()</education>,
<revenu> $t/income/text() </revenu>
</statistiques>,
<coordonnees>
<nom> $t/name/text() </nom>,
<rue> $t/street/text() </rue>,
<ville> $t/city/text() </ville>,
<pays> $t/country/text() </pays>,
<reseau>
<courrier> $t/email/text() </courrier>,
<pagePerso> $t/homepage/text()</pagePerso>
</reseau>,
</coordonnees>
<cartePaiement> $t/creditcard/text()</cartePaiement>
</personne>
RETURN <categorie>
<id> $i </id>,
$p
</categorie>
-
Объединения на значениях
Этот запрос проверяет способность базы данных обработать большие (промежуточные) результаты. На сей раз, объединения - на основе значений. Различие между этими запросами и ссылкой, преследующей запросы Q8 и Q9 - то, что ссылки определены в DTD и могут быть оптимизированы с логическими OID например. Два запроса Q11 и Q12 располагают каскадом в размере набора результата и обеспечивают различные возможности оптимизации. Мы обращаем внимание, что альтернативные формулировки запроса с ‘-> ’ оператор могут использоваться.
Q11. Для каждого человека, перечислите номер
items
в настоящее время в продаже, цена которых не превышает 0.02 % дохода человека.
FOR $p IN document("auction.xml")/site/people/person
LET $l := FOR $i IN document("auction.xml")/site/open_auctions/open_auction/initial
WHERE $p/profile/@income > (5000 * $i/text())
RETURN $i
RETURN <items name=$p/profile/@income> COUNT ($l) </items>
Q12. For each richer-than-average person, list the number of items currently on sale whose price does not exceed 0.02% of the person’s income.
FOR $p IN document("auction.xml")/site/people/person
LET $l := FOR $i IN document("auction.xml")/site/open_auctions/open_auction/initial
WHERE $p/profile/@income > (5000 * $i/text())
RETURN $i
WHERE $p/profile/@income > 50000
RETURN <items person=$p/profile/@income> COUNT ($l) </person>
- Реконструкция
Ключевой дизайн для XML! Отображения системы управления базой данных должны определить критерии фрагментации. Дополнительное действие должно восстановить оригинал документа от его разбитого представления. Сделайте запрос 13 испытаний на способность базы данных восстановить части оригинала XML документ.
Q13. Перечислите имена
item
, зарегистрированных в Австралии наряду с их описаниями
FOR $i IN document("auction.xml")/site/regions/australia/item
RETURN <item name=$i/name/text()> $i/description </item>
-
Полный Текст
Мы продолжаем бросать вызов текстовому характеру XML документов; на сей раз, мы проводим поиск по всей Справке в форме поиска по ключевым словам. Хотя полнотекстовая загрузка сдвигового регистра могла быть изучена в изоляции, мы думаем, что взаимодействие со структурной пометкой является основным, поскольку концепции считают ортогональными; так запрос Q14 ограничен подмножеству документа, объединяя содержание и структуру.
Q14. Возвратите имена всех
items
, описание которых содержит слово 'золото'.
FOR $i IN document("auction.xml")/site//item
WHERE CONTAINS ($i/description,"gold")
RETURN $i/name/text()
- Обходов Пути
В отличие от Раздела правильных Выражений Пути
мы теперь пробуем определить количество затрат длинных обходов пути, которые не включают подстановочные знаки. Мы сначала убываем глубоко в дерево (Сделали запрос 15) и затем возвратились снова (Сделали запрос 16). Оба запросы только проверяют существование путей вместо того, чтобы выбрать пути с предикатами.
Q15. Печатайте ключевые слова в акценте в аннотациях закрытых аукционов.
FOR $a IN document("auction.xml")/site/closed_auctions/closed_auction/annotation//description/parlist/listitem/parlist/listitem/text/emph/keyword/text()
RETURN <text> $a <text>
Q16. Присудите Q15. Возвратите
IDs
продавцов тех аукционов, которые имеют один или более
keywords
в акценте
FOR $a IN document("auction.xml")/site/closed_auctions/closed_auction
WHERE NOT EMPTY ($a/annotation/description/parlist/listitem/parlist/
listitem/text/emph/keyword/text())
RETURN <person id=$a/seller/@person />
- Отсутствующих Элементов
Это должно проверить, как хорошо процессоры запроса знают к dealwith слабоструктурированный аспект XML данных, особенно элементы, которые объявлены дополнительными в DTD.
Q17. Какие люди не имеют
homepage
?
FOR $p IN document("auction.xml")/site/people/person
WHERE EMPTY($p/homepage/text())
RETURN <person name=$p/name/text()/>
Фракция людей без домашней страницы довольно высока так, чтобы этот запрос также представил стимулирующий обход пути декластеризации систем.
- Функциональных Приложений
Этот запрос помещает приложение определяемых пользователем функций (UDF) к доказательству. В XML мире, UDFs имеет специфическое значение, потому что они позволяют пользователю назначать семантику на универсальные строки, которые идут вне принуждения типа.
Q18. Конвертируйте валюту резерва всех открытых аукционов к другой валюте.
FUNCTION CONVERT ($v)
{
RETURN 2.20371 * $v -- convert Dfl to Euros
}
FOR $i IN document("auction.xml")/site/open_auctions/open_auction/
RETURN CONVERT($i/reserve/text())
- Сортировок
Благодаря недостатку схемы, предложения SORT BY часто запускают роль SQL: ORDER BY и GROUP BY. Этот запрос требует сорта на универсальных строках.
Q19. Дайте в алфавитном порядке упорядоченный список всех
items
наряду с их местоположением.
FOR $b IN document("auction.xml")/site/regions//item
LET $k := $b/name/text()
RETURN <item name=$k> $b/location/text() </item>
SORTBY (.)
- Соединений частей
Следующий запрос вычисляет простое соединение частей, назначая каждого человека к категории. Обратите внимание, что соединение частей действительно слабоструктурированно, поскольку это также включает тех людей, для которых уместные данные не доступны.
Q20. Клиенты группы их доходом и выводом количество элементов каждой группы.
<result>
<preferred>
COUNT (document("auction.xml")/site/people/person/profile[@income >= 100000])
</preferred>,
<standard>
COUNT (document("auction.xml")/site/people/person/profile[@income < 100000
and @income >= 30000])
</standard>,
<challenge>
COUNT (document("auction.xml")/site/people/person/profile[@income < 30000])
</challenge>,
<na>
COUNT (FOR $p in document("auction.xml")/site/people/person
WHERE EMPTY($p/@income)
RETURN $p)
</na>
</result>
2.5
XQuery
–
XML Query Language
XQuery - это мощный и удобный язык, предназначенный для обработки XML. Под XML понимаются не только файлы в XML-формате, но и другие данные, похожие на XML, включая базы данных, структура которых представляет собой вложенные, поименованные деревья с атрибутами.
XQuery - это интересный язык с некоторыми необычными понятиями.
2.5.1 Язык выражений
В XQuery любая конструкция - это выражение, результатом вычисления которого является некоторое значение. Программа XQuery или скрипт - это просто выражение вместе с некоторыми необязательными функциями и другими определениями.
У стандарта XQuery нет изменений или уточнений, хотя, вероятно, в будущем они появятся. Эта спецификация определяет результирующую величину выражения или программы, но не устанавливает, как ее нужно вычислять.
Для описания локальных переменных используется выражение let:
let $x := 5 let $y := 6 return 10*$x+$y
2.5.2 Примитивные типы данных
Примитивные типы данных XQuery такие же, как в XML Schema:
· числа, включая целые и числа с плавающей запятой;
· булевы числа: true (истина) и false (ложь);
· строки символов;
различные типы для представления дат, времени и продолжительности.
2.5.3 Величины узлов и выражения
В XQuery также есть типы данных, необходимые для представления величин XML. Для этого используются величины узлов следующих семи типов: элемент, атрибут, пространство имен, текст, комментарий, инструкция обработки и документ (корень).
Для создания и возврата узлов используются различные стандартные функции XQuery. Так, функция document читает XML-файл, указанный аргументом URL, и возвращает корневой узел документа. (Корневой элемент - это потомок корневого узла).
Новые узлы можно также создавать непосредственно в программе.
Чтобы поместить выражение XQuery внутрь конструкторов элементов следует воспользоваться {} (фигурными скобками). Так,
let $i := 2 return let $r := <em>Value </em> return <p>{$r} of 10*{$i} is {10*$i}.</p>
создает
<p><em>Value </em> of 10*2 is 20. </p>
2.5.4 Последовательности
Рассмотренные атомарные величины (числа, строки и т.п.) и величины узлов (элементы, атрибуты и т.д.) известны как простые величины. Результатом вычисления выражения XQuery на самом деле является последовательность простых величин.
Проиллюстрируем это - для этого воспользуемся функцией count, которая принимает один аргумент и возвращает число величин в последовательности. Тогда выражение
let $a := 3,4 let $b := ($a, $a) let $c := 99 let $d := () return (count($a), count($b), count($c), count($d))
равняется (2, 4, 1, 0), потому что $b то же самое, что и (3,4,3,4).
2.5.5 Выражения XPath и отношение к XPath
В XQuery используются path expression XPath. XQuery можно рассматривать как обобщение XPath. За исключением некоторых малоизвестных форм (в основном необычных "осевых спецификаторов") все выражения XPath являются также и выражениями XQuery. По этой причине комитет, занимающийся XQuery, также работает и над спецификацией XPath - планируется, что XQuery 1.0 и XPath 2.0 будут опубликованы одновременно.
Необходимо отметить следующее различие между XPath и XQuery - выражения XPath могут вернуть множество узлов (node set), а такое же выражение XQuery возвращает последовательность узлов. Для обеспечения совместимости эти последовательности находятся в документальном порядке, в них удалены дубликаты - благодаря этому они эквиваленты множествам.
2.5.6 Итерация по последовательностям
Выражение for позволяет организовывать цикл по элементам последовательности:
for $x in (1 to 3) return ($x,10+$x)
В этом примере получается последовательность из шести элементов: 1,11,2,12,3,13.
Термин "выражение FLWR" относится и к выражению for, и к выражению let. Аббревиатура FLWR расшифровывается как одно или несколько операторов for и/или let, необязательный оператор where и оператор result. Оператор result вычисляется только тогда, когда выражение where истинно (true).
2.5.7 Функции
Без функций, определяемых пользователем, XQuery был бы далек от языка от программирования. Определения таких функций располагаются в прологе запроса (query prologue) программы XQuery.
2.5.8 Сортировка и контекст
Для сортировки последовательности используется выражение sortby. Чтобы упорядочить последовательность книг по имени автора можно сделать следующее:
$books sortby (author/name)
Выражение sortby берет входную последовательность (в данном случае $books) и одно или несколько выражений упорядочения (ordering expressions). При сортировке реализация должна сравнивать две величины из входной последовательности, чтобы определить, какая должна идти первой. Для этого вычисляется выражение(я) упорядочения в контексте величины из входной последовательности. Поэтому path expression author/name вычисляется множество раз, каждый раз относительно разной книги, используемой в качестве контекстуальной (или текущей) единицы (context (or current) item).
Path expression также используют и устанавливают этот контекст. В author/name возвращаемые потомки name - это потомки из контекстуальной единицы author.
2.5.9 Определение типов
XQuery - это смесь статического (проверка совместимости типов во время компиляции) и динамического контроля типов (тестирование типов во время выполнения). Однако, типы в XQuery отличаются от классов, присущих объектно-ориентрованному программированию. Взамен XQuery включает типы, которые соответствуют модели данных XQuery, и позволяет импортировать типы из XML Schema.
2.6. Поддержка
XML
в СУБД
2.6.1. В
SQL
server
2005
SQL Server 2005 обеспечивает обширную поддержку хранению и обработку XML данных. Вы можете сохранить XML документы и фрагменты прирожденно как столбцы и переменные T-SQL нового xml типа данных. Xml столбцы типа данных может быть индексирован, напечатан согласно XML схеме, и управлял использованием XQuery и XML Языком Манипулирования данными (язык DML).
Некоторые причины сохранять данные как XML включают следующее:
· использование административных возможностей сервера SQL, чтобы управлять XML данными
· эффективно совместное использование, запрос, и создание мелкомодульных модификаций к вашим XML данным
· гарантировать, что данные утверждены против существующей XML схемы
В дополнение к нативному сохранению XML данные, SQL Server 2005 позволяет Вам отображать относительные данные к XML данным, используя XQuery функции расширения и отображать XML данные к относительным данным, используя предложение FOR XML.
2.6.1.1
Xml
Data
–
Типа данных
Новые xml типа данных подержат сохраняющие и XML документы и фрагменты в базе данных. Фрагмент XML - XML образец, который не имеет единственного (корневого) элемента верхнего уровня. Вы можете создать столбцы, параметры, и переменные нового xml типа и сохранить XML образцы в них. Xml типа данных имеет максимальный размер 2GB.
2.
6
.1.1.1. Создание столбцы и переменные
xml
типа данных
Следующие подразделы описывают, как создать столбцы и переменные T-SQL xml типа данных:
2.6.1.1.
1.1 Столбцы
Используйте инструкцию CREATE TABLE, чтобы создать таблицу, которая содержит один или более столбцов c xml типа данных. Синтаксис чтобы создавать таблицу столбцы c xml типа данных:
CREATE TABLE table
_
name
( ... xml_column_name
xml [[DOCUMENT | CONTENT](schema_name.xml_schema_collection_name
) ], ... )Где
table
_
name
-
Имя таблицы в базе данных
xml
_
column
_
name
–
Имя столбца xml типа данных в таблице.
[ DOCUMENT | CONTENT ]
· Аспект DOCUMENT сдерживает напечатанный образец xml типа данных, чтобы позволить только единственный элемент верхнего уровня.
· Аспект CONTENT явно позволяет напечатанному образцу xml типа данных иметь нуль или больше элементов верхнего уровня и текстовых узлов в элементах ве
schema
_
name
-
XML схема в XML коллекции схемы, чтобы связаться с столбцом xml типа данных
xml
_
schema
_
collection
_
name
-
Имя существующей XML коллекции схемы.
2.6.1.1.1.2 Переменные
Инструкция DECLARE используется, чтобы создать переменные T-SQL. Синтаксис чтобы создавать переменную xml типа данных:
DECLARE variable
_
name
[AS] xml [([DOCUMENT | CONTENT] schema_name.xml_schema_collection_name
)] Где: Variable
_
name
-
Имя переменной xml типа данных. Имя переменной должно быть предустановленно с амперсандом(@).
2.5.1.1.2 Методы
xml
Типа данных
Xml тип данных обеспечивает вспомогательные методы сделать запрос столбцов и переменных xml типа данных. Внутренне, методы xml типа данных обработаны как подзапросы. В результате, метод xml типа данных не может использоваться в инструкции PRINT или в предложении GROUP BY.
· query
(
)
Метод xml типа данных query() делает запрос образца xml типа данных и возвращает образец xml типа данных без контроля типов. query() синтаксис:
query (XQuery
)
Где:
XQuery
- Выражение XQuery, которое делает запрос для узлов XML в образце xml типа данных
· value
()
Метод value() xml типа данных исполняет запрос против образца xml типа данных и возвращает скалярное значение типа данных SQL. Синтаксис метода value(): value(XQuery
, SQLType
) Где:XQuery
-
Выражение XQuery, которое отыскивает данные от образца xml типа данных. Ошибка возвращена, если выражение не возвращает не менее одно значение.SQLType
-
Строка, буквальная из типа данных SQL, который будет возвращен. SQLType
не может быть xml, CLR UDT, image, text, ntext, или sql_variant тип данных.
value() метод использует функцию CONVERT T-SQL неявно, чтобы конвертировать результат выражения XQuery к типу данных SQL.
value() оператор требует единственного операнда
· exist()
метод exist () xml тип данных возвращает значение, указывающее, возвращает ли выражение XQuery против образца xml типа данных непустой набор результата. Возвращаемое значение - одно из следующего:
1 – Выражение XQuery возвращает не менее один XML узел.
0 – Выражение XQuery возвращает пустой набор результата.
NULL – Образец xml типа данных, против которого запрос выполнен, является НУЛЕВЫМ.
Синтаксис метода exist(): exist (XQuery
)
Где:
XQuery –
Выражение
XQuery
· modify( )
метод modify() xml тип данных метод изменяет содержание образца xml типа данных. Синтаксис метода modify(): modify (XML
_
DML
)
Где:
XML
_
DML
–
Инструкция Data Manipulation Language XML. Инструкции языка DML, inserts, updates, or deletes узлы из образца xml типа данных.
modify() метод может только использоваться в предложении SET инструкции UPDATE.
· nodes( )
метод nodes() xml типа данных () делит образец xml типа данных в относительные данные, идентифицируя узлы, которые будут отображены к новой строке.nodes() синтаксис:
nodes (XQuery
) as Table
(Column
)
Где:
XQuery
–
Выражение XQuery, которое создает узлы, которые впоследствии выставлены в результате набор
Table
–
Имя таблицы для набора результата
Column
-
Имя столбца для набора результата
2.6.1.1.3
Индексация
XML
Данных
xml типа данных сохранены как двойные большие объекты (большой двоичный объект) в столбцах xml типа данных. Если эти столбцы не индексированы, они должны быть shredded во время выполнения для каждой строки в таблице, чтобы оценить запрос. Это может быть дорогостоящим, особенно с большими образцами xml типа данных или большим количеством строк в таблице. Формирование первичных и вторичных индексов XML на столбцах xml типа данных может значительно улучшить выполнение запроса.
Столбец xml типа данных может иметь один первичный индекс XML и множественные вторичные индексы XML, где:
· Первичный индекс
XML
Относительный индекс на shredded и сохранился представление всех тэгов, значений, и путей XML образцов в столбце xml типа данных. Индекс создает несколько строк данных для каждого образца в столбце.
Первичный индекс XML требует сгруппированного индекса на первичной ключи таблицы, содержащей индексируемый xml тип данных.
· Вторичный индекс
XML
Далее улучшает выполнение для определенных типов запросов. Первичный индекс XML должен существовать на столбце xml типа данных прежде, чем вторичный индекс XML может быть создан.
Есть три типа вторичных индексов XML:
1. Индекс Path
Оптимизирует запросы, основанные на выражениях пути
2. Индекс Value
Оптимизирует запросы на основе значения для путей, которые включают подстановочные знаки или полностью не определены
3. Индекс Property
Оптимизирует запросы, основанные на свойствах в определенном XML образце, сохраненном в столбце
2.6.1.2 Поддержка
XQuery
в
SQL
server
2005
SQL Server 2005 имеет встроенную поддержку нативному хранению XML данных, используя XML тип данных. XQuery 1.0 - язык, который определяется Консорциумом Всемирной паутины (W3C) XML Группа Работы Запроса, чтобы формулировать запросы по XML данным. XQuery, подобно SQL, является декларативным языком запросов.
XQuery 1.0 осуществлен в SQL Server 2005, который в свою очередь основан на XQuery 1.0 июля 2004.
2.
6
.1.2.1 Структура
XQuery
выражения
Выражение XQuery в SQL Server 2005 состоит из двух разделов: Пролог и тело. Пролог может в свою очередь содержать namespace подраздел объявления. Namespace объявления используются, чтобы определить отображение между префиксом и namespace URI, таким образом дающими возможность Вам использовать префикс вместо namespace URI в теле запроса.
Тело выражения XQuery содержит выражения запроса, которые определяют результат запроса. Это может, например, быть сигнатура выражение FLWOR, XPath 2.0 выражения, или другое выражение XQuery типа конструкции или арифметического выражения.
2.6.1.2.2
XPath
2.0 Выражения
XQuery использует XPath 2.0 выражения, чтобы определить местонахождение узлов в документе и передвигаться от одного местоположения до другого в пределах отдельного документа или поперек документов. Навигационные определенные пути, используя XPath, состоят из последовательности шагов, отделенных /. Отдельный шаг включает ось, испытание узла, и нуль или больше спецификаторов шага.
Ось определяет направление движения, относительно контекстного узла. Поддержанные оси в SQL Server 2005 являются: child, descendant, parent, attribute, seft and descendant-or-seft.
2.
6
.1.2.3 Инструкция
FLWOR
Инструкции FLWOR формируют основные выражения XQuery и подобны инструкциям SELECT SQL. Акроним FLWOR (явный "цветок") замещает FOR,LET,WHERE, ORDER BY, RETURN. FLWOR выражения в XQuery дают возможность пользователям определить операции типа декларативной итерации,связывания переменной, фильтрации, сортировки, и возвращения результатов.SQL Server 2005 поддержек,FOR , WHERE, ORDER BY и RETURN.
2.
6
.1.2.4 Операторы в
XQuery
Как функциональный язык, XQuery в SQL Server 2005 поддержек различные типы функций и операторов, которые могут быть сгруппированы под следующими категориями:
· Арифметические операторы
· Операторы сравнения
· Логические операторы
· Конструкция условного оператора
Подобно другим функциональным языкам, XQuery поддерживает конструкцию условного оператора.
2.
6
.1.2.5 Встроенные Функции
XQuery
Выполнение XQuery в SQL Server 2005 поддержек подмножество встроенных функций XQuery 1.0 и XPath 2.0. Эти функции включают функции средства доступа данных, натягивают функции манипуляции, агрегатные функции, контекстные функции, числовые функции, функции Boolean, функции узла, и функции последовательности.
2.6.2. В
Oracle
2.6.2.1. Новый тип -
XMLType
.
Oracle следует за этим подходом и вводит новый тип объекта XMLType. Основная цель XMLType состоит в том, чтобы формировать CLOB хранение и обеспечивать XPath-основанные методы ослабить обработку XML документов. XMLType может использоваться подобно любому другому Oracle тип в таблицах. XMLType обеспечивает несколько методов для того, чтобы обработать XML документы:
· STATIC createXML(xml VARCHAR | CLOB)
· MEMBER getClobVal() RETURN CLOB
· MEMBER getStringVal() RETURN VARCHAR
· MEMBER getNumberVal() RETURN NUMBER
· MEMBER isFragment() RETURN NUMBER
Статический метод createXML берет XML строку или CLOB и создает объект XMLType, таким образом, проверяя отмеченность, но не законность относительно DTD или XML схемы. Методы getClobVal и getStringVal возвращают содержание XMLType в преобразованном в последовательную форму формате. getNumberVal уступает, НОМЕР оценивает, и требует, чтобы текст был числовым. Следовательно, getNumberVal не может быть применен к элементам формы <CNo> "10" </CNo>; текст функции XPath () должен использоваться заранее, чтобы извлечь числовое значение "10". Два дальнейших метода XMLType извлекают выгоду из XPath подмножества для запроса:
a.
MEMBER existsNode (VARCHAR xpath) RETURN NUMBER, прикладной по XMLType проверкам документа, если XPath определяет любые допустимые узлы.
b. MEMBER extract (VARCHAR xpath) RETURN XMLType фрагменты извлечений XMLType из XMLType документов, и возвращает их как объект XMLType.
2.6.2
Поддержка
XQuery
в
Oracle
Oracle XML DB поддержит языку XQuery обеспечен через нативое выполнение SQL/XML функций XMLQuery и XMLTable.
Oracle XML DB вообще оценивает выражения XQuery, компилируя их в те же самые глубинные структуры как относительные запросы. Запросы оптимизированы, усиливая и относительная база данных и XQuery-определенные технологии оптимизации, так, чтобы Oracle XML DB служил родным XQuery механизмом.
2.6.2.1 Функции SQL
XMLQuery
и
XMLTable
Функции SQL XMLQuery и XMLTable определены по SQL/XML стандарту как общий интерфейс между SQL и XQuery языками. Как имеет место для других функций SQL/XML, XMLQuery и XMLTable позволяют Вам использовать в своих интересах мощность и гибкость и SQL и XML. Используя эти функции, Вы можете создать XML данные, используя относительные данные, сделать запрос относительных данных, как будто это были XML, и создают относительные данные из XML данных.
2.6.2.2 Функции Расширения
Oracle
XQuery
Oracle XML DB добавляет некоторые функции XQuery к обеспеченным в W3C стандарте. Эти дополнительные функции находятся в Oracle XML DB namespace, http://xmlns.oracle.com/xdb, который использует предопределенные префиксные ora. Этот раздел описывает эти функции расширения Oracle.
2.6.2.3 Функция
XQuery
ora
:
contains
Функция XPath ora:contains может использоваться в выражении XPath выражения XQuery или в запросе к функции SQL existsNode, extract, или extractValue.
2.6.2.4 Функция
XQuery
ora
:
matches
Функция XQuery ora:match позволяет Вам использовать правильное выражение, чтобы соответствовать тексту в строке. Это возвращает true(), если ее target_string параметр соответствует ее параметру правильного выражения match_pattern и false () иначе. Если target_string - пустая последовательность, false () возвращена. Дополнительный параметр match_parameter - код, который квалифицирует соответствие: чувствительность к оператору выбора - и так далее.
2.6.2.5 Функция
XQuery
ora
:
replace
Функция XQuery ora:replace позволяет Вам использовать правильное выражение, чтобы заменить текст соответствия в строке.
2.6.2.6 Функция
XQuery
ora
:
sqrt
XQuery функция ora: sqrt возвращает квадратный корень ее числового параметра, который может иметь XQuery типа xs: decimal, xs: float, или xs: double. Возвращенное значение имеет тот же самый тип XQuery как параметр.
2.6.2.7 Функция
XQuery
ora
:
view
Функция XQuery ora:view позволяет Вам сделать запрос существующих таблиц базы данных или обозрений в выражении XQuery, как будто они были XML документами. В действительности, ora:view создает обозрения XML по относительным данным, на лету. Вы можете таким образом использовать ora:view, чтобы избежать явно, создавать обозрения XML относительно вершины относительных данных.
2.6.2.8 Поддержка Функциям и Операторам
XQuery
Oracle XML DB поддерживает все функции XQuery и операторы, включенные в последний XQuery 1.0 и XPath 2.0 Функции и спецификация Операторов, со следующими исключениями. Нет никакой поддержки следующему:
Функции XQuery правильного выражения. Используйте расширения Oracle для операций правильного выражения, вместо этого.
Неявные часовые пояса, когда используя функции, которые вовлекают продолжительности, даты, или времена.
Значения типа xs:IDREF или xs:IDREFS, в функциях строки, которые вовлекают узлы.
2.6.2.9
Функций
XQuery doc
и
collection
.
XQuery встроенные функции fn:doc и fn:collection по существу определены выполнением. Oracle XML DB поддерживает эти функции для всех ресурсов в Oracle XML DB Repository. Функция doc возвращает ресурс файла архива, который преследуется его параметром URI; это должен быть файл правильно построенных XML данных. Функция collection подобна, но работает на ресурсах папки архива (каждый файл в папке должен содержать правильно построенные XML данные). Каждая из этих функций возвращает пустую последовательность, если целенаправленный ресурс не найден - это не поднимает ошибку.
2.7. Другие методы для хранения
XML
в реляционных данных
2.7.1. Относительный подход DTD
2.7.1.1
Побуждение для специальных методов преобразования схемы
Относительные схемы были получены из модели данных типа модели Связи сущностей.
При преобразовании XML DTD к отношениям, это соблазняет, чтобы отобразить каждый элемент в DTD к восторгу и отобразить атрибуты элемента к атрибутам отношения.
Нет никакой соответствия между элементами и атрибутами DTD и объектов и атрибутов Модели ER
a. Основная
Inlining
методика
Основной решает проблему фрагментации inlining так много потомков элемента насколько возможно в отдельное отношение, основы создают отношения для каждого элемента, потому что XML документ может быть внедрен в любом элементе в DTD.
Два осложнения: оцененные набором атрибуты и рекурсия.
Граф DTD - граф представляет структуру DTD. Его узлы - элементы, атрибуты, и операторы в DTD.
Учитывая граф элемента, отношения созданы следующим образом. Отношение создано для корневого элемента графа. Потомки всего элемента - inlined в то отношение со следующими двумя исключениями:
a. дочерние записи непосредственно ниже "*" узел сделан в отдельные отношения - это соответствует созданию нового отношения для набора - оцененного ребенка.
b. каждый узел, имеющий backpointer край, указывающий на это, сделан в отдельное отношение - это соответствует созданию нового отношения, чтобы обработать рекурсию.
Атрибуты в отношениях называет путь от корневого элемента отношения.
Каждое отношение имеет поле идентификатора, что серверы как ключ того отношения.
Все отношение, соответствующее узлам элемента, имеющего родителя также имеет parentID поле, которые служат внешним ключом.
b. Share
Inlining Методика.
Основная идея позади Shared должна идентифицировать узлы элемента, которые представлены во множественных отношениях в Основном и совместно использовающему их, создавая отдельные отношения для этих элементов.
В общедоступном отношения, созданы для всех элементов в графе DTD, узел которого имеет В-степени что один.
Узлы элемента, имеющие В-степени из нуля также, сделаны отдельными отношениями, потому что они не доступны от любого другого узла.
Как в Основном, элементы bellows "*" узел сделан в отдельные отношения.
Наконец, взаимно рекурсивных элементов весь имеющий В-степени, один из них сделал отдельное отношение.
c. Hibrid
Inlining
Методика
Hibrid в том же самом как разделено за исключением того, что второй inlines некоторые элементы - не inlined в Shared.
Hibrid дополнительно inlines элементы со в-степени больше, что тот, которые не рекурсивны или достигнуты через "*" узел.
Подэлементы набора и рекурсивные элементы обработаны как в Shared.
2.7.1.2 DTD Xmark
<!ELEMENT site (regions, categories, catgraph, people, open_auctions,
closed_auctions)>
<!ELEMENT categories (category+)>
<!ELEMENT category (name, description)>
<!ATTLIST category id ID #REQUIRED>
<!ELEMENT name (#PCDATA)>
<!ELEMENT description (text | parlist)>
<!ELEMENT text (#PCDATA | bold | keyword | emph)*>
<!ELEMENT bold (#PCDATA | bold | keyword | emph)*>
<!ELEMENT keyword (#PCDATA | bold | keyword | emph)*>
<!ELEMENT emph (#PCDATA | bold | keyword | emph)*>
<!ELEMENT parlist (listitem)*>
<!ELEMENT listitem (text | parlist)*>
<!ELEMENT catgraph (edge*)>
<!ELEMENT edge EMPTY>
<!ATTLIST edge from IDREF #REQUIRED to IDREF #REQUIRED>
<!ELEMENT regions (africa, asia, australia, europe, namerica, samerica)>
<!ELEMENT africa (item*)>
<!ELEMENT asia (item*)>
<!ELEMENT australia (item*)>
<!ELEMENT namerica (item*)>
<!ELEMENT samerica (item*)>
<!ELEMENT europe (item*)>
<!ELEMENT item (location, quantity, name, payment,
description, shipping, incategory+, mailbox)>
<!ATTLIST item id ID #REQUIRED
featured CDATA #IMPLIED>
<!ELEMENT location (#PCDATA)>
<!ELEMENT quantity (#PCDATA)>
<!ELEMENT payment (#PCDATA)>
<!ELEMENT shipping (#PCDATA)>
<!ELEMENT reserve (#PCDATA)>
<!ELEMENT incategory EMPTY>
<!ATTLIST incategory category IDREF #REQUIRED>
<!ELEMENT mailbox (mail*)>
<!ELEMENT mail (from, to, date, text)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT date (#PCDATA)>
<!ELEMENT itemref EMPTY>
<!ATTLIST itemref item IDREF #REQUIRED>
<!ELEMENT personref EMPTY>
<!ATTLIST personref person IDREF #REQUIRED>
<!ELEMENT people (person*)>
<!ELEMENT person (name, emailaddress, phone?, address?,
homepage?, creditcard?, profile?, watches?)>
<!ATTLIST person id ID #REQUIRED>
<!ELEMENT emailaddress (#PCDATA)>
<!ELEMENT phone (#PCDATA)>
<!ELEMENT address (street, city, country, province?, zipcode)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT province (#PCDATA)>
<!ELEMENT zipcode (#PCDATA)>
<!ELEMENT country (#PCDATA)>
<!ELEMENT homepage (#PCDATA)>
<!ELEMENT creditcard (#PCDATA)>
<!ELEMENT profile (interest*, education?, gender?, business, age?)>
<!ATTLIST profile income CDATA #IMPLIED>
<!ELEMENT interest EMPTY>
<!ATTLIST interest category IDREF #REQUIRED>
<!ELEMENT education (#PCDATA)>
<!ELEMENT income (#PCDATA)>
<!ELEMENT gender (#PCDATA)>
<!ELEMENT business (#PCDATA)>
<!ELEMENT age (#PCDATA)>
<!ELEMENT watches (watch*)>
<!ELEMENT watch EMPTY>
<!ATTLIST watch open_auction IDREF #REQUIRED>
<!ELEMENT open_auctions (open_auction*)>
<!ELEMENT open_auction (initial, reserve?, bidder*, current,
privacy?, itemref, seller, annotation, quantity, type, interval)>
<!ATTLIST open_auction id ID #REQUIRED>
<!ELEMENT privacy (#PCDATA)>
<!ELEMENT initial (#PCDATA)>
<!ELEMENT bidder (date, time, personref, increase)>
<!ELEMENT seller EMPTY>
<!ATTLIST seller person IDREF #REQUIRED>
<!ELEMENT current (#PCDATA)>
<!ELEMENT increase (#PCDATA)>
<!ELEMENT type (#PCDATA)>
<!ELEMENT interval (start, end)>
<!ELEMENT start (#PCDATA)>
<!ELEMENT end (#PCDATA)>
<!ELEMENT time (#PCDATA)>
<!ELEMENT status (#PCDATA)>
<!ELEMENT amount (#PCDATA)>
<!ELEMENT closed_auctions (closed_auction*)>
<!ELEMENT closed_auction (seller, buyer, itemref, price, date,
quantity, type, annotation?)>
<!ELEMENT buyer EMPTY>
<!ATTLIST buyer person IDREF #REQUIRED>
<!ELEMENT price (#PCDATA)>
<!ELEMENT annotation (author, description?, happiness)>
<!ELEMENT author EMPTY>
<!ATTLIST author person IDREF #REQUIRED>
<!ELEMENT happiness (#PCDATA)>
2.7.1.3 Часть графа
DTD
XMark
- в
People
узла
DTD
в
People
узла
<!ELEMENT people (person*)>
<!ELEMENT person (name, emailaddress, phone?, address?,
homepage?, creditcard?, profile?, watches?)>
<!ATTLIST person id ID #REQUIRED>
<!ELEMENT emailaddress (#PCDATA)>
<!ELEMENT phone (#PCDATA)>
<!ELEMENT address (street, city, country, province?, zipcode)>
<!ELEMENT street (#PCDATA)>
<!ELEMENT city (#PCDATA)>
<!ELEMENT province (#PCDATA)>
<!ELEMENT zipcode (#PCDATA)>
<!ELEMENT country (#PCDATA)>
<!ELEMENT homepage (#PCDATA)>
<!ELEMENT creditcard (#PCDATA)>
<!ELEMENT profile (interest*, education?, gender?, business, age?)>
<!ATTLIST profile income CDATA #IMPLIED>
<!ELEMENT interest EMPTY>
<!ATTLIST interest category IDREF #REQUIRED>
<!ELEMENT education (#PCDATA)>
<!ELEMENT income (#PCDATA)>
<!ELEMENT gender (#PCDATA)>
<!ELEMENT business (#PCDATA)>
<!ELEMENT age (#PCDATA)>
<!ELEMENT watches (watch*)>
<!ELEMENT watch EMPTY>
<!ATTLIST watch open_auction IDREF #REQUIRED>
2.7.1.4 Отношение
Shema
от графа
DTD
a.
The Basic Inlining Technique
People(peopleID:integer,people.person.id:String,people.person.name:String,people.person.emailaddress:String,people.person.phone:String,people.person.address.street:String, people.person.address.city:String, people.person.address.country:String, people.person.address.province:String, people.person.address.zipcode:String,people.person.homepage:String,people.person.creditcard:String, people.person.profile.interest.category:String, people.person.profile.business:String, people.person.profile.education:String, people.person.profile.gender:String, people.person.profile.income:String, people.person.profile.age:String,people.person.wathes.wath.open-auction:String)
Person(personID:integer,person.id:String,person.name:String,person.emailaddress:String,person.phone:String,person.address.street:String,person.address.city:String,person.address.country:String,person.address.province:String,person.address.zipcode:String,person.homepage:String,person.creditcard:String,person.profile.interest.category:String,person.profile.business:String, person.profile.education:String, person.profile.gender:String, person.profile.income:String, person.profile.age:String, person.wathes.wath.open-auction:String)
Name (nameID: Integer, name: String)
Emailaddress (emailaddressID: Integer, emailaddress: String)
Phone (phoneID: Integer, phone: String)
Address(addressID:Integer,address.street:String, address.city:String,address.country:String,address.province:String,address.zipcode:String)
Street(streetID:Integer,street:String)
City(CityID:Integer,city:String)
Country(countryID:Integer,country:String)
Province(provinceID:Integer,province:String)
Zipcode(zipcodeID:Integer,zipcode:String)
Homepage(homepageID:Integer,homepage:String)
Creditcard(creditcardID:Integer,creditcard:String)
Profile(profileID:Integer,profile.interest.category:String,profile.business:String,profile.education:String,profile.income:String,profile.gender:String,profile.age:String)
Interest (interestID: Integer, interest.category: String)
Category(categoryID:Integer,category:String)
Business(businessID:Integer,business:String)
Education(educationID:Integer,education:String)
Gender(genderID:Integer,gender:String)
Age(ageID:Integer,age:String)
Watches(watchesID:Integer,watch.open-auction:String)
Watch(watchID:Integer,watch:String)
b.
The Shared Inlining Technique
People.person(people.personID:integer,
people.person.name.isroot:Boolean,people.person.name:String,
people.person.emailaddress.isroot:Boolean,people.person.emailaddress:String, people.person.phone.isroot:Boolean,people.person.phone:String, people.person.homepage.isroot:Boolean,people.person.homepage:String, people.person.creditcard.isroot:Boolean,people.person.creditcard:String,)
Address(addressID:Integer,address.parentID:Integer,address.street.isroot:Boolean,address.street:String,address.city.isroot:Boolean,address.city:String,address.country.isroot:Boolean,address.country:String,address.province.isroot:Boolean,address.province:String,address.zipcode.isroot:Boolean,address.zipcode:String)
Profile(profileID:Integer,profile.parentID:Integer,profile.interest.isroot:Boolean,profile.interest.category:String,profile.education.isroot:Boolean,profile.education:String,profile.business.isroot:Boolean,profile.business:String,profile.gender.isroot:Boolean,profile.gender:String,profile.age.isroot:Boolean,profile.age:String,profile.income:String)
Interest(interestID:Integer,interest.parentID:Integer,interest.category:String)
Watches(watchesID:Integer,watches.parentID:Integer,watches.watch.isroot:Boolean,watches.watch.open-auction:String)
Watch(watchID:integer,watch.parentID:Integer,watch.open-auction:String)
Отношение Shema Hibird Inlining Методика в этом случаи подобно отношению Shema Shared Inlining Методики.
2.
7
.2. Подход атрибутов
2.
7
.2.1 Подход
Edge
таблицы.
Наиболее простой хранить все атрибуты в единственной таблице: позвольте нам называть эту таблицу таблицей Edge. Таблица Edge делает запись oid источника и объектов маленького круглого щита атрибута, имя атрибута, флажок, который указывает, является ли атрибут меж-объектной ссылкой или poit к значению, и порядковое число имело обыкновение возвращать весь атрибуты объекта в праве и выполнять модификации, если объекты имеют несколько атрибутов с тем же самым именем.
Таблица Edge имеет следующую структуру:
Edge(sourceID, tag, ordinal, targeteID, Data )
Ключ таблицы Edge {sourceID, ordinal}.Простой вариант подхода Edge должен хранить имена атрибута в отдельной таблице.
2.
7
.2.2 Подход Атрибута
В этом методе, всеми атрибутами с тем же самым именем была группа в одну таблицу. Этот подход соответствует горизонтальному разделению таблицы Edge, используемой в первом подходе, использование имени как атрибут разделения. Таким образом, там мы создаем так много таблиц атрибутов, имеет структуру:
A-имя (source, ordinal, flag, target )
Ключ такой таблицы атрибута - {source, ordinal}, и все поля имеет то же самое значение как в подходе Edge
3.Эксперименты/ результаты
Эксперимент проводился на Windows XP машина; RAM на 512 МБ 40Gb Жесткий диск. Программное обеспечение: Oracle 10g и SQL Server 2005 используются. База данных от XMark и вопросов, случайных от 20 вопросов XMark, и я дала некоторые вопросы для сравнения разных методов.
3.1 Сравнение разных методов
3.1.1 Время погрузки данных
|
|
SQL Server (s)
|
Oracle (s)
|
| Тип
|
197
|
87s
|
| XQuery
|
200
|
100
|
| DTD
|
518400
|
--
|
| Edge
|
43200
|
--
|
Видим в таблицу, мы получим: Два метод DTD подход и Edge подход, в которых надо выбрать данные из XML данных и потом вставить в таблицу, поэтому время погрузки данных медленнее, чем много раз подходов Тип XML данных и XQuery, которые только вставить в одну строку таблицы. В DTD подход, поскольку в каждый тэг надо создать соответствующую таблицу и в Edge подход все данные только создать одну таблицу, поэтому время погрузки данных быстрее чем, DTD подхода.
В Oracle, время чтобы загрузить данных в таблицы надо много времени, поэтому я не проводила эксперимент DTD поход и Edge подход в Oracle.
3.1.2 Память хранения данных из 110
Mb
XML
данных
|
|
SQL Server (Mb)
|
Oracle (Mb)
|
| Тип
|
172.2
|
140
|
| XQuery
|
17
|
140
|
| DTD
|
230
|
--
|
| Edge
|
210
|
--
|
Из таблицы, мы видим так, в DTD подходе и Edge подходе мы храним данные в таблицы с много строк, которые нужны дополненная память для индекса. В тип XML данных и XQuery подходах только хранятся в одну строку, поэтому память хранения данных DTD и Edge подходов много чем, тип XML данных и XQuery.
3.1.3 Время выполнения запросов
В этом эксперименте, я сделала DTD и Edge подходы только в узел person поэтому запросы я не использовала запросы из XMark, а я сама думала запросы. И запросы такие:
Q
1
: Выбрать люди, которые имеют
ordinal
равно 100
Q
2
: Выбрать люди, которые не имеют
homepage
Q
3
: Найти все люди.
Q
4
: Найти имя, адрес всех людей, которые имеют
zipcode
равно 22
Q
5:
Выбрать имя,
age
, пол,
income
людей, которые имеют
open
_
auction
равно 6634
Q
6:
Найти сумм всех людей, у которых есть
income
> =100
Q
7:
Выбрать имя, улицы, город, страна людей, у которых имеют
education
=”
College
”
Q
8:
Найти людей, у которых есть телефон и пол «
female
»
Q
9:
Найти сумм всех женских
Q
10
: Выбрать имя, пол,
education
людей, у которых есть
creditcard
Время выполнения:
| Query |
SQL Server |
Oracle |
||||
| Тип XML |
XQuery |
DTD |
Edge |
Тип XML |
XQuery |
|
| Q1 |
23 |
20 |
2 |
2 |
1543 |
2956 |
| Q2 |
12 |
19 |
1 |
1 |
1666 |
7873 |
| Q3 |
20 |
30 |
3 |
3 |
2416 |
6265 |
| Q4 |
2500 |
35 |
1 |
3 |
1308 |
8157 |
| Q5 |
15 |
20 |
2 |
8 |
7065 |
7515 |
| Q6 |
2550 |
65 |
0.5 |
6 |
2325 |
8115 |
| Q7 |
2200 |
44 |
1 |
7 |
2453 |
6315 |
| Q8 |
2600 |
70 |
1 |
2 |
2154 |
7265 |
| Q9 |
1000 |
28 |
4 |
15 |
3421 |
5437 |
| Q10 |
200 |
22 |
2 |
10 |
4325 |
7125 |
Из результатов, мы видим что:
Когда выполнены запросы, время выполнено в DTD подход и в Edge подход меньше чем в тип XML и в XQuery. Поскольку в DTD и Edge подходы, когда данные в таблицах, тогда в СУБД имеет поддержка очень хорошо для реляционных баз. А для типа XML и XQuery – Это новые возможности, которые применены в СУБД, поэтому их поддержка может не лучше чем, реляционных баз.
Edge подход – это самый простой метод хранения XML в реляционных базах. Но при выполнении запросов, нам надо дать сложнее запросы чем, в DTD подходе. И время выполнения запросов тоже более чем, в DTD подходе. Например: В запросе Q7, если мы хотим найти имя, улицы, город, страна людей, у которых имеют education =”College”. Начала нам надо найти ‘source’ в Edge таблице имеет ‘target’ = “College”,потом мы найдем ‘target’ соотношение ‘source’, который мы нашли. Если значение ‘target’ является порядковым (ordinal), тогда мы повторяем, когда target не является порядковым. Но в DTD подходе, мы только делаем ссылку двух таблиц- People_person и Profile. Поэтому время выполнения запросов DTD похода меньше чем, Edge подхода.
И в SQL Server в тип XML, который применит Xpath 1.0, а XQuery, который применит Xpath 2.0, поэтому время выполнения запросов в XQuery меньше чем, в тип XML. Кроме этого, когда мы дадим запросы в XQuery проще, чем в тип XML. Но в Oracle не так, время выполнения запросов тип XML подход меньше чем, времени выполнения запросов XQuery подход. В Oracle 10.0.2g, XQuery поддержит ‘let’ выражение, а в SQL Server 2005 XQuery не поддержит ‘let’ выражение.
Итог: Как мы видим, время погрузки данных DTD и Edge подходов меньше чем много раз (более чем 2000 раз) типа XML и XQuery подходов, но время выполнения запросов у них меньше чем, типа XML и XQuery. Если XML данных имеет элемент далеко от корня более 3 степени, тогда мы лучше используем DTD подход, но если меньше 2 степени, тогда мы лучше используем Edge подход.
3.2 Сравнение хранения
XML
в разных системах:
SQL
Server
и
Oracle
с 110 Mb XML дата (время s).
| 110 Mb |
11Mb |
|||
| Oracle |
SQL Server |
Oracle |
SQL Server |
|
| Q1 |
2107 |
8 |
300 |
2 |
| Q2 |
2018 |
14 |
250 |
3 |
| Q3 |
2201 |
2500 |
312 |
360 |
| Q5 |
1767 |
25 |
180 |
4 |
| Q6 |
3124 |
5 |
400 |
1 |
| Q7 |
10992 |
126 |
1200 |
17 |
| Q8 |
1713 |
2500 |
175 |
370 |
| Q11 |
1636 |
2000 |
150 |
290 |
| Q13 |
4395 |
20 |
437 |
6 |
| Q17 |
1666 |
500 |
156 |
15 |
В таблице результата мы видим так, для запросов выбора из данных, время запроса в SQL Server меньше чем в Oracle много раз. В SQL Server, для запросов конкретного значения, время выполнения меньше чем в Oracle много раз. Например, запросы Q1,Q2,Q7,Q5,Q13,Q17.Однако, если запросы имеют сравнения значения между тэгами, время выполнения запросов прямо пропорциональны количеству тэгов, поэтому в SQL Server время выполнения запросов больше чем в Oracle. Например, запросы Q3,Q8,Q11.Мы получим это результат потому-то:
- В
Oracle
: хранение XML документов в CLOB XMLTypes приводит к дорогой избыточной обработке при запросе XML конвента такими функциями, как XMLType.Extract() или XMLType.ExistsNode(), поскольку эти операции требуют во время обработки построения в оперативной памяти дерева XML DOM и выполнения функциональных Xpath оценок.
Поэтому, как правило, следует избегать использования XMLType функций при выполнении незначительных XML обновлений или запросов с задействованием Xpath при действиях с CLOB XMLTypes.
- В
SQL
Server
:
Методы типа данных XML поддерживают XQuery, который является стандартом языка W3C и включает язык навигации XPath 2.0.
Команда SQL обрабатывается анализатором SQL. Когда он обнаруживает выражение XQuery, управление передается компилятору XQuery, который затем компилирует выражение XQuery. Это порождает дерево запросов.
Общее дерево запросов выполняет оптимизацию запросов и строит физический план запросов, основанный на оценке затрат
4.Заключение
Из результатов раздела Эксперимента:
- Если мы только храним данных и выполним простые запросы, тогда мы можем использовать тип XML и XQuery подходы, потому что память хранения данных из одного файла этих подходов меньше чем, DTD и Edge подходов, но время выполнения не очень различные.
- Если мы делаем с много запросов и сложные запросы, мы можем использовать DTD или Edge подход, поскольку время выполнения запросов DTD и Edge подходов меньше чем более 10 раз, XQuery подхода и меньше чем 1000 раз тип XML подхода, например: запросы Q4, Q6, Q7, Q8, Q9 в разделе 3.1.3. Хотя время загрузки данных этих подходов более чем много раз двух остальных подходов, но если мы загрузим данные, когда мы начала создать XML данных, тогда проблема времени загрузки данных не важно.
- Если мы делаем с данных, у которых есть элемент далеко от корня более 3 элемента, мы лучше используем DTD подход. Поскольку из результатов раздела 3.1.3 мы видим что, когда запросы с элементами, которые имеют позиции далеко от корня более 3 степени, то время выполнения запросов Edge подхода больше чем , DTD подхода. Например: Из раздела 3.1.3, вопросы Q5, Q6, Q7, Q9,Q10, которые выполнены запросами с имеющими более 3 степени от корня элементами, тогда время выполнения запросов DTD подхода больше чем, времени выполнения запросов Edge подхода.
- Когда я делала с Oracle и SQL Server, я видела так: для подхода тип XML данных, время выполнения конкретных запросов в SQL Server меньше чем в Oracle. Например: из результатов раздела 3.2, запросы Q1, Q2, Q5,Q6,Q7,Q13,Q17, которые выполнены с конкретных значений, тогда время выполнения запросов в SQL Server меньше чем много раз в Oracle. Но если мы делали с запросами, у которых есть сравнение значения между элементами, то время выполнения запросов в Oracle меньше чем в SQL Server. Например: запросы Q3,Q8,Q11 из раздела 3.2, время выполнения запросов в Oracle меньше чем в SQL Server.
- В этом дипломе, я только смотрела некоторые методы хранения XML данных в реляционных базах и в системах только в Oracle и в SQL Server. Поэтому я буду развивать диплом так: Буду смотреть ещё не которые методы, особенно применяющие xml схемы (xsd) методы, которые близки похоже методы DTD, но время меньше чем. Кроме этого, смотреть ещё в других системах (DB2…). Для DTD подход и Edge подход, я не смотрела в Oracle, потому что время загрузки данных из XML в реляционных базах в этой системе очень долго и у меня не достаточно время, поэтому развития этого диплома может ещё рассмотреть в Oracle для DTD и Edge подходов. А размер данных, я только смотрела 110Mb и 10Mb, развития этого направления будет так: рассмотрим разные размеры и одинаковые размеры, но различные количества элементов (узлов).
- И последний, я хочу благодарить профессору Б.А.Новикову, который поможет мной много в процессе выполнения диплома. Он руководил мной самоотверженно и проверил ошибки в дипломе, и я знаю, что руководил иностранным студентом труднее, чем русским студентом. И мне тоже спасибо всем преподавателям математико-механического факультета Санкт-петербургского Государственного Университета, которые учили меня и помогли мне много, когда я училась в России.
Список
литературы
[1] Extensible Markup Language
http://www.w3c.org/XML/Overview.html
[2] Хабибуллин И. Ш. - Самоучитель XML.
СПб.: БХВ - Петербург, 2003.- 336с.
[3] K.Williams, M. Brundage, P. Dengler, J. Gabriel, A. Hoskinson, M. Kay, Th. Maxwell, M. Ochoa, J. Papa, M. Vanmane.
Professional XML Databases
Wrox Press Ltd.
[4] A.B. Chaudhri, A. Rashid, R. Zicari.
XML Data Management – Native XML and XML-Enabled Database Systems
[5] XQuery 1.0: An XML Query Language
http://www.w3c.org/TR/xquery.
[6] Michael Brundage.
XQuery: The XML Query Language.
Publisher: Addison Wesley. ISBN: 0-321-16581-0. Pages: 544.
[7] A. Schimidt, F. Waas, M. Kersten, M. J. Carey, I. Manolesco, R. Busse.
XMark : A Benchmark for XML Data Management.
Proceedings of the 28th
VLDB Conference, Hong Kong, China, 2002.
[8] XMark – The XML benchmark project.
http://monetdb.cwi.n/xml/index.html.
[9] Shankar Pal, Mark Fussell, and Irwin Dolobowsky - Microsoft Corporation.
XML Support in Microsoft SQL Server 2005.
http://msdn2.microsoft.com/en-us/library/ms345117.aspx
[10] Bill Hamilton.
Programming SQL Server 2005.
Publisher: O’Reilly. Print ISBN-10: 0-596-00479-6.
Print ISBN-13: 978-0-59-600479-8.Pages:586.
[11] Using
XQuery with Oracle XML DB
Oracle® XML DB Developer's Guide 10g
Release 2 (10.2), Part Number B14259-02
[12] Using Oracle XML DB.
Oracle® XML DB Developer's Guide 10g
Release 1 (10.1), Part Number B10790-01
[13] Марк Скандина, Бен Чанг, Джайню Ванг
Хранение XML данных (Storing XML Data)
Глава 9 из книги "Oracle Database 10g XML & SQL: Design, Build, & Manage XML Applications in Java, C, C++, & PL/SQL" by Mark Scardina
, Ben Chang
, Jinyu Wang
, изд. Osborne, ISBN: 0072229527, 2004, 600 стр.
[14] Daniela Florescu, Donald Kossmann
A Performance Evaluation of Alternative Mapping Schemes for Storing XML Data in a Relational Database
Rapport de Recherche No. 3680 INRIA, Rocquencourt, France, May 1999.
[15] Jayavel Shanmugasundaram, Kristin Tufte, Gang He, Chun Zhang, David DeWitt, Jeffrey Naughton.
Relational Databases for Querying XML Documents : Limitations and Opportunities.
Proceedings of the 25th
VLDB Conference, Edinburgh, Scotland, 1999.
[16] Feng Tian, David J.DeWitt, Jianjun Chen, Chun Zhang.
The Design and Performance Evauation of Alternative XML Storage Strategies.
[17] Daniela Florescu, Donald Kossmann.
Storing and Querying XML Data using an RDMBS.
Bulletin of the IEEE Computer Society Technical Committee on Data Engineering.