3.14. Уровни языка SQL/92

В официальном стандарте SQL/92 определяются три уровня языка: полный SQL, промежуточный SQL и вводный SQL. Основная идея состоит в том, что полный SQL является полным стандартом, промежуточный SQL - cтрогое подмножество полного SQL, а вводный SQL - строгое подмножество промежуточного SQL. Разработчики стандарта стремились позволить поэтапную реализацию с продвижением от поддержки вводного SQL через поддержку промежуточного SQL к поддержке полного SQL (как мы отмечали выше, до сих пор ни одна компания-производитель реляционных СУБД не объявила, что в ее продукте целиком поддерживается полный SQL). В п. 3.14.1 перечисляются основные свойства полного SQL, которые отсутствуют в промежуточном SQL, а в п. 3.14.2 указываются основные черты, которые в дополнение к этому отсутствуют во вводном SQL.

Язык SQL, определенный стандартом, называется "соответствующим языком SQL". Реализация называется "соответствующей реализацией SQL", если в ней обрабатывается соответствующий язык SQL в соответствии со спецификациями стандарта. Таким образом, соответствующая реализация SQL должна поддерживать соответствующий язык SQL по крайней мере на вводном уровне. Такая реализация должна также поддерживать по крайней мере один "стиль связывания" (модуль, встроенный SQL или прямой SQL), и в случае модуля или встроенного SQL, по крайней мере один из официальных основных языков (Ada, Си, COBOL, FORTRAN, MUMPS, Pascal или PL/1). Более того, в такой реализации должны быть также документированы определения для всех свойств соответствующего языка SQL, которые установлены стандартом как определяемые в реализации.

Заметим, однако, что в соответствующей реализации явно допускается:

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

С другой стороны, от реализации, которая провозглашается соответствующей стандарту на любом уровне (за исключением, возможно, вводного уровня), требуется поддержка опции SQLFlagger для помечания элементов, которые не соответствуют указанному уровню (см.п.3.14.3).

В стандарте SQL/92 многие аспекты явно установлены как "зависимые от реализации", т.е. неопределенные; на самом деле, некоторые аспекты кажутся (возможно, неумышленно) неопределенными неявно. Даже если две реализации могут законно быть провозглашены соответствующими стандарту, это не дает абсолютной гарантии переносимости приложений.

В стандарте специально не определяется метод компиляции прикладных программ со встроенным SQL или иной способ их обработки.

3.14.1. Промежуточный SQL

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

Сначала мы приведем список конструкций полного SQL, которые целиком отсутствуют в промежуточном SQL:

• идентификаторы, в которых последний символ есть подчеркивание;
• явные имена каталогов;
• операторы SETCATALOG, SETSCHEMA, SETNAMES;
• операторы CONNECT, SETCONNECTION, DISCONNECT;
• все конструкции, связанные с битовыми строками;
• все, что служит для трансляции, преобразования и (явного) сравнения;
• явная спецификация точности для данных типа TIME и TIMESTAMP;
• значения SECOND для данных типа DATETIME или INTERVAL с более чем микросекундной точностью;
• функции POSITION, UPPER, LOWER;
• UNIONJOIN;
• возможность указания CORRESPONDING для операторов UNION, EXCEPT и INTERSECT;
• предикаты IS[NOT]TRUE, IS[NOT]FALSE, IS[NOT]UNKNOWN;
• условия MATCH в определениях внешнего ключа;
• утверждения целостности общего вида (операторы CREATE и DROPASSERTION);
• проверочные ограничения базовой таблицы, которые ссылаются на другие таблицы;
• определения действий ONUPDATE в определениях внешнего ключа;
• откладываемые ограничения и оператор SETCONSTRAINTS;
• "глобальные" и "объявляемые локальные" временные таблицы;
• привилегии INSERT уровня столбцов;
• LOCAL или CASCADED в опциях проверки (хотя CASCADED должно поддерживаться неявно);
• оператор ALTERDOMAIN;
• INSENSITIVE курсоры;
• спецификация "TABLE таблица" внутри табличного выражения;
• параметры или переменные основной программы как имена области дескрипторов SQL;
• все, что служит для работы с генерируемыми пользователями именами операторов;
• все, что служит для работы с генерируемыми пользователями именами курсоров;
• операторы DEALLOCATEPREPARE, DESCRIBEINPUT и возможность наличия раздела INTO в операторе EXECUTE.

Вот список дополнительных ограничений:

• ссылка на таблицу не может быть табличным выражением в круглых скобках;
• оператор DISTINCT допускается внутри табличного выражения не более одного раза на каждом уровне вложенности;
• список сравниваемых значений в правой части условия IN не должен включать более сложные элементы, чем литерал, ссылка на столбец или встроенная функция без параметров;
• если при ссылке на агрегатную функцию указывается DISTINCT, аргумент должен представлять простую ссылку на столбец;
• привилегия REFERENCES не требуется для столбцов, используемых в проверочном ограничении (это на самом деле противоположность ограничению; из этого следует, что промежуточный SQL не является вполне строгим подмножеством полного SQL);
• наличие в определении курсора ORDERBY влечет неявно свойство FORREADONLY;
• операторы INSERT, UPDATE и DELETE не могут включать раздел WHERE (ни прямо в случае поисковой операции, ни через определение курсора в случае позиционной операции), ссылающийся на таблицу, которая является целью этого оператора;
• на некоторые таблицы информационной схемы (например, TRANSLATIONS) нельзя ссылаться.

