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

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

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

Выполнение программы со встроенным SQL

Вспомним (рис. 17.3), что в процессе компиляции программы со встроенным SQL создаются два исполняемых компонета: собственно исполняемая программа и план ее выполнения, сохраняюшийся в базе данных. При запуске программы со встроенным SQL два указанных компонента выполняют необходимую работу совместно:

1. Исполняемая программа загружается обычным способом, и начинается вьшолнение ее инструкций.

2. Один из первых вызовов, подготовленных препроцессором, - это вызов функции СУБД, которая находит и загружает план выполнения для данной программы.

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

4. Программа продолжает работать, как описано в п.п. 1-3, совместно с СУБД выполняя задачу определенную исходной программой со встроенным SQL.

Защита данных во время выполнения

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

идентификатор того пользователя, который разработал программу, или, более точно, того, кто запускал утилиту BIND, чтобы создать план выполнения;

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

Может показаться странным, что СУБД должна учитывать идентификатор того пользователя, который запускал утилиту BIND, но фактически в системе безопасности DB2 и ряда других коммерческих СУБД применяются оба идентификатора пользователя. Чтобы разобраться в принципе работы системы безопасности, предположим, что пользователь joe вьшолняет программу ordmaint (программу обслуживания заказов), которая обновляет таблицы orders, sales и offices. План выполнения для программы ordmaint был создан администратором по обработке заказов, Имеющим идентификатор пользователя opadmin.

в DB2 план выполнения является защищаемым объектом базы данных. Чтобы реализовать план, пользователь joe должен иметь на него привилегаю execute. Если такой привилегаи у него нет, программа вьшолняться не будет. Когда программа выполняется ее встроенные инструюгии insert, update и delete изменяют содержимое базы данных. Привилегии пользователя с идентификатором opadmin определяют, осуществит ли исполняемый файл, содержащий план вьшолнения, эти изменения. Обратите внимание на то, что названный файл может модифицировать таблицы, даже если у пользователя joe нет требуемых привилегий. Однако могут быть сделаны только те изменения которые явно заданы во встроенных инструкциях SQL данной программы. Таким образом, DB2 осуществляет четкое управление схемой защиты базы данных. Можно значительно ограничить привилегии пользователей на доступ к таблицам, не лишая их возможности пользоваться готовыми программами.

Не во всех СУБД осуществляется защита плана вьшолнения. Там, где ее нет, привилегии плана вьшолнения определяются привилегиями пользователя, выполняющего программу. Согласно этой схеме, у пользователя должны быть привилегии на вьшолнение всех действий, имеющихся в плане, иначе программа завершится неуспешно. Если в интерактивном режиме пользователь не должен иметь те же привилегии, то необходимо ограничить для него доступ к самой интерактивной программе; это является недостатком данной системы защиты.

Автоматическая перекомпоновка

Следует отметить, что план вьшолнения оптимизируется для структуры базы данных, существующей в тот момент, когда утилита BIND помещает план в базу данных. Если позднее структура изменится (например, будет удален индекс или столбец из таблицы), любой план вьшолнения, в котором имеются ссьики на измененные структурные элементы, может стать недействительным. Для обработки таких ситуаций в СУБД вместе с планом вьшолнения хранится копия его исходных инструкций SQL. СУБД также отслеживает состояние всех объектов базы данных, от которых зависит план вьшолнения. Если какой-нибудь из этих объектов модифицируется инструкцией DDL, СУБД автоматически отмечает план как недействительный . Когда в следующий раз программа попытается использовать этот план, СУБД обнаружит такую ситуацию и автоматически перекомпонует инструкции, создав новый образ плана. Автоматическая перекомпоновка остается совершенно незаметной для прикладной программы, за исключением того что может увеличиться время вьшолнения инструкций.

Хотя СУБД автоматически перекомпоновывает план при изменении одного из структурных элементов, с которым связан данный план, она не способна обнаружить изменения в структуре базы данных, позволяющие улучшить план. Например, если во время компоновки плана отсутствовал соответствующий индекс и поэтому данный план последовательно сканировал некоторую таблицу, то вполне возможно, что позднее этот индекс был создан с помощью инструкции create index. Чтобы воспользоваться преимуществами новой структуры, необходимо запустить утилиту BIND и перекомпоновать план.

Простые инструкции встроенного SQL

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

Удалить данные обо всех служащих с объемом продаж ниже $150000.

DELETE FROM SALESREPS WHERE SALES < 150000.00

Ha рис. 17.4,17.5 и 17.6 приведены три программы, которые с помощью встроенного SQL выполняют ту же задачу, что и данная инструкция интерактивного SQL. Эти про-1ралшы написаны на С, COBOL и FORTRAN соответственно. Хотя программы являются очень простыми, они иллюстрируют основные особенности встроенного SQL:

Инструкции встроенного SQL могут находиться между инструкциями базового языка программирования. Обычно не имеет значения, прописными или строчными буквами набраны инструкции SQL. Это определяется стилем базового языка.

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

Если встроенная инструкция SQL занимает несколько строк, то факт продолжения инструкции на следующую строку обозначается в соответствии с правилами базового языка. В программах на С, PL/I и COBOL никакого специального символа не требуется. В программах на FORTRAN вторая и последующие строки инструкции должны иметь в столбце 6 символ продолжения.

Каждая встроенная инструкция SQL заканчивается ограничителем, обозначающим ее окончание. В разных базовых языках применяются различные ограничители. В языке COBOL ограничителем является строка END-EXEC , заканчивающаяся точкой, как и другие инструкции COBOL. В PL/I и С ограничитель представляет собой точку с запятой, которая в этих языках также является символом окончания инструкции. В языке FORTRAN встроенная инструкция SQL заканчивается, когда отсутствует символ продолжения.

main О {

exec sql include sqlca;

exec sql declare salesreps table

(empl num integer not null,

name varchar(15) not null,

age integer,

rep office integer,

title varchar (10),

hire date date not null,

manager integer,

quota money,

sales money not null) ;

/* Выдать сообщение */

Prmtf ( Удаление данных о служащих с низким объемом продаж.\п );

/* Выполнить инструкцию SQL */ exec sql delete from salesreps where sales < 150000.00,-

/* Выдать другое сообщение */ Printf( Удаление закончено.\n ); exit(O),-