Карпова Т.С. Базы данных: модели, разработка, реализация

Подождите немного. Документ загружается.

Особенности

встроенного

SQL 251

данных,

которые

согласуются

базовыми

языками

программирования.

Во

встроенном

SQL

запросы делятся

на 2

типа:

Однострочные

запросы,

где

ожидаемые результаты

соответствуют

одной

стро-

ке

данных.

Эта

строка

может

содержать

значения

нескольких

столбцов.

Многострочные

запросы,

результатом которых является

получение

целого

на-

бора

строк.

При

этом

приложение

должно

иметь возможность проработать

все

полученные

строки. Значит,

должен

существовать механизм,

который

под-

держивает просмотр

обработку полученного набора строк.

Первый

тип

запроса

—

однострочный

запрос

во

встроенном

SQL

вызвал

моди-

фикацию оператора

SQL,

которая выглядит

следующим

образом;

'SELECT

[{ALL

DISTINCT}]

<список

возвращаемых

столбцов*

INTO

<список

переменных

базового

языка>

FROM

<список

исходных

таблиц>

[WHERE

<условия

соединения

поиска>]

Мы

видим,

что во

встроенный

SELECT

добавился

новый

для нас

раздел,

содер-

жащий

список

переменных

базового

языка.

Именно

эти

переменные

будет

по-

мещен

результат

однострочного

запроса,

поэтому

список

переменных

базового

языка

должен

быть согласован

как по

порядку,

так и по

типу

размеру данных

со

списком

возвращаемых

столбцов.

По

правилам

любого

языка

программиро-

вания

все

базовые

переменные

предварительно

описаны

прикладной

програм-

ме.

Например,

если

нашей

БД

«Библиотека»

существует

таблица

READERS

(Чи-

татели),

мы

можем получить сведения

конкретном

читателе.

CREATE

TABLE

READERS

(

READERJD

Small1nt(4)

PRIMARY

KEY.

FIRSTJAME

char(30)

HOT

NULL,

LAST_NAME

charCSO)

NOT

NULL,

ADRES

char(50)

HOME_PHON

char(12)

WORK.PHON

char(12)

BIRTHJAY

date

СНЕШ

DateD1ff(year,

GetDateO.BIRTHJJAY)

>°17

)

);

Для

этого

опишем

базовые

переменные.

Рассмотрим

пример

для MS SQL

SERVER 7.0, используя язык Transact SQL,

При

описании

локальных

перемен-

ных

языке

Transact

SQL

используется

специальный

символ

Комментарии

Transact

SQL

заключены

парные

символы

комментарий

*/•

DECLARE

(aREADERJD

int

DECLARE

GFIRSJAME

CharOQ).

OLASTJAHE

CharCSO),

CADRES

Char(50)

DECLARE

@HOMEJ>HON

Char(12).QUQRKJ>HON

Char(12)

зададим

уникальный

номер

читательского

билета

252

Глава

12.

Встроенный

SQL

SET

0READERJD

теперь

выполним

запрос

поместим

полученные сведения

определенные

ранее

переменные

SELECT

READERS,FIRSTJIAME.

READERS,LASTJAME.

READERS.AORES.

READERS.

HOME..PHON,

READERS.

WQRKJ»HON

INTO

SFIRSJAME.

0LASTJWME.

0ADRES.

@HOME_PHON.@WORK_PHON

FROM

READERS

WHERE

READERS.READER_ID

GREADERJD

этом простом

примере

мы

имена

переменных

сделали

такими

же,

как

имена

столбцов таблицы

READERS,

no это

необязательно. Однако транслятор

различает

эти

объекты,

именно

поэтому

диалекте

Transact

SQL

принято

локальные

пере-

менные

предварять специальным символом

примере

мы

использовали ква-

лифицированные

имена полей,

имена

полей,

предваряемые именем

таблицы,

пашем случае

это

тоже

необязательно,

потому

что

запрос выбирает

данные

только

из

одной

таблицы.

нашем примере базовые

переменные

играют

разную

роль,

Локальная

пере-

менная

@READER_ID

является входной

по

отношению

запросу.

Ей

присвоено

зна-

чение

запросе

это

значение

используется

для

фильтрации

данных,

поэто-

му эта

