Накопленная информация в современных информационных технологиях хранится и организованна в базах данных. Эти базы данных создаются и работают с помощью систем управления базами данных (СУБД).
Развитие компьютерных технологий, увеличение объема и структурной сложности хранимых данных, увеличение числа пользователей информационных систем привели к распространению реляционных СУБД.
Пользоваться базами данных из разных уголков мира, с разных архитектур ЭВМ по сети можно посредствами одного стандартного языка манипулирования данными. Разработанный в 1974 году язык SQL фирмой IBM для экспериментальной реляционной СУБД System R стал стандартом (сначала де-факто), благодаря распространению двух СУБД (той же фирмы) – SQL/DS (1981 год) и DB2 (1983 год), а признание SQL международным стандартом произошло в 1987 году.
Реализация в SQL концепции операций, ориентированных на табличное представление данных, позволило создать компактный язык с небольшим (менее 30) набором предложений. SQL может использоваться как интерактивный (для выполнения запросов) и как встроенный (для построения прикладных программ).
Программисты пользуются языком SQL, чтобы писать приложения, в которых содержатся обращения к базам данных. Одни и те же операторы SQL используются как для интерактивного, так и для программного доступа, поэтому части программ, содержащие обращения к базе данных, можно вначале тестировать в интерактивном режиме, а затем встраивать в программу. В традиционных базах данных для программного доступа используются одни программные средства, а для выполнения немедленных запросов — другие, без какой либо связи между этими двумя режимами доступа.
Многие современные СУБД имеют собственные языки программирования, ряд которых включает в себя SQL. Другие работают с программами, написанными на одном из распространенных алгоритмических языков (Си, Паскаль или Фортран), в которые включаются предложения SQL. Для обмена информацией с частями программы, написанными на любых из этих языков, существуют специальные конструкции SQL, позволяющие работать с переменными и (или) отдельными строками таблиц.
В письменной работе будет рассмотрено использование SQL в прикладном программировании.
В первой главе речь пойдет о структуре модуля SQL и встроенном SQL. Определение процедур.
Во второй главе описаны операторы манипулирования данными. Операторы, связанные с курсором, а так же одиночные операторы манипулирования данными.
В третьей главе будет рассмотрен динамический SQL в Oracle V.6.
1. Язык модулей и встроенный SQL
В стандарте SQL/89 определены два способа взаимодействия с БД из прикладной программы, написанной на традиционном языке программирования.
Первый способ состоит в том, что все операторы SQL, с которыми может работать данная прикладная программа, собраны в один модуль и оформлены как процедуры этого модуля. Для этого SQL/89 содержит специальный подъязык - язык модулей. При использовании такого способа взаимодействия с БД прикладная программа содержит вызовы процедур модуля SQL с передачей им фактических параметров и получением ответных параметров.
Второй способ состоит в использовании так называемого встроенного SQL, когда с использованием специального синтаксиса в программу на традиционном языке программирования встраиваются операторы SQL. В этом случае с точки зрения прикладной программы оператор SQL выполняется "по месту". Явная параметризация операторов SQL отсутствует, но во встроенных операторах SQL могут использоваться имена переменных основной программы, и за счет этого обеспечивается связь между прикладной программой и СУБД.
Концептуально эти два способа эквивалентны. Более того, в стандарте устанавливаются правила порождения неявного модуля SQL по программе со встроенным SQL. Однако в большинстве реализаций операторы SQL, содержащиеся в модуле SQL, и встроенные операторы SQL обрабатываются существенно по-разному. Модуль SQL обычно компилируется отдельно от прикладной программы, в результате чего порождается набор так называемых хранимых процедур (в стандарте этот термин не используется, но распространен в коммерческих реализациях). Т.е. в случае использования модуля SQL компиляция операторов SQL производится один раз, и затем соответствующие процедуры сколько угодно раз могут вызываться из прикладной программы.
В отличие от этого, для операторов SQL, встроенных в прикладную программу, компиляция этих операторов обычно производится каждый раз при их использовании (правильнее сказать, при каждом первом использовании оператора при данном запуске прикладной программы).
Конечно, пользователи не обязаны знать об этом техническом различии в обработке двух видов взаимодействия с СУБД. Существуют и такие системы, которые производят одноразовую компиляцию встроенных операторов SQL и сохраняют откомпилированный код. Но все-таки лучше иметь это в виду.
При использовании языка модулей текст прикладной программы имеет меньший размер, взаимодействия с СУБД более локализованы за счет наличия явных параметров вызова процедур. С другой стороны, для понимания смысла поведения прикладной программы потребуется одновременное чтение двух текстов. Кроме того, как кажется, синтаксис модуля SQL может существенно различаться в разных реализациях. Встроенный SQL предоставляет возможность производства более "самосодержащихся" прикладных программ. Имеется больше оснований рассчитывать на простоту переноса такой программы в среду другой СУБД, поскольку стандарт встраивания более или менее соблюдается. Основным недостатком является некоторый PL-подобный вид таких программ, независимо от выбранного основного языка.
1.1. Язык модулей
Структура модуля SQL в стандарте SQL/89 определяется следующими синтаксическими правилами:
<module> ::=
<module name clause>
<language clause>
<module autorization clause>
[<declare cursor>...]
< procedure > ...
<module name clause> ::= MODULE [<module name>]
<language clause> ::= LANGUAGE { COBOL | FORTRAN | PASCAL | PLI }
<module autorization clause> ::=
AUTHORIZATION <module autorization identifier>
<module autorization identifier> ::= <autorization identifier>
Существенно, что каждый модуль SQL ориентирован на использование в программах, написанных на конкретном языке программирования. Если в модуле присутствуют процедуры работы с курсорами, то все курсоры должны быть специфицированы в начале модуля. Заметим, что объявление курсора не погружается в какую-либо процедуру, поскольку это описательный, а не выполняемый оператор SQL.
Процедуры в модуле SQL определяются следующими синтаксическими конструкциями:
<procedure> ::=
PROCEDURE <procedure name>
<parameter declaration>...;
<SQL statment>;
<parameter declaration>::=
<parameter name> <data type>
| <SQLCODE parameter>
<SQLCODE parameter> ::= SQLCODE
<SQL statement> ::=
<close statement>
| <commit statement>
| <delete statement positioned>
| <delete statement searched>
| <fetch statement>
| <insert statement>
| <open statement>
| <rollback statement>
| <select statement>
| <update statement positioned>
| <update statement searched>
Имена всех процедур в одном модуле должны быть различны. Любое имя параметра, содержащегося в операторе SQL процедуры, должно быть специфицировано в разделе объявления параметров. Число фактических параметров при вызове процедуры должно совпадать с числом формальных параметров, указанных при ее объявлении. Список формальных параметров каждой процедуры должен содержать ровно один параметр SQLCODE (код ответа процедуры; возможные значения кодов ответа стандартизованы, но некоторые из них определяются в реализации).
1.2. Встроенный SQL
Поскольку в стандарте SQL/89 не специфицированы (даже в приложениях) правила встраивания SQL в язык Си, мы приведем только общие синтаксические правила встраивания, используемые для любого языка. Это поможет оценить "степень стандартности" конкретной реализации.
<embedded SQL statement> ::=
<SQL prefix>
{ <declare cursor>
| <embedded exception declaration>
| <SQL statement>}
[<SQL terminator>]
<SQL prefix> ::= EXEC SQL
<SQL terminator> ::= END EXEC | ;
<embedded SQL declare section> ::=
<embedded SQL begin declare>
(<host variable definition>...]
<embedded SQL end declare>
<embedded SQL begin declare> ::=
<SQL prefix> BEGIN DECLARE SECTION [<SQL terminator>]
<embedded SQL end declare> ::=
<SQL prefix> END DECLARE SECTION [<SQL terminator>]
<embedded variable name> ::= :<host identifier>
<embedded exception declaration> ::=
WHENEVER <condition> <exception action>
<condition> ::= SQLERROR | NOT FOUND
<exception action> ::= CONTINUE | <go to>
<go to> ::= { GOTO | GO TO } <target>
<target> ::= :<host identifier> | <unsigned integer>
Встраиваемые операторы SQL, включая объявления курсора, а также разделы объявления исключительных ситуаций и переменных основной программы, должны быть окружены скобками EXEC SQL и END EXEC. Объявление курсора должно встречаться текстуально раньше любого оператора, ссылающегося на этот курсор. Все переменные основной программы, используемые во встроенных операторах SQL, должны быть объявлены в текстуально предшествующем этому оператору разделе объявления переменных основной программы. При этом синтаксис объявления переменной соответствует синтаксису основного языка программирования, но имени переменной предшествует двоеточие.
Механизм обработки исключительных ситуаций в SQL/89 исключительно прост (можно сказать, примитивен). Можно задавать реакцию на возникновение двух видов условий: SQLERROR - это условие появления в переменной SQLCODE после выполнения встроенного оператора отрицательного значения; NOT FOUND - условие появления в SQLCODE значения +100 (этот код означает исчерпание курсора). Реакция может состоять в выполнении безусловного перехода на метку основной программы (действие GO TO), или отсутствовать (действие CONTINUE). Срабатывает тот оператор определения реакции на исключительную ситуацию, который текстуально ближе от начала программы к данному оператору SQL.
Заметим, что во многих реализациях поддерживается два вида кодов ответа при выполнении операторов SQL (встроенных или взятых из модуля): через переменную SQLCODE с кодами ответа, представляемыми целыми числами и через переменную SQLSTATE с кодами ответа, кодируемыми десятичными числами, представленными в текстовой форме. Имеется тенденция к переходу на использование только механизма SQLSTATE, но в стандартных реализациях должен поддерживаться механизм SQLCODE.