3.14.2. Вводный SQL

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

• идентификаторы длиннее, чем из 18 символов;
• малые буквы в идентификаторах;
• оператор SETSESSIONAUTHORIZATION;
• символьные строки переменного размера;
• определяемые в реализации наборы символов, включая строки национальных символов;
• все конструкции, связанные с datetime и interval;
• все, что связано с доменами;
• явные именованные ограничения;
• константы CURRENT_USER, SESSION_USER, SYSTEM_USER (однако USER поддерживается);
• CHARACTER_LENGHT, OCTET_LENGHT;
• функции SUBSTRING, TRIM, EXTRACT;
• операция конкатенации символьных строк;
• выражения с переключателем;
• оператор явного преобразования типов (CAST);
• раздел DEFAULT в операторах INSERT и UPDATE;
• явный оператор JOIN;
• операции EXCEPT и INTERSECT;
• элементы выборки в форме "R.*";
• условие UNIQUE;
• оператор DROPSCHEMA;
• оператор DROPTABLE;
• задание действия ONDELETE в определениях внешнего ключа;
• оператор ALTERTABLE;
• оператор DROPVIEW;
• оператор REVOKE;
• оператор SETTRANSACTION;
• динамический SQL;
• прокручиваемые курсоры;
• раздел FORUPDATE в определении курсора;
• преобразования между точными и приблизительными численными значениями при присваивании;
• информационная схема;
• оператор GETDIAGNOSTICS.

Вот список дополнительных ограничений:

• конструктор строки должен включать в точности один компонент, за исключением специального случая, когда конструктор строки является компонентом конструктора таблицы (в этом случае он должен быть единственным таким компонентом), и случая, когда конструктор строки используется для определения источника в операторе INSERT;
• табличное выражение в круглых скобках не может включать UNION;
• если в разделе FROM выражения выборки присутствует ссылка на представление, определение которого включает разделы GROUPBY или HAVING, то

(а) в этом разделе FROM не должны упоминаться другие таблицы;
(b) это выражение выборки не должно включать разделы WHERE, GROUPBY и HAVING;
(c) раздел SELECT этого выражения выборки не должен включать ссылок на какие-либо агрегатные функции;

• одиночный оператор SELECT не может включать разделы GROUPBY и ORDERBY и не может ссылаться на представление, в определении которого использованы разделы GROUPBY и ORDERBY;
• если какое-либо значение в условии сравнения представляет собой выражение выборки в круглых скобках, это выражение выборки не может содержать разделы GROUPBY и HAVING и не должно ссылаться на представление, в определении которого использованы разделы GROUPBY и ORDERBY;
• для UNION типы данных соответствующих столбцов должны быть в точности одними и теми же (и NOTNULL должно прилагаться ко всем или ни к кому);
• в условии LIKE первый операнд должен быть ссылкой на столбец, и "pattern" и "escape" должны быть литералами, параметрами или переменными основной программы;
• в проверке на неопределенное значение операнд должен быть ссылкой на столбец;
• оператор CREATESCHEMA должен включать раздел AUTHIRIZATION и не должен включать имени схемы;
• определение модуля должно включать раздел AUTHIRIZATION и не должен включать раздела SCHEMA;
• каждый столбец, упомянутый в определении возможного ключа, должен быть явно определен как NOTNULL;
• ключевое слово TABLE не должно появляться в операторе GRANT;
• операторы COMMIT и ROLLBACK должны включать паразитное слово WORK.

3.14.3. SQLFlagger

Как упоминалось в начале этого раздела, от реализации, которая провозглашается соответствующей стандарту на любом уровне, требуется обеспечение SQLFlagger. Назначение SQLFlagger состоит в помечании любой специфичной в реализации конструкции SQL, т.е. конструкции, которая распознается и поддерживается реализацией, но не соответствует уровню стандарта, соответствие которому провозглашено. Целью является идентификация свойств SQL, которые могли бы породить разные результаты в разных средах, т.е. свойств, которые потребовали бы внимания, если бы приложения или запросы на SQL перемещались из одной среды в другую. Такие соображения уместны, например, если приложение разрабатывается на рабочей станции, а выполняется на mainframe.

Реализация, которая объявляется соответствующей полному SQL, должна обеспечивать SQLFlagger, который поддерживает следующие опции: - EntrySQLFlagging (т.е. опцию для помечания конструкций SQL, не соответствующих вводному SQL); - IntermediateSQLFlagging (т.е. опцию для помечания конструкций SQL, не соответствующих промежуточному SQL); - FullSQLFlagging (т.е. опцию для помечания конструкций SQL, не соответствующих полному SQL).

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

Реализация, объявленная соответствующей промежуточному SQL, должна обеспечивать SQLFlagging, который поддерживает вводный SQL и промежуточный SQL, и должна поддерживать как минимум проверку "только синтаксиса".

Реализация, объявленная соответствующей вводному SQL, должна обеспечивать SQLFlagging, который поддерживает как минимум проверку "только синтаксиса" вводного SQL.

Назад | Содержание | Вперед