«временная

используется

условии

WHERE,

Остальные

базовые

переменные играют роль

выходных

переменных,

них

СУБД

помещает

результат

выполнения

запроса,

помещая

в них

значения

соответ-

ствующих

полей

отношения

READERS,

извлеченные

из

БД,

Операторы,

связанные

многострочными запросами

Рассмотрим

более

сложные

многострочные запросы.

Для

реализации

многострочпых

запросов вводится новое

понятие

—

понятие

курсора

или

указателя

набора

записей.

Для

работы

курсором

добавляется

не-

сколько

новых

операторов

SQ.L:

Оператор

DECLARE CURSOR

определяет

выполняемый

запрос,

задает

имя

кур-

сора

связывает результаты запроса

заданным курсором. Этот оператор

не

является

исполняемым

для

запроса,

он

только

определяет

структуру буду-

щего множества

записей

связывает

ее с

уникальным

именем

курсора. Этот

оператор

подобен операторам

описания

данных

языках

программирования.

Оператор

OPEN

дает команду СУБД

выполнить

описанный

запрос, создать

виртуальный

набор

строк,

который

соответствует

заданному

запросу.

Опера-

тор

OPEN

устанавливает указатель записей (курсор)

перед

первой

строкой

виртуального

набора

строк результата,

Оператор

FETCH

продвигает

указатель

записей

на

следующую

позицию

вир-

туальном

наборе

записей.

большинстве

коммерческих

СУБД оператор

пере-

мещения

FETCH

реализует

более

широкие

функции

перемещения,

он

иозволя-

Операторы,

связанные

многострочными

запросами

253

ет

перемещать указатель

на

произвольную

запись,

вперед

назад,

допускает

как

абсолютную

адресацию,

так и

относительную

адресацию,

позволяет уста-

новить курсор

на

первую

или

последнюю

запись виртуального набора,

Оператор

закрывает курсор

прекращает доступ

виртуальному

набо-

ру

записей.

Он

фактически

ликвидирует

связь между курсором

результа-

том

выполнения

базового запроса.

Однако

коммерческих СУБД оператор

не

всегда означает

уничтожение

виртуального набора записей.

Мы

кос-

немся этого

далее,

когда будем

рассматривать

работу

курсором

в MS SQL

Server

7,0.

Оператор

определения

курсора

Стандарт

определяет

синтаксис

оператора

определения

курсора:

DECLARE

<имя_курсора>

CURSOR

FOR

<спецификация_курсора>

спецификация

курсора>::

<выражение_запроса

SELECT>

'Имя

курсора

— это

допустимый

идентификатор

базовом

языке

программиро-

вания,

объявлении курсора могут быть

использованы

базовые переменные. Однако

необходимо помнить,

что на

момент

выполнения

оператора

OPEN

значения

всех

базовых

переменных,

используемых

качестве входных

переменных,

связанных

условиями

фильтрации

значении

базовом

запросе,

должны быть

уже

заданы.

Определим

курсор,

который

содержит

список всех

должников

нашей

библиоте-

ки.

Должниками

назовем

читателей,

которые

имеют

па

руках хотя

бы

одну

кни-

гу,

срок сдачи которой

уже

прошел.

DECLARE

Debtor_reader_cursor

CURSOR

FOR

SELECT

READERS,FIRST

JAME.

READERS.

LAST

JAME.

READERS.AORES,

READERS.

HOMEJHON.

READERS.WQRK_PHON,

BOOKS.TITLE

FROM

READERS.BOOKS,EXEMPLAR

WHERE

READERS.READERJD

EXEMPLAR.READERJD

AND

BOOKS.ISBN

EXEMPLARE.ISBN

AND

EXEMPLAR.DATAJJUT

GetdateO

ORDER

READERS.FIRST

JAME

При

определении

курсора

мы

снова'использовали

функцию

Transact

SQL

GetdateO,

которая

возвращает

значение

текущей

даты.

Таким

образом,

определенный

кур-

сор

будет

создавать

набор

строк,

содержащих

перечень

должников,

указанием

названий

книг, которые

они

не

вернули вовремя

библиотеку,

соответствии

со

стандартом

SQL2

Transact

SQL

содержит

расширенное

опреде-

ление

курсора

