Соответствие стандарту SQL

• Поддерживаемые возможности
• Неподдерживаемые возможности
• Ограничения XML и соответствие SQL/XML
  • Запросы ограничены XPath 1.0
    • Ограничение языка XQuery относительно XPath
    • Ограничение XPath до версии 1.0
  • Сопоставления типов данных и значений между SQL и XML
  • Непреднамеренные ограничения реализации
    • Поддерживается только механизм передачи параметров по значению (BY VALUE)
    • Невозможно передать в запросы именованные параметры
    • Отсутствие типа XML(SEQUENCE)

В этом разделе в общих чертах описывается, в какой степени QHB соответствует текущему стандарту SQL. Следующая информация не является полноценной декларацией соответствия, но при этом представляет основные темы достаточно подробно, чтобы быть полезной и целесообразной для пользователей.

Официально стандарт SQL называется ISO/IEC 9075 «Database Language SQL» (Язык баз данных SQL). Время от времени выпускается обновленная версия стандарта; последнее обновление было сделано в 2016 году. Эта версия стандарта получила название ISO/IEC 9075:2016, или просто SQL:2016. Ранее были выпущены версии SQL:2011, SQL:2008, SQL:2006, SQL:2003, SQL:1999 и SQL-92. Каждая версия заменяет предыдущую, поэтому заявления о соответствии более ранним версиям не имеют официальной ценности. Разработка QHB нацелена на соответствие последней официальной версии стандарта, если оно не противоречит традиционному функционалу или здравому смыслу. Поддерживается большая часть функционала, требуемого стандартом SQL, хотя иногда с немного отличающимся синтаксисом или функциями. Можно ожидать, что со временем степень соответствия стандарту будет постепенно возрастать.

SQL-92 определил три уровня функционального соответствия стандарту: начальный (Entry), промежуточный (Intermediate) и полный (Full). Большинство СУБД, заявлявших о соответствии стандарту SQL, соответствовали ему только на начальном уровне, поскольку общий набор функций на промежуточном и полном уровнях либо был слишком обширным, либо конфликтовал с устаревшими моделями поведения.

Начиная с SQL:1999, вместо трех малоприменимых пространных уровней, вычлененных в SQL-92, в стандарте SQL определено множество отдельных функциональных возможностей. Большое его подмножество представляет собой «Основной» функционал, который должны обеспечивать все реализации, совместимые с SQL. Поддержка остальных возможностей не являются обязательной. Некоторые дополнительные возможности сгруппированы вместе, формируя «пакеты», о поддержке которых могут заявлять реализации SQL, тем самым декларируя соответствие определенным группам возможностей.

Версии стандарта, начиная с SQL:2003, также разбиты на несколько частей. Каждая часть имеет краткое название. Обратите внимание, что нумерация этих частей непоследовательная.

• ISO/IEC 9075-1 Структура (SQL/Framework)

• ISO/IEC 9075-2 Основа (SQL/Foundation)

• ISO/IEC 9075-3 Интерфейс уровня вызовов (SQL/CLI)

• ISO/IEC 9075-4 Модули постоянного хранения (SQL/PSM)

• ISO/IEC 9075-9 Управление внешними данными (SQL/MED)

• ISO/IEC 9075-10 Привязки объектных языков (SQL/OLB)

• ISO/IEC 9075-11 Схемы информации и определений (SQL/Schemata)

• ISO/IEC 9075-13 Программы и типы, использующие язык Java (SQL/JRT)

• ISO/IEC 9075-14 Спецификации, связанные с XML (SQL/XML)

Ядро QHB реализует части 1, 2, 9, 11 и 14. Часть 3 реализуется драйвером ODBC, а часть 13 — плагином PL/Java, но точное соответствие этих компонентов стандарту на данный момент не проверено. Части 4 и 10 в QHB в настоящее время не реализованы.

QHB поддерживает почти весь основной функционал SQL:2016. Из 179 обязательных возможностей, необходимых для полного соответствия «Основному» функционалу, QHB обеспечивает соответствие как минимум для 160. Кроме того, он поддерживает длинный список дополнительных возможностей. Следует отметить, что на момент написания этой документации ни одна из существующих версий СУБД не претендовала на полное соответствие «Основному» функционалу SQL:2016.

