Стандарты языка реляционных баз данных SQL: краткий обзор
Страница 24. Сводка отличий SQL/92 от SQL/89. Часть 2

4. 2. 1. 7 ВЫРАЖЕНИЯ ЗАПРОСОВ

При построении выражений запросов (формально, согласно синтаксису SQL/92, соответствующие конструкции не называются выражениями запросов; тем не менее мы предпочитаем сохранить этот термин для сближения с семантикой SQL/89), кроме операции теоретико-множественного объединения UNION, которая присутствовала в SQL/89, стало возможным использовать операции EXCEPT (теоретико-множественное вычитание) и INTERSECT (теоретико-множественное пересечение). Заметим для точности, что возможность получения в качестве результата запроса мультимножества строк (т. е. с дубликатами) не позволяет однозначно интерпретировать сразу все эти операции. Поэтому результат одного и того же выражения запросов в разных реализациях может быть разным.

4. 2. 1. 8 КУРСОРЫ

При определении курсора можно указывать ключевые слова SCROLL и INSENSITIVE. Указание SCROLL означает, что курсор можно явно позиционировать: на первую строку результирующего множества запроса, на последнюю строку, на строку с позицией с положительным или отрицательным смещением от текущей строки, на строку с явно указанным абсолютным номером позиции. Наличие ключевого слова INSENSITIVE означает, что какие бы изменения в базовых таблицах не производились в той же транзакции, в которой определен курсор, они не должны влиять на результирующее множество строк курсора после его открытия. Заметим, что, хотя внешне эти возможности выглядят очень привлекательно, их реализация стоит недешево. И в том и в другом случае требуется явное и почти всегда полное построение результирующего множества запроса, связанного с курсором.

4. 2. 1. 9 УПРАВЛЕНИЕ ТРАНЗАКЦИЯМИ И УРОВНИ ИЗОЛЯЦИИ

Известно, что в большинстве SQL-ориентированных реляционных СУБД поддерживаются несколько режимов изолированности транзакций. В стандарте SQL/92 специфицирован оператор SET TRANSACTION, который, в частности, позволяет явно установить один из следующих режимов, влияющих на уровень изолированности транзакции: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE.

В соответствии со стандартом режим READ UNCOMMITTED допускает наличие чтения "грязных данных " (если транзакция T1 работает в этом режиме, то она может прочитать данные, обновленные транзакцией T2, которая заканчивается откатом; эти данные "грязные ", поскольку никогда не будут существовать в БД).

При установке режима READ COMMITTED транзакция не сможет прочитать "грязные данные ", но в ней может возникнуть ситуация "неповторяющегося чтения " (пусть транзакция T1 работает в этом режиме и в ней выполняется выборка некоторой строки некоторой таблицы; после этого в транзакции T2срабатывает оператор, обновляющий эту строку; теперь в транзакции T1 снова выполняется оператор, выбирающий ту же строку, и прикладная программа или интерактивный пользователь с удивлением обнаруживают, что значения полей строки изменились).

Если устанавливается режим REPEATABLE READ, "неповторяющиеся чтения "должны гарантированно отсутствовать, но возможно возникновение "строк-фантомов "(пусть транзакция T1 работает в этом режиме и выбирает некоторое множество строк некоторой таблицы в соответствии с заданным условием; после этого транзакция T2 заносит в ту же таблицу новую строку, удовлетворяющую условию выборки транзакции T1; теперь в транзакции T1 повторно срабатывает тот же самый оператор выборки, и прикладная программа или интерактивный пользователь с удивлением обнаруживают, что множество выбранных строк отличается оттого, как им оно было при первом выполнении оператора выборки).

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

Кроме указания режима изоляции в операторе SET TRANSACTION можно указать, является ли транзакция только читающей базу данных (READ ONLY) или обновляющей(READ WRITE). По умолчанию любая транзакция считается обновляющей, если только не задан режим изоляции READ UNCOMMITTED. В последнем случае транзакция полагается только читающей. Другими словами, комбинация READ WRITE и READUNCOMMITTED является недопустимой. 

4. 2. 1. 10 ДИНАМИЧЕСКИЙ SQL

В стандарте определены операторы динамического SQL. См. разд. 4. 1.

4. 2. 1. 11 ВСТРОЕННЫЙ SQL

как отмечалось в разд. 2. 5, стандарт SQL/89 формально не включал раздел, посвященный встраиванию конструкций SQL в программу на традиционном языке программирования. Этот раздел являлся приложением и, кроме того, не включал правил встраивания для языков Си и Ада. В SQL/92 полностью специфицированы правила встраивания для наиболее распространенных языков программирования(Ада, Си, Кобол, Фортран, MUMPS, Паскаль, ПЛ/1).

4. 2. 1. 12 ИНТЕРАКТИВНЫЙ (ПРЯМОЙ) SQL

В SQL/92 специфицирован набор операторов SQL, которые должны поддерживаться в интерактивном режиме, хотя некоторые решения по-прежнему отдаются на откуп реализациям.

Этим не исчерпываются расширения SQL/92 по сравнению с SQL/89. Однако не упомянутые выше новые возможности SQL не кажутся настолько важными, чтобы о них стоило писать в журнальной статье (может быть , я и ошибаюсь. . . ).

4. 2. 2 Несовместимости

В стандарте SQL/92 содержится приложение, в котором устанавливаются несовместимости между SQL/92 и SQL/89. Формально SQL/92 не включает в себя полностью SQL/89, т. е. некоторые конструкции SQL/89 не соответствуют стандарту SQL/92. Конечно, при переходе от SQL/89 к SQL/92 нужно внимательно отнестись к этим несоответствиям. Однако, во-первых, эти несоответствия являются слишком техническими и непринципиальными, чтобы описывать их в этой статье. Во-вторых, ни один производитель СУБД никогда не пойдет на то, чтобы с использованием его нового продукта перестали работать ранее разработанные прикладные системы. Поэтому можно быть почти уверенным (или уверенной), что в реализациях SQL/89 по-прежнему будет поддерживаться. Так что по поводу несоответствий мы отсылаем читателя к тексту стандарта SQL/92.