DECLARE

<имя_курсора>

[INSENSITIVE]

[SCROLL]

CURSOR

FOR

<оператор

выбора

SELECT>

[FOR

{READ

ONLY

UPDATE

[OF

<мня_столбца

C,...n]]}3

254

Глава

12.

Встроенный

SQL

Параметр

INSENSITIVE

(нечувствительны!!)

определяет режим

создания

набора

строк,

соответствующего определяемому курсору,

при

котором

все

изменения

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

пользо-

вателями,

не

видны

нем. Такой набор данных нечувствителен

ко

всем измене-

ниям,

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

исходных

табли-

цах,

этот

тип

курсора соответствует

некоторому

мгновенному слепку

с БД.

СУБД более быстро

экономно

может обрабатывать такой курсор, поэтому

если

для"вас

действительно важно рассмотреть

обработать состояние

БД на

неко-

торый

конкретный момент времени,

то

имеет смысл создать

«нечувствительный

курсор».

Ключевое

слово

SCROLL

определяет,

что

допустимы

любые

режимы

перемещения

по

курсору

(FIRST.

LAST, PRIOR, NEXT, RELATIVE, ABSOLUTE)

операторе

FETCH.

Если

не

указано ключевое слово

SCROLL,

то

считается

доступной

только

стан-

дартное

перемещение вперед: спецификация

операторе

FETCH.

Если

указана спецификация

READ

ONLY

(только

для

чтения),

то

изменения

и об-

новления

исходных

таблиц

не

будут

выполняться

использованием

данного

кур-

сора.

Курсор

данной спецификацией может быть

самым

быстрым

обработке,

однако

если

вы не

укажите специально спецификацию

READ

ONLY,

то

СУБД

бу-

дет

считать,

что вы

допускаете операции модификации

базовыми таблицами,

и в

этом случае

для

обеспечения целостности

БД

СУБД будет гораздо медлен-

нее

обрабатывать ваши операции

курсором.

При

использовании параметра

UPDATE

[OF

<иня

столбца

Е....<иня

столбца

п>]3

мы

задаем перечень

столбцов,

которых допустимы изменения

процессе

на-

шей

работы

курсором. Такое ограничение упростит

ускорит работу СУБД.

Если

этот параметр

не

указан,

то

предполагается,

что

допустимы

изменения

всех

столбцов

курсора.

Вернемся

нашему

примеру.

Если

мы

преследуем цель

мгновенного

слепка

БД»

дающего

сведения

должниках,

то

применим

все

параметры, позволяющие

ускорить

работу

нашим курсором. Тогда оператор описания курсора будет

вы-

глядеть следующим образом;

DECLARE

Debtor_reader_cursor

INSENSITIVE

CURSOR

FOR

SELECT

READERS,FIRSTJAME.

READERS.

LASTJAME.

READERS.ADRES,

READ£RS,HOME_PHON,

READERS.WORK_PHON.

BOOKS.TITLE

FROM

READERS,BOOKS.EXEMPLAR

WHERE

READERS.READERJD

EXEMPLAR.READERJD

AND

BOOKS.ISBN

EXEMPLARE.ISBN

AND

EXEMPLAR.DATAJJUT

GetdateO

ORDER

READERS.FIRSTJAME

FOR

READ ONLY

При

описании

лсурсора

нет

ограничений

на вид

оператора

SELECT»

который

ис-

пользуется

для

создания

базового

набора

строк,

связанного

курсором.

one-

рператоры,_08язанные

многострочными

запросами

255

раторе

SELECT

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

встроенные

подзапросы

вычисляемые поля,

Оператор открытия курсора

Оператор

открытия курсора имеет следующий

синтаксис:

OPEN

<имя_курсора>

[USING

«список

базовых

перененных>]

Именно

оператор

открытия

курсора

инициирует

выполнение

базового

запроса,

соответствующего описанию курсора,

заданному

операторе

DECLARE

...

CURSOR.

При

выполнении

оператора

OPEN

СУБД

производит

семантическую

проверку

курсора,

то

есть выполняет

эгапы

со 2 по 5 в

алгоритме

выполнения

запросов

(рис.

12.1),

поэтому именно здесь СУБД возвращает коды

ошибок

прикладной