В следующих двух разделах мы предоставляем список функциональных возможностей, которые поддерживает QHB, а также список возможностей, определенных в SQL:2016, которые в QHB еще не поддерживаются. Оба списка носят приблизительный характер: возможность, указанная как поддерживаемая, может отличаться от стандарта в незначительных деталях, а неподдерживаемая возможность на самом деле может быть по большей части реализована. Наиболее точная информация о том, что работает, а что нет, содержится в основной документации.

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

Поддерживаемые возможности

Неподдерживаемые возможности

Следующие возможности, определенные в SQL:2016, не реализованы в этом выпуске QHB. В некоторых случаях доступна равнозначная им функциональность.

Ограничения XML и соответствие SQL/XML

В SQL:2006 в спецификации ISO/IEC 9075-14 (SQL/XML), посвященные XML, были внесены существенные изменения. Реализация типа данных XML и связанных с ним функций в QHB во большей степени соответствует более ранней редакции от 2003 года, с некоторыми заимствованиями из последующих редакций. В частности:

• Тогда как в текущем стандарте предусмотрено семейство типов данных XML, содержащих «документы» или «содержимое» в нетипизированных вариантах или вариантах с типами XML Schema, а также тип XML(SEQUENCE), содержащий произвольные фрагменты содержимого XML, в QHB есть только один тип xml, который может содержать «документ» или «содержимое». Эквивалента определенному в стандарте типу «последовательность» в QHB не существует.

• QHB предоставляет две функции, появившиеся в SQL:2006, но вместо языка XML Query, указанного для них в стандарте, в этих вариантах используется язык XPath 1.0.

В этом разделе описаны некоторые проистекающие из этого различия, с которыми вы можете столкнуться.

Запросы ограничены XPath 1.0

Специфичные для QHB функции xpath() и xpath_exists() выполняют запросы к документам XML на языке XPath. QHB также предоставляет стандартные функции XMLEXISTS и XMLTABLE, поддерживающие только XPath, хотя официально они должны поддерживать язык XQuery. Для всех этих функций QHB использует библиотеку libxml2, которая поддерживает только XPath 1.0.

Существует тесная связь между языком XQuery и XPath версии 2.0 и новее: любое выражение, которое синтаксически допустимо и успешно выполняется, выдает в обоих языках одинаковый результат (с небольшим исключением для выражений, содержащих ссылки на числовые символы или предварительно определенные сущности, которые XQuery заменяет соответствующими символами, а XPath оставляет в исходном виде). Но между этими языками и XPath 1.0 такой связи нет; он появился раньше и во многих отношениях отличается от них.

Следует иметь в виду две категории ограничений: ограничение языка XQuery до XPath для функций, указанных в стандарте SQL, и ограничение XPath до версии 1.0 как для стандартных, так и для специфичных функций QHB.

Ограничение языка XQuery относительно XPath

В число возможностей XQuery, отсутствующих у XPath, входят:

• Выражения XQuery могут не только возвращать все возможные значения XPath, но и конструировать новые узлы XML. XPath может создавать и возвращать значения атомарных типов (числа, строки и т. д.), но возвращать способен только те узлы XML, которые уже присутствовали в документах, поступивших на вход выражения.

• В XQuery есть управляющие конструкции для итерации, сортировки и группировки.

• XQuery позволяет объявлять и использовать локальные функции.

В последних версиях XPath начинают появляться возможности, пересекающиеся с возможностями XQuery (например, функциональные конструкции for-each и *sort, анонимные функции и функция parse-xml, создающая узел из строки), но до XPath 3.0 они были недоступны.

Ограничение XPath до версии 1.0

Разработчикам, знакомым с XQuery и XPath 2.0 или новее, приходится сталкиваться с рядом отличий XPath 1.0:

• Фундаментальный тип выражения XQuery/XPath, тип sequence, который может содержать узлы XML, атомарные значения или и то, и другое, в XPath 1.0 отсутствует. В 1.0 выражение может создавать только множество узлов (содержащих ноль или более узлов XML) или одно атомарное значение.

• В отличие от последовательности XQuery/XPath, которая может содержать любые требуемые элементы в любом желаемом порядке, во множестве узлов XPath 1.0 нет гарантированного порядка и оно, как и любое множество, не допускает несколько появлений одного и того же элемента.

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

• Тогда как XQuery/XPath предоставляет все типы, определенные в стандарте XML Schema, а также множество операторов и функций для этих типов, XPath 1.0 поддерживает только множества узлов и три атомарных типа: boolean, double и string.

• В XPath 1.0 отсутствует условный оператор. Выражение XQuery/XPath вида if ( hat ) then hat/@size else "no hat" не имеет эквивалента в XPath 1.0.

