В этой части курса содержится
краткая сводка основных различий между
языками SQL/89 и SQL/92.
4.1. Сводка расширений SQL/92 по отношению к SQL/89
В этом разделе мы приводим сводку
основных новых свойств, введенных в SQL/92.
Все, что относится к встроенному SQL.
Встроенный SQL не являлся частью SQL/89 и был
частично специфицирован только в
приложениях. Кроме того, в этих
приложениях не специфицировалась
поддержка языков Си и Ада.
Все, что относится к работе с каталогами
и почти все, что касается работы со
схемами. В SQL/89 имелся оператор CREATESCHEMA, но
не было оператора DROPSCHEMA, и все операторы
CREATETABLE, CREATEVIEW и GRANT должны были
специфицироваться как "элементы схемы"
внутри такого оператора CREATESCHEMA (т.е. не
было понятия независимого выполнения
таких операторов, как в SQL/92). Однако
понятие схемы было по существу не
определено. Заметим также, что CREATETABLE,
CREATEVIEW и GRANT в SQL/89 были только операциями
определения данных; не существовали DROPTABLE,
ALTERTABLE и т.д.
Возможность включать в модуль все виды
операторов SQL. Как уже отмечалось, CREATETABLE,
CREATEVIEW и GRANT в SQL/89 должны были выполняться
как компоненты операции CREATESCHEMA; на самом
деле, CREATESCHEMA, CREATETABLE, CREATEVIEW и GRANT вместе
составляли отдельный "язык схемы",
который отличался от "языка модулей".
Нежелательное и не необходимое различие
между языком схем и языком модулей почти
полностью устранено в SQL/92.
Возможность включать все виды операций
SQL (в частности, возможность смешивать
операции определения данных и
манипулирования данными) в одну
транзакцию. По причине разделения языков
схем и модулей, отмеченного в предыдущем
параграфе, SQL/89 не обладал этим свойством.
Все, что относится к управлению
подключениями и сессиями.
Оператор SETTRANSACTION, включающий, в
частности, возможность определения
уровня изоляции (в SQL/89 поддерживался
только уровень SERIALIZABLE, и только неявно).
Все, что относится к работе с доменами,
включая CREATE, ALTER и DROPDOMAIN.
Операторы ALTER и DROPTABLE.
Все, что связано с работой с временными
таблицами.
Варианты CASCADED и LOCAL опции проверки при
CREATEVIEW.
Оператор DROPVIEW.
Почти все, что относится к работе с
ограничениями целостности, за
исключением случаев определения
возможного и внешнего ключей и одного
простого вида проверочного ограничения
базовой таблицы. В SQL/89 имелись возможные
и внешние ключи и проверочные
ограничения для одной строки (т.е.
ограничения, которые можно проверять для
данной строки, рассматривая ее в изоляции).
Однако отсутствовали общие (с
несколькими строками) ограничения, не
было разновидностей FULL и PARTIAL для
соответствия внешних ключей и не было
отложенных проверок (DEFERRABLE, INITIALLYDEFERRED,
SETCONSTRAINTS и т.д.).
Оператор REVOKE.
Строки символов переменной длины.
Битовые строки постоянной и переменной
длины.
Все, что относится к работе с датами и
временем.
Почти все, что касается работы с
наборами символов, сравнениями,
трансляциями и преобразованиями (включая
поддержку национальных наборов символов
и наборов символов для идентификаторов).
В SQL/89 поддерживался тип данных строк
постоянной длины вместе с
соответствующим набором операторов
присваивания и сравнения, но это все, что
было (в частности, набор символов и
правила их сравнения определялись по
существу в реализации).
Все скалярные операторы и функции (за
исключением +, -, *, / и USER), включающие, в
частности, операторы CASE и CAST для
управления преобразованиями типов
данных.
Существенно улучшенная ортогональность
в скалярных выражениях, включая, в
частности, возможность использования
скалярных выражений из базы данных как
операндов внутри таких выражений.
Спецификации FORUPDATE, SCROLL и INSENSITIVE в DECLARECURSOR.
Существенно улучшенная ортогональность
в табличных выражениях, включая
(а) возможность вводить имена столбцов
результата и имена таблиц;
(b) набор правил вывода имени столбца;
(c) возможность вложенных табличных
выражений.
Явная поддержка INTERSECT, EXCEPT и JOIN (включая
естественные и внешние соединения).
Конструкторы строк, включая, в частности,
возможность использования таких
конструкторов в условных выражениях
наряду со скалярами.
Новые условия MATCH и UNIQUE.
Новые условия IS[NOT]TRUE, IS[NOT]FALSE и IS[NOT]UNKNOWN.
Все, что касается динамического SQL.
Информационная схема.
SQLSTATE и все, что касается работы с
областью диагностики.
Более исчерпывающее обращение с прямым
SQL (хотя многие конкретные вещи все еще
остались определяемыми в реализации).
4.2. Несовместимости SQL/92 и SQL/89
Документ SQL/92 включает приложение,
в котором устанавливаются несовместимости
между SQL/92 и SQL/89. Мы перечислим эти
несовместимости ниже.
В SQL/92 имеется более 100 дополнительных
зарезервированных слов. Конкретные
детали следует смотреть в самом
стандарте.
В SQL/89 модуль, происходящий из
встроенного SQL, имел идентификатор
авторизации, определяемый в реализации; в
SQL/92 он вообще не имеет идентификатора
авторизации.
Имена параметров в SQL/89 не имели префикса
в виде двоеточия. SQL/92 требует наличия
такого префикса.
SQL/89 допускает определение двух
различных возможных ключей для одной
базовой таблицы с заданием одного и того
же набора столбцов. SQL/92 этого не
допускает.
SQL/89 не препятствует рекурсивному
определению представления, т.е. в
терминах его же самого. SQL/92 не допускает
этой возможности.
Семантика WITHCHECKOPTION была двусмысленной в
SQL/89, но была прояснена в SQL/92. (По крайней
мере, это утверждается в документе SQL/92.
Более точно, опция проверки не являлась
наследуемой в SQL/89, но является таковой в
SQL/92 по умолчанию.)
Пусть в спецификации курсора C
отсутствует раздел GROUPBY, и пусть курсор C
открывается несколько раз внутри одной и
той же транзакции. В SQL/89 требуется, чтобы
строки, доступные через курсор C,
возвращались в одном и том же порядке при
каждом открытии. В SQL/92 порядок при каждом
открытии зависит от реализации и,
следовательно, может отличаться для
разных открытий курсора.
В соответствии со стандартом SQL/89, если
курсор установлен на некоторую строку
или перед ней, и эта строка удаляется,
курсор устанавливается перед следующей
строкой или (если следующей строки нет)
после последней строки. (Заметим, что это
требование достаточно трудно
удовлетворить в реализации.) В SQL/92
изменение состояния курсора
определяется только если операция DELETE
производится через тот же самый курсор; в
противном случае воздействие на курсор
зависит от реализации.
В SQL/89 привилегия SELECT требовалась только
для таблиц, к которым производится доступ
через операторы FETCH или одиночный SELECT. В SQL/92
это дополнительно требуется для таблиц,
упоминаемых в некоторых табличных
выражениях, условных выражениях и
скалярных выражениях.
В стандарте SQL/92 указываются еще
некоторые виды несовместимости, но их
формулировка слишком сложна, а сами они не
слишком важны, чтобы упоминать о них в нашем
курсе. С другой стороны, независимые авторы
(в частности, К.Дейт) отмечают наличие
некоторых дополнительных несовместимостей,
не специфицированных в стандарте. Среди них
следующие:
Фактически, SQL/89 состоял из двух разных
языков - языка модулей и языка
определения схем. Операторы CREATETABLE, CREATEVIEW
и GRANT могли появляться только как
элементы внутри оператора CREATESCHEMA, и этот
оператор в свою очередь был оператором
языка определения схем; таким образом,
CREATESCHEMA (и следовательно, CREATETABLE, CREATEVIEW и
GRANT) не могли появляться внутри модуля. В
попытке сохранить совместимость с этим
достаточно странным обстоятельством, в
стандарте SQL/92 многократно указывается,
что оператор CREATESCHEMA мог бы не включаться
в модуль; однако из описания языка не
видно способа осуществить эту
возможность.
В SQL/89 привилегия REFERENCES требовалась
только для возможных ключей, на которые
ссылались некоторые внешние ключи. В SQL/92
это требуется для любого столбца, который
встречается в некотором ограничении
целостности.
Стандарт SQL/89 допускает использование
квалифицированных имен столбцов в
разделе ORDERBY. SQL/92 этого не допускает. (На
самом деле, это изменение лучше
расценивать как исправление ошибки SQL/89, а
не как несовместимость, поскольку в
соответствии со спецификациями SQL/89
область видимости квалифицированного
имени столбца не включала или, по крайней
мере, не должна была включать раздел ORDERBY.)
В соответствии со стандартом SQL/92
значением константы USER является текущий
идентификатор авторизации. В SQL/89
значением USER должен являться
идентификатор авторизации модуля.
В SQL/89 квалификатором имени высшего
уровня для (например) имен базовых таблиц
был идентификатор авторизации. В SQL/92 это
имя схемы, которое, в свою очередь,
включает (возможно, неявное) имя каталога
как другой (более высокого уровня)
квалификатор.
4.3. Осуждаемые свойства языка SQL/89
В стандарте SQL/92 присутствует
приложение, устанавливающее "осуждаемые
свойства" языка, т.е. свойства, которые
оставлены в SQL/92 только для обеспечения
совместимости с SQL/89 и которые, вероятно,
будут удалены в какой-нибудь будущей версии
стандарта. Эти свойства включают следующее:
Переменная SQLCODE (предпочтительнее SQLSTATE).
Следовательно, например, целая
переменная программы на языке Кобол,
определенная как USAGEASCOMPUTATIONAL, также
является осуждаемой, поскольку USAGE
поддерживается только для SQLCODE.
Беззнаковые целые как элементы
упорядочивания в разделе ORDERBY (предпочтительнее
использовать имена столбцов, введенные
через раздел AS для соответствующих
элементов выборки).
Незаключенный в скобки список
параметров в процедурах (предпочтительнее
заключенные в скобки списки через
запятую).