программе, сообщающие

ей о

результатах

выполнения

базового запроса,

Ошиб-

ки

могут

возникнуть

результате

неправильного

задания

имен

полей

или

имен

исходных

таблиц

или при

попытке

извлечь

данные

из

таблиц,

которым дан-

ный

пользователь

не

имеет

доступа.

По

стандарту

СУБД

возвращает

код

завершения

операции

специальной

сис-

темной

переменной

SQLCODE.

прикладной

программе пользователь может ана-

лизировать

эту

переменную,

что

необходимд

делать

после

выполнения каждого

оператора SQL.

При

неудачном

выполнении

операции

открытия курсора СУБД

возвращает

отрицательное

значение

SQLCODE.

случае удачного завершения

выполнения

оператора открытия курсора набор

данных,

сформированный

результате

базового

запроса,

остается

доступным

пользователю

до

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

Однако

надо

помнить,

что

СУБД

автоматически

закрывает

все

курсоры

слу-

чае

завершения

транзакции

(COMMIT)

пли

отката

транзакции

(ROLLBACK).

После

того

как

курсор закрыт

его

можно открыть

снова,

но

при

этом соответствующий

запрос выполнится заново. Поэтому

допустимо,

что

содержимое

первого курсо-

ра

будет

ив

соответствовать

его

содержимому

при

повторном

открытии,

потому

что за это

время

изменилось

состояние

БД.

Оператор

чтения очередной строки курсора

После

открытия

указатель

текущей

строки

установлен

перед

первой

строкой

курсора.

Стандартно

оператор

FETCH

перемещает

указатель текущей

строки

на

следующую

строку

присваивает

базовым

переменным

значение

столбцов,

со-

ответствующее

текущей

строке.

Простой

оператор

FETCH

имеет

синтаксис:

FETCH

<иня

курсора>

INTO

«список

переменных

базового

языка

Оператор

извлечения

очередной

строки

из

курсора

будет

выглядеть

следующим

образом:

FETCH

Debtor_reader_cursor

into

SFIRSTJAME.

&LASTJAME.

CADRES.

0HOMEJHON.

@HQRK_PHON.

©TITLE

256

Глава

12,

Встроенный

SQL

Расширенный

оператор

FETCH

имеет следующий синтаксис;

FETCH

[NEXT

PRIOR

FIRST

LAST

ABSOLUTE

<иия_переменной>}

|RELATIVE{n|<иня_перененной>}]

FROM

<иия_курсора>

INTO

<список

базовых

перененных>

Здесь параметр

задает выбор

следующей

строки

после

текущей

из

базового

набора

строк, связанного

курсором. Параметр

PRIOR

задает перемещение

на

пре-

дыдущую строку

по

отношению

текущей.

Параметр

FIRST

задает

перемещение

на

первую

строку

набора,

параметр

LAST

задает

перемещение

на

последнюю

строку

набора.

Кроме

того,

расширенном операторе

перемещения

допустимо

переместиться

сразу

на

заданную строку,

при

этом допустима

как

абсолютная адресация, зада-

нием

параметра

ABSOLUTE,

так и

относительная

адресация,

заданием

параметра

RELATIVE.

При

относительной

адресации

положительное

число

сдвигает указа-

тель вниз

от

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

от текущей

записи.

Однако

для

применения

расширенного

оператора

FETCH

соответствии

со

стан-

дартом

SQL2

описание

курсора обязательно

должно

содержать

ключевое

слово

SCROLL.

Иногда такие курсоры называют

литературе

прокручиваемыми

курсо-

рами.

стандарт

эти

курсоры вошли

сравнительно

недавно,

поэтому

коммер-

ческих

СУБД

очень часто операторы

по

работе

подобными

курсорами

серьезно

отличаются.

Правда, реалии сегодняшнего

дня

заставляют

Поставщиков

ком-

мерческих

СУБД

более

строго соблюдать

последний

стандарт

SQL Б

техниче-

ской

документации можно

встретить

две

версии

синтаксиса

оператора

FETCH;

одну,

которая

соответствует

стандарту,

другую, которая расширяет стандарт допол-

нительными

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

данной

СУБД

для

ра:

боты

курсором.

Если

вы

предполагаете,

что

ваша

БД