• В XPath 1.0 отсутствует оператор сравнения строк с упорядочиванием. Условия "cat" < "dog" и "cat" > "dog" оба являются ложными, поскольку представляют собой числовые сравнения двух значений NaN. Условия же = и !=, напротив, сравнивают строки в виде строк.

• XPath 1.0 размывает разницу между сравнениями значений и общими сравнениями, как они определены в XQuery/XPath. Сравнения sale/@hatsize = 7 и sale/@customer = "alice" по сути оба являются количественными сравнениями, и их результатом будет истина, если существует элемент sale с заданным значением атрибута, но sale/@taxable = false() — это сравнение значений с фактическим логическим значением всего множества узлов. Его результат будет истиной, только если ни у одного элемента sale вообще не будет атрибута taxable.

• В модели данных XQuery/XPath узел документа может иметь либо форму документа (т. е. содержать ровно один элемент верхнего уровня, снаружи которого допускаются только комментарии и инструкции по обработке), либо форму содержимого (с ослабленными ограничениями). В XPath 1.0 ему соответствует корневой узел, который может иметь только форму документа. Это одна из причин, по которой значение типа xml, передаваемое в качестве элемента контекста любой функции QHB на базе XPath, должно быть в форме документа.

Кроме различий, отмеченных здесь, есть и другие. В языках XQuery и XPath 2.0 и новее существует режим совместимости с XPath 1.0, а имеющийся в документации W3C список изменений библиотеки функций и языковых изменений, применяемых в этом режиме, предоставляет более полное (но все же не исчерпывающее) описание различий. Режим совместимости не обеспечивает полную идентичность XPath 1.0 и более поздних языков.

Сопоставления типов данных и значений между SQL и XML

В SQL:2006 и более поздних версиях точно определены преобразования между стандартными типами данных SQL и типами стандарта XML Schema в обе стороны. Однако эти правила выражаются в типах и семантике XQuery/XPath и не могут быть напрямую применены к другой модели данных, характерной для XPath 1.0.

Когда QHB сопоставляет значения данных SQL с XML (как в функции xmlelement) или XML с SQL (как в выходных столбцах xmltable), за исключением нескольких специально обрабатываемых случаев, QHB просто предполагает, что строковая форма XPath 1.0, содержащая данные типа XML, будет допустима в качестве формы ввода в виде текста в типе данных SQL, и наоборот. Это правило подкупает своей простотой, и при этом результаты для многих типов данных именно такие, какими, согласно стандарту, должны быть у преобразований.

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

Непреднамеренные ограничения реализации

В этом разделе рассматриваются ограничения, которые присущи не самой библиотеке libxml2, а текущей реализации в QHB.

Поддерживается только механизм передачи параметров по значению (BY VALUE)

В стандарте SQL определены два механизма передачи параметров, которые применяются при передаче аргумента XML из SQL в функцию XML или получении результата: BY REF, в котором конкретное значение XML сохраняет идентификатор узла, и BY VALUE, в котором передается содержимое XML, но идентификатор узла теряется. Задать механизм можно перед списком параметров, в качестве механизма по умолчанию для всех параметров, или после каждого параметра, тем самым переопределив выбор по умолчанию.

Чтобы проиллюстрировать разницу, рассмотрим следующие два запроса. Если x является значением XML, в среде SQL:2006 они выдадут значения true и false соответственно:

SELECT XMLQUERY(’$a is $b’ PASSING BY REF x AS a, x AS b NULL ON EMPTY);

SELECT XMLQUERY(’$a is $b’ PASSING BY VALUE x AS a, x AS b NULL ON EMPTY);

QHB примет указания BY VALUE и BY REF в конструкции XMLEXISTS или XMLTABLE, но проигнорирует их. Тип данных xml содержит сериализованное представление символьной строки, поэтому идентификатор узла, который нужно сохранять, отсутствует, и фактически передача всегда производится по значению (BY VALUE).

Невозможно передать в запросы именованные параметры

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

Отсутствие типа XML(SEQUENCE)

Тип данных xml в QHB может содержать значение только в форме документа (DOCUMENT) или содержимого (CONTENT). Элемент контекста выражения XQuery/XPath должен быть одиночным узлом XML или атомарным значением, но XPath 1.0 дополнительно ограничивает его только узлом XML и не имеет типа узла, содержащего CONTENT. В результате единственной формой значения XML, которую в качестве элемента контекста XPath может предоставить QHB, является корректно сформированный документ (DOCUMENT).