Материал: Graber_Martin_-_SQL_dlya_prostykh_smertnykh_-_2014

SQL сегодня

Все указанные типы соединений поддерживаются специальными операторами в предложениях запросов FROM.

Курсоры типа READ-ONLY, SCROLLABLE, INSENSIТIVE, DYNAMIC.

Курсор - это объект, используемый для хранения выходных данных запроса на об­ работку для приложения. В стандарте SQL 89 курсор был обновляемым в принципе, то есть не существовало серии правил и предложений, защищающих от обновлений.

Теперь можно объявить его "read-only" (только для чтения). Помимо расширения сек-

361

Приложение F. SQL сегодня

ретности, обновляемые курсоры ускоряют выполнение команд, уменьшая потребно­

сти в установке замков защиты данных.

Sensitivity (чувствительность) должна выполняться для того, чтобы отразить в

курсоре внешние изменения данных, поскольку курсор транслирует операцию set-at- a-time в операцию item-at-a-time, обычную для языков программирования. Другими словами, курсор может быть открыт, а затем прочитан (вызван) постепенно. Это дает

возможность изменять данные, на которые указывает курсор, в то время, когда они

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

еще читаются открытым курсором? В соответствии со старым стандартом, ответ мог быть только один "Знает только бог!" Согласно же стандарту SQL 92, можно объявить курсор нечувствительньш (insensitive), и в этом случае он будет полностью игнориро­ вать внешний мир. Нечувствительными могут быть только курсоры read-only. Нынеш­ ний стандарт не позволяет объявить курсор чувствительным для того, чтобы в нем отражались внешние изменения данных. (Можно оставить курсор неопределенным, и тогда все, что с ним произойдет, зависит только от конкретной реализации. Остается

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

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

строки в таблице являются неупорядоченными, а строки связанные курсором, могут иметь произвольный или определенный порядок. Ранее было необходимо оперировать строками по одной за единицу времени (за один шаг обработки данных), начиная с первой и перебирая их по одной вплоть до последней. Прокручивающийся курсор по­ зволяет перемещаться скачками, возвращаться назад по мере необходимости и т.д. Ом

должен иметь статус "только для чтения".

Последнее расширение концепции курсора - динамические курсоры т.е. курсоры динамического языка SQL, которые не поддерживались в предыдущем стандарте. В

таком языке заранее неизвестно, какой запрос должен содержать курсор, поэтому со­

держимым курсора считается строковая переменная, которая может быть множеством

текстовых данных, полученных по запросу во время его выполнения. Фактически,

само имя курсора можно сделать переменным, используя предложение ALLOCATE CURSOR вместо обычного DECLARE CURSOR, поэтому вы не должны знать зара­ нее, сколько курсоров понадобится пользователю приложения. Подобно статическим курсорам, динамические курсоры могут быть "только для чтения", нечувствительны­

ми и прокручивающимися.

Ориентация клиент/сервер. Новый стандарт позволяет управлять связями, рас­ познавая всякую общую конфигурацию базы данных, на которой установлено про­ граммное обеспечение конечного пользователя (front-end) на одном компьютере, называемом <клиентом> (client), который пытается извлечь информацию из СУБД (''Ьack-end"), расположенной на другом компьютере, называемом <сервером> (server). Много новых средств, относящихся к стандартизации процедур связи, схем запирания и диагностики ошибок было мотивировано желанием клиентов единооб­ разно взаимодействовать с множеством СУБД и на множестве серверов.

362

SQL сегодня

Что такое архитектура клиент/сервер? В архитектуре клиент/сервер множест­ во компьютеров объединено в сеть, в которой все компьютеры подразделяются на

клиентов и серверов. Пользователи непосредственно взаимодействуют с клиентами

для выполнения большей части функций конечного пользователя. Серверы вьшолня­ ют различные интенсивные задания в ответ на запросы клиентов. СУБД обычно раз­ мещается на сервере и занимается обслуживанием требований клиентов. SQL хорошо

соответствует таким соглашениям, поскольку, являясь декларативным языком, он

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

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

передавать клиенту целую транзакцию и предоставлять ее для извлечения данных в

с.1учае необходимости.

В архитектуре клиент/сервер важное значение имеет вопрос о связях. Клиент дол­ жен быть связан с сервером для взаимодействия с ним. При этом стандарт нейтрален относительно частностей реализации, например, относительно того, какие платформы и сети используются. Стандарт 92 определяет, что такое SQL-связь и содержит не­ сколько основных правил регламентирующих поведение пользователей в ряде ситуа­ ций. Он базируется на реалиях компьютерной технологии клиент-сервер, в которой клиенты стремятся взаимодействовать с множеством серверов, а серверы обычно взаимодействуют с множеством клиентов.

Это не означает, что стандарт применим только к архитектурам клиент-сервер. SQL 92, как и его предшественник, является функциональной спецификацией, прием­ лемой для любой конфигурации: отдельных персональных компьютеров, стандартных миникомпьютеров и mainframe компьютеров.

Более сложное управление транзакциями. Транзакция - это группа правиль­

ных предложений SQL, которые могут выполняться или не выполняться все вместе. Ошибка в транзакции приводит к тому, что вся последовательность операций может быть отменена (canceled) или для нее может быть выполнен откат ("rolled back"). СУБД автоматически начинает транзакцию всякий раз, когда применяется предложе­

ние, вызывающее ее выполнение, при условии, что никакая друтая транзакция не яв­

ляется активной. Транзакции заканчиваются предложением СОММIТ WORК (для того чтобы сохранить изменения) или предложением ROLLBACK (при отказе от вне­ сения изменений или в случае сбоя или разъединения системе). Если транзакция не может быть восстановлена, то следует выполнить ее откат; ROLLBACK никогда не выполняется ошибочно.

Все это учитывалось в стандарте 86. В стандарте SQL 92 новым является следую­

щее:

• Транзакция может быть определена "только для чтения" (read опlу). Это означа­

ет, что предложения внутри транзакции, ориентированные на изменение содер­

жимого или структуры базы данных, вызовут ошибку, что способствует

363

Приложение F. SQL сегодня

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

•Нужно сохранять проверку ограничений до конца транзакции и можно ука­ зывать желаемые ограничения. Ограничения управляют содержимым базы

данных.

• Транзакции могут специфицировать уровни изоляции блокировок, накладывае­

мых на данные.

•Транзакции могут специфицировать размер области диагностики для предложе­

ний внутри транзакции.

Уровни изоляции. Предшествующий стандарт предполагал управление транзакциями, но совсем не учитывал совпадений, т.е. ситуаций, в которых множество различ­ ных пользователей используют одни и те же данные по-разному. Естественно, что

многопользовательские системы на рынке должны бьmи иметь и имели дело с действи­

тельностью, но теперь в ISO осуществлена некоторая стандартизация. Системы имеют четыре уровня изоляции транзакций: READ UNCOММIТTED, READ СОММIТТЕD, READ REPEAТABLE, SERIALIZAВLE. Кроме того, можно определить, что транзакция является "только для чтения" (read-only}, а для уровня изоляции READ UNCOMMITTED это необходимо.

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

могут выполнять предложения в приложении, не имея тех же привилегий, которые они

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

Иногда говорят, что привилегии, ориентированные на приложения, воплощают права разработчика, а модули, выполняемые пользователями, выполняются в соот­ ветствии с их собственными привилегиями, которые называются права.ми вызова. Су­

ществуют и другие названия привилегий, поскольку некоторые программные

продукты предполагают привилегии на владение приложением (application-owned}, считавшиеся до недавнего времени нестандартными. Сейчас они стандартизованы по

крайней мере для языка модулей, языков программирования, и это одна из причин

того, что модульный подход применяется, по-видимому, чаще других. Тем не менее SQL 92 еще не поддерживает application-owned привилегии для встроенного или дина­ мического SQL. Для однопользовательского SQL привилегии, ориентированные на приложение, несущественны. Поэтому они являются необязательными для языков

364

SQL сегодня

программирования. Могут также существовать пользователи, выполняющие приложе­ ния с персональными привилегиями. Эта ситуация относится к классу "либо-либо". Не может быть пользователей, выполняющих приложения с комбинацией их собст­ венных привилегий и привилегий приложения.

Процедура стандартного связывания. В предыдущем стандарте связь SQL- предложения с идентификатором пользователя определялась конкретной реализаци­ ей. Идентификаторы пользователей имеют привилегии. при выполнении определен­ ных предложений, и, если пользователи создают объекты (такие как таблицы) то получают право управления этими объектами. Они понятны пользователям, хотя стандарт об этом явно не говорит. С точки зрения СУБД или операционной системы, "пользователь" может не иметь соответствия один к одному с каким-либо другим пользователем или пользователями реального мира. В некоторых коммерческих про­ граммных продуктах единственный идентификатор пользователя применяется не­

сколькими реальными пользователями или отдельные пользователи могут иметь по

несколько идентификаторов. Способ распознавания идентификатора пользователя СУБД - процедура связи - обычно рассматривается только на уровне конкретной

реализации.

Стандарт SQL 92 уточняет способ связи пользователей с СУБД непосредствен­ но или через приложения. Значит, возможна ситуация, в которой данный пользова­ тель имеет несколько текущих связей, одна из которых в настоящий момент является активной. Пользователи непосредственно осуществляют переключение связи с помощью предложения SET CONNECТION. Совпадающие связи являются частью той же транзакции. Таким образом новый, стандарт ориентирован на мир клиент/сервер.

При использовании статического SQL в модульном языке программирования мож­ но осуществить связь идентификаторов пользователей и, следовательно, привилегий с приложением, а не с пользователем, и этот подход имеет преимущества. Смотрите предыдущий раздел "Привилегии владельца уровня приложения".

Стандартизация системных таблиц. Каталог (catalog) в новом стандарте рас­ сматривается как набор схем. Он содержит информационную схему (Informatioп_ Schema), которая представляет собой множество таблиц, описывающих содержимое схем: какие столбцы в каких таблицах содержатся, какие представления определены, какие привилегии связаны с каждым идентификатором пользователя и т.д. В ряде коммерческих продуктов некоторые из этих таблиц получили название "каталог". Стандартная информационная схема, определенная SQL 92, разрешает как пользова­ телям, так и приложениям применять одни и те же процедуры для получения инфор­ мации о любой схеме для любой СУБД, доступной для них.

Стандартные коды ошибок и диагностики. На предшествующих этапах разви­ тия SQL информация о результате SQL-операции передавалась через переменную число­ вого типа SQLCODE. Значение этой переменной устанавливается автоматически после

365