может

быть

перенесена

па

другую плат-

форму,

а это

ладо

всегда

предусматривать,

то

лучше пользоваться

стандартны-

ми

возможностями,

этом случае ваше

приложение

будет более

илатформешю-

пезависимым

легче будет

его

перенести

па

другую СУБД.

Оператор

закрытия

курсора

Оператор

закрытия курсора имеет простой

синтаксис,

он

выглядит следующим

образом;

<имя_курсора>

Оператор

закрытия

курсора

закрывает

временную

таблицу,

созданную

опера-

тором открытия

курсора,

прекращает

доступ

прикладной

программы

к этому

объекту.

Единственным

параметром оператора

закрытия

является

имя

курсора.

Операторы,

связанные

многострочными

запросами

257

Оператор

закрытия

может быть

выполнен

любой

момент после оператора

от-

крытия курсора.

некоторых коммерческих СУБД кроме оператора закрытия курсора использу-

ется

еще

оператор

деактивации

(уничтожения)

курсора,

Например,

в MS SQL

Server

7.0

наряду

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

DEALLOCATE

<имялурсора>

Здесь

оператор

закрытия курсора

не

уничтожает набор

данных,

связанный

кур-

сором,

он

только закрывает

нему

доступ

освобождает

все

блокировки,

кото-

рые

ранее

были

связаны

данным

курсором,

При

выполнении

оператора

DEALLOCATE

SQL

Server освобождает

разделяемую

па-

мять,

используемую

командой

описания

курсора

DECLARE,

После

выполнения

этой

команды

невозможно

выполнение

команды

OPEN

для

данного

курсора,

Удаление

обновление

данных

использованием

курсора

Курсоры

прикладных

программах

часто используются

для

последовательного

просмотра

данных.

Если

курсор

не

связан

операцией

группировки,

то

факти-

чески

каждая

строка

курсора

соответствует

строго

только

одной

строке

исход-

ной

таблицы,

этом случае курсор удобно

использовать

для

оперативной

кор-

ректировки

данных.

стандарте

определены

операции

модификации

данных,

связанные

курсором.

Операция

удаления

строки,

связанной

текущим указа-

телем курсора, имеет

синтаксис:

DELETE

FROM

<иня_таблицы>

WHERE

CURRENT

<иня

курсора>

Если

указанный

операторе курсор открыт

установлен

на

некоторую строку,

курсор

определяет

изменяемую

таблицу,

то

текущая строка

курсора

удаляет-

ся, а он

позиционируется

перед

следующей строкой.

Таблица,

указанная

раз-

деле

FROM

оператора

DELETE,

должна быть

таблицей,

указанной

самом

внешнем

разделе

FROM

спецификации

курсора.

Если

нам

необходимо

прочитать

следующую строку

курсора,

то

надо

снова

вы-

полнить

оператор

FETCH NEXT.

Аналогично

курсор может

быть

использован

для

модификации

данных.

Синтак-

сис

операции

позиционной

модификации

UPDATE

<имя_табпииы>

SET

••имя^столбца!^

{<значение>

NULL}

[{,<иня_столйца_Н>-

{<значение>

NULL}},..]

WHERE

CURRENT

-'иня_курсора>

Одним

оператором

позиционного

обновления

могут быть

заменены

несколько

значении

столбцов

строки

таблицы,

соответствующей текущей

позиции

курсо-

ра.

После

выполнения

операции

модификации

позиция

курсора

не

изменяется.

Для

того

чтобы

можно

было

применять

позиционные

операторы

удаления

(DELETE)

модификации

(UPDATE),

курсор должен

удовлетворять

определенным

требова-

ниям.

Согласно

стандарту

SQU,

ото

следующие

требовании:

258

Глава

12.

Встроенный

SQL

Запрос,

связанный

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

данные

из

одной

исходной

таблицы,

то

есть

предложении

FROM

запроса

SELECT,

связанного

определе-

нием

курсора

(DECLARE CURSOR),

должна

быть

задана только одна

таблица.

запросе

не

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

ORDER

BY.

Для

того

чтобы

сохранялось взаимно однозначное соответствие строк курсора

и ис-

ходной

таблицы,

курсор

не

должен идентифицировать

упорядоченный

набор

