Замечание. Выражения UPDATE.. .WHERE CURRENT и DELETE.. .WHERE CURRENT будут недопустимы, если табличное выражение в объявлении курсора определено с участием необновляемого представления, созданного с помощью оператора CREATE VIEW (подробности приводятся в главе 9, раздел 9.6).

Динамический SQL

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

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

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

3. Сгенерировать соответствующие SQL-операторы для обращения к базе данных.

4. Возвратить сообщение и (или) полученные результаты на терминал.

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

Существует два основных динамических SQL-оператора- PREPARE и EXECUTE. Их использование проиллюстрировано на следующем (нереальном по простоте, но достаточно точном) примере.

DCL SQLSOURCE CHAR VARYING (65000) ;

SQLSOURCE = DELETE FROM SP WHERE QTY < 300 ) EXEC SQL PREPARE SQLPREPPED FROM :SQLSOURCE ; EXEC SQL EXECUTE SQLPREPPED ;

Пояснения

\. Имя SQLSOURCE идентифицирует переменную языка PL/I типа символьной строки переменной длины, в которой программа каким-либо образом конструирует исходную форму (т.е. представление в виде символьной строки) некоторого SQL-оператора, в нашем конкретном примере - оператора DELETE.

2. Имя SQLPREPPED, напротив, идентифицирует переменную среды SQL, а не базового языка PL/I, которая будет (концептуально) использоваться для хранения скомпилированной формы SQL-оператора (исходная форма которого представлена в переменной SQLSOURCE). Конечно, имена SQLSOURCE и SQLPREPPED можно выбирать произвольно.

3. С помощью оператора присвоения SQLSOURCE =...; переменной SQLSOURCE присваивается исходная форма SQL-оператора DELETE. Конечно, на практике процесс конструирования такого исходного оператора будет значительно сложнее и, возможно, в нем будут использоваться ввод и анализ некоторых элементов запросов от конечного пользователя, выраженных на обычном языке или в другой, более дружественной для пользователя форме, чем обыкновенный язык SQL.

4. Оператор PREPARE извлекает это исходное выражение и подготавливает (т.е. компилирует) его, создавая выполняемую версию извлеченного им оператора, сохраняемую в переменной SQLPREPPED.

5. Оператор EXECUTE выполняет откомпилированную версию оператора из переменной SQLPREPPED, в результате чего осуществляется собственно операция DELETE. Информация SQLSTATE выполненного оператора DELETE возвращается так же, как при выполнении аналогичного оператора обычным образом.

Обратите внимание, что, поскольку имя SQLPREPPED идентифицирует переменную языка SQL, а не PL/I, при его использовании в операторах PREPARE и EXECUTE двоеточие перед ним не указывается. Заметьте также, что подобные SQL-переменные не объявляются явно.

Описанный выше процесс в точности совпадает с процессом, который происходит, если SQL-выражения вводятся интерактивно. Во многих системах имеется некоторое подобие процессора SQL-запросов. Этот процессор в действительности - не что иное, как обобщенное интерактивное приложение, способное обрабатывать весьма широкий спектр вводимых команд, а именно - любой допустимый (или недопустимый!) оператор языка SQL. Для конструирования SQL-операторов, соответствующих вводимым пользователем командам, для компиляции и выполнения сконструированных операторов и для возврата сообщений и результатов на терминал в нем используются именно средства динамического языка SQL,

Завершая этот раздел, кратко рассмотрим более позднее (1995) дополнение стандарта SQL, известное как SQL Call-Level Interface, или кратко - просто интерфейс CLL Интерфейс CLI, в основном, строится на базе интерфейса Open Database Connectivity компании Microsoft (ODBC), Благодаря интерфейсу CLI приложения, которые написаны на одном из базовых языков, могут выдавать запросы к базе данных, обращаясь к процедурам CLI, предоставляемым изготовителем. Затем эти процедуры, обязательно предварительно связанные с данным приложением, используют динамический язык SQL для выполнения требуемых операций с базой данных от имени приложения. (Иными словами, с точки зрения СУБД процедуры CLI могут считаться просто другим приложением.)

Как видим, интерфейс SQL/CLI (и ODBC тоже) решает ту же задачу, что и динамический язык SQL, а именно - позволяет приложению предоставлять текст SQL-оператора лишь к тому времени, когда его непосредственно необходимо выполнять. Однако подход интерфейсов CLI и ODBC к решению этой задачи лучше, чем подход динамического языка SQL. Эти преимущества заключаются в следующем.

Во-первых, динамический SQL - это стандарт исходного кода. Поэтому для любого приложения, которое использует динамический язык SQL, требуется какой-то SQL-компилятор, необходимый для обработки установленных стандартом операций, таких как PREPARE, EXECUTE и т.д. Интерфейсом CLI, напротив, нормированы лишь детали вызова процедуры (т.е., в основном, вызовов подпрограмм). Не требуется услуг никакого специального компилятора, достаточно использовать обычный компилятор стандартного базового языка. Поэтому приложение может распространяться (возможно, сторонними изготовителями программного обеспечения) в сжатой форме в виде объектного кода.

Во-вторых, такие приложения могут быть независимыми от типа СУБД, т.е. интерфейс CLI включает средства создания обших приложений (опять же, возможно, от сторонних изготовителей программного обеспечения), которые могут использоваться для нескольких различных типов СУБД вместо специальных для какой-то конкретной СУБД.

Такие интерфейсы, как CLI, ODBC и JDBC (вариант ODBC для языка Java), приобретают все более важное значение по причинам, которые будут обсуждаться (частично) в главе 20.

4.7. Несовершенство языка SQL

Как отмечалось во введении к этой главе, язык SQL далек от совершенства и имеет недостатки, вызванные многочисленными недоделками и переделками. Конкретные критические замечания будут представлены в последующих главах. Здесь лишь отметим, что основной недостаток заключается в том, что, строго говоря, язык SQL, в целом, некорректно поддерживает реляционную модель. Поэтому возникает сомнение, заслуживают ли современные SQL-продукты права называться действительно реляционными. Фактически, насколько это известно автору, на сегодняшний день на рынке нет ни одного продукта, который поддерживал бы реляционную модель в полном объеме. Мы не хотим этим сказать, что какие-то аспекты реляционной модели не важны; как раз наоборот, каждый элемент в модели важен. Более того, каждый из ее элементов важен по чисто практическим соображениям. Нельзя не подчеркнуть тот непреложный факт, что назначение реляционной теории состоит не в том, чтобы просто быть теорией для теории . Вовсе нет, ее назначение - обеспечить базу для построения систем, которые будут практическими на все сто процентов. Но, как это ни печально, со стороны изготовителей продуктов еще не сделано реальных шагов к решению проблемы реализации реляционной теории во всей ее полноте. В результате реляционные продукты сегодняшнего дня все как один по тем или иным причинам оказываются неспособными реализовать преимущества, которые теоретически могут быть получены в результате использования реляционной технологии.

4.8. Резюме

На этом завершается знакомство с некоторыми важнейшими функциональными возможностями, предусмотренными стандартом языка SQL (точнее, SQL/92). Мы подчеркиваем тот факт, что язык SQL очень важен с коммерческой точки зрения, хотя, к сожалению, в определенной степени несовершенен с чисто реляционной точки зрения.