Введение в стандарты языка баз данных SQL

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


В официальном стандарте 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) нельзя ссылаться.



Содержание раздела