данных.

запросе

не

должно присутствовать ключевое слово

DISTINCT.

Запрос

не

должен содержать операций

группировки,

то

есть

в нем не

должно

присутствовать предложение

GROUP

BY или

HAVING.

Пользователь,

который хочет

применить

операции позиционного

удаления

или

обновления,

должен

иметь

соответствующие права

на

выполнение дан-

ных

операций

над

базовой таблицей.

(О

правах

привилегиях пользователя

мы

поговорим

главе 13.)

Использование

курсора

для

операций

обновления

значительно усложняет

работу

подобным курсором

со

стороны СУБД, поэтому

операции,

связанные

пози-

ционной

модификацией,

выполняются

гораздо

медленнее,

чем

операции

кур-

сорами,

которые используются только

для

чтения.

Именно

поэтому рекоменду-

ется обязательно указывать

операторе определения курсора предложение

READ

ONLY,

если

вы

не

собираетесь

использовать

данный курсор

для

операций

моди-

фикации.

По

умолчанию,

если

нет

дополнительных

указаний,

СУБД создает

кур-

сор

возможностью

модификации.

Курсоры

—

удобное средство

для

формирования бизнес-логики

приложений,

но

следует

помнить,

что

если

вы

открываете курсор

возможностью

модификации,

то

СУБД блокирует

все

строки базовой таблицы,

вошедшие

в ваш

курсор,

и тем

самым

блокируется

работа других пользователей

данной

таблицей.

Чтобы

свести

минимуму

количество требуемых блокировок,

при

работе интер-

активных

программ

следует

придерживаться следующих правил:

Необходимо

делать

транзакции

как

можно

короче,

Необходимо

выполнять

оператор

завершения

COMMIT

после

каждого запроса

как

можно скорее

после

изменений, сделанных программой.

Необходимо избегать программ,

которых осуществляется

интенсивное

взаи-

модействие

пользователем

или

осуществляется просмотр очень большого

количества

строк данных.

Если

возможно,

то

лучше

не

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

(SCROLL),

потому

что они

требуют

блокирования

всех

строк выборки, связанных

с от-

крытым курсором,

Использование

простого

последовательного

курсора позволит системе раз-

блокировать

текущую строку,

как

только будет выполнена операция

FETCH,

что

минимизирует блокировки

других

пользователей, работающих параллель-

но

вами

использующих

те

лее

таблицы.

Если

возможно,

определяйте курсор

как

READ ONLY.

Хранимыэ

процедуры

259

Однако когда

мы

рассматривали модели

«клиент-сервер»,

применяемые

БД,

тр

одределили,

что в

развитых моделях серверов

баз

данных большая часть

бизнес-логики клиентского

приложения

выполняется

именно

на

сервере,

а не

па

клиенте.

Для

этого используются

специальные

объекты, которые называют-

ся

хранимыми процедурами

хранятся

БД,

как

таблицы,

другие

базовые

объекты,

связи

этим фактом

курсоры,

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

приложе-

ниях, обычно

делятся

на

курсоры

.сервера

курсоры клиента. Курсор

сервера

создается

выполняется

на

сервере, данные,

связанные

ним,

не

пересылаются

на

компьютер клиента. Курсоры сервера определяются обычно

хранимых про-

цедурах

или

триггерах.

Курсоры клиента

— это те

курсоры, которые определяются

прикладных

про^

граммах,

выполняемых

на

клиенте.

Набор

строк,

связанный

данным курсором,

пересылается

на

клиент

и там

обрабатывается. Если

курсором связан боль-

шой

набор

данных,

то

операция пересылки набора строк, связанных

курсором,

может

занять

значительное

время

значительные

ресурсы

сети

клиентского

компьютера,

Конечно,

курсоры сервера более

экономичны

выполняются быстрее. Поэтому

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

использованием

курсоров, будет реко-

мендация

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

как

можно

чаще вместо курсоров клиента

использовать

курсоры сервера.

Хранимые процедуры

точки

зрения

приложений,

работающих

с БД,

хранимые процедуры

(Stored

Procedure)

— это

подпрограммы, которые выполняются

на

сервере.

По

отноше-

нию

к БД - это

объекты,

которые создаются

хранятся

в БД. Они

могут быть

вызваны

из

клиентских приложений.

При

ртом

одна

процедура может быть

ис-

пользована

любом количестве клиентских приложений,

что

позволяет

сущест-

венно сэкономить трудозатраты

на

создание

прикладного

программного обеспе-

чения

эффективно

применять

стратегию повторного использования

кода.

Так

же как и

любые процедуры

стандартных языках

программирования,

хранимые

процедуры могут

иметь

входные

выходные параметры

или не

иметь

их

вовсе.

Хранимые

процедуры

могут

быть

активизированы

не

только

пользовательски-

ми

приложениями,

но

триггерами.

Хранимые

процедуры

пишутся

на

специальном

встроенном языке программи-

рования,

они

могут включать любые операторы SQL,

также включают некото-

рый

набор операторов, управляющих ходом выполнения программ, которые

во

многом

схожи

подобными

операторами

процедурно

ориентированных

языков

программирования.

коммерческих СУБД

для

написания

текстов хранимых

процедур

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

СУБД

Oracle

для

этого

используется

язык

/SQL,

а в MS SQL

Server

Systemll

фирмы

Sybase

используется язык

Transact

SQL.

последних

версиях Oracle

объявлено

использование языка

Java

для

написания хранимых процедур.

260

Глава

12.

Встроенный

SQL

Хранимые процедуры

являются

объектами

БД.

Каждая хранимая

процедура

компилируется

при

первом

выполнении,

процессе компиляции

строится

опти-

мальный

план выполнения процедуры. Описание процедуры совместно

пла-

ном

ее

выполнения хранится

системных

таблицах

БД.

Для

создания

хранимой

процедуры

применяется

оператор

SQL

CREATE PROCEDURE.

По

умолчанию

выполнить

хранимую процедуру может только

се

владелец,

ко-

торым

является владелец

БД, и

создатель хранимой

процедуры.

Однако

владе-

лец

хранимой

процедуры может делегировать права

на ее

запуск другим

пользо-

вателям.

Имя

хранимой процедуры

является

идентификатором

языке

программирова-

ния,

на

котором

она

пишется,

должно удовлетворять всем требованиям,

кото-

рые

предъявляются

идентификаторам

данном

языке.

MS SQL

Server

хранимая процедура создается оператором:

CREATE

PROCEDURE]

<иня„процедуры>

[;<версия>]

[{@параметр1

тип_данных}

[VARYING]

<значение_по_з'нолчанию>]

[OUTPUT]]

[..параметр!!.]

WITH

{

RECOMPILE

ENCRYPTION

RECOMPILE.

ENCRYPTION}]

[FOR

REPLICATION]

Тело

процедуры

Здесь необязательное ключевое слово

VARYING

определяет

заданное

значение

по

умолчанию

для

определенного

ранее

параметра.

Ключевое

слово

RECOMPILE

определяет режим

компиляции

создаваемой

храни-

мой

процедуры. Если задано ключевое слово

RECOMPILE,

то

процедура будет

пере-

компилироваться

каждый раз, когда

она

будет вызываться

на

исполнение.

Это

может

резко замедлить

исполнение

процедуры.

Но, с

другой

стороны,

если

дан-

ные,

обрабатываемые

данной

хранимой

процедурой,

настолько

динамичны,

что

план

исполнения,

составленный

при ее

первом вызове,

может

быть

абсолютно

неэффективен

при

последующих вызовах,

то

стоит

применять

дан-

ный

параметр

при

создании

этой

процедуры.

Ключевое

слово

ENCRYPTION

определяет режим,

при

котором

исходный

текст

хра-

нимой

процедуры

не

сохраняется

в БД.

Такой режим

применяется

для

того,

чтобы

сохранить

авторское право

на

интеллектуальную

продукцию,

которон

являются

хранимые

процедуры. Часто такой

режим

применяется,

когда

вы

ста-

вите готовую

базу

заказчику

не

хотите, чтобы

исходные

тексты

разработан-

ных

вами

хранимых

процедур были

бы

доступны

администратору

БД,

работаю-

щему

заказчика. Однако

надо

помнить,

что

если

захотите

отредактировать

текст хранимой процедуры сами,

то вы его

не

сможете

извлечь

из

БД

тоже,

его