18.Основные понятия и конструкции pl/sql. Курсоры, хранимые процедуры, функции пользователя, триггеры.

PL/SQL - это процедурный блочно-структурированный язык. Он представляет собой расширение языка SQL и предназначен для работы с СУБД Oracle. PL/SQL предоставляет разработчику приложений и интерактивному пользователю следующие основные возможности:

• реализация подпрограмм как отдельных блоков, в том числе использование вложенных блоков;

• создание пакетов, процедур и функций, хранимых в базе данных;

• предоставление интерфейса для вызова внешних процедур;

• поддержка как типов данных SQL, так и типов, вводимых в PL/SQL;

• применение явного и неявного курсора, а также оператора цикла FOR для курсора;

• введение у переменных PL/SQL и курсоров атрибутов, которые позволяют ссылаться на тип данных или структуру элемента;

• введение типов коллекций и объектных типов;

• поддержка набора операторов управления и операторов цикла;

• реализация механизма обработки исключений.

Основной программной единицей PL/SQL является блок, который может содержать вложенные блоки, называемые иногда подблоками.

Блок позволяет объединять объявления и операторы, связанные общей логикой; может быть анонимным и именованным.

Блок состоит из трех основных частей:

• секция объявлений (необязательная часть);

• тело блока;

• обработчики исключений (необязательная часть).

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

Любой оператор языка PL/SQL, используемый для управления ходом выполнения программы, может относиться к одной из следующих групп операторов:

• операторы выбора:

IF-THEN-END IF;

IF-THEN-ELSE-END IF;

IF-THEN-ELSIF-END IF;

• операторы цикла:

LOOP-END LOOP;

WHILE-LOOP-END LOOP;

FOR-LOOP-END LOOP;

EXIT;

EXIT WHEN;

• операторы безусловного перехода:

GOTO;

NULL;

Курсор SQL — это область памяти базы данных, где был сохранен последний из операторов SQL Если текущим оператором SQL оказывается запрос, в памяти сохраняется также и строка запроса – текущим значением курсора или текущей строкой Соответствующая область памяти именуется и оказывается доступной программам

DECLARE CURSOR ИМЯ_ КУРСОРА

IS {ОПЕРАТОР_SELECT}

При закрытии курсора в Oracle занимаемые им ресурсы освобождаются автоматически без использования оператора DEALLOCATE. Синтаксис оператора закрытия курсора в Oracle следующий. CLOSE ИМЯ_КУРСОРА

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

CREATE [ OR REPLACE ] PROCEDURE ИМЯ__ПРОЦЕДУРЫ [ (АРГУМЕНТ [{IN | OUT | IN OUT) ] ТИП, АРГУМЕНТ [{IN 1 OUT | IN OUT} ] ТИП] ] {IS I AS)

ТЕЛО_ПРОЦЕДУРЫ

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

• Операторы сохраненной процедуры уже сохранены в базе данных.

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

• Возможность сохранения процедур позволяет использовать модульное программирование.

• Сохраненные процедуры могут вызывать другие процедуры и функции.

• Сохраненные процедуры могут вызываться другими программами.

• При использовании сохраненных процедур результат ответ от базы данных обычно получается быстрее.

• Использовать процедуры очень просто.

Триггер — это откомпилированная процедура, используемая для выполнения действий, инициируемых происходящими в базе данных событиями Триггер представляет собой сохраненную в базе данных процедуру, которая выполняется тогда, когда в отношении таблицы выполняются определенные действия (операторы языка манипуляции данными — DML). Триггер может выполняться до или после операторов INSERT, DELETE или UPDATE. Триггер можно создать с помощью оператора CREATE TRIGGER.

Тело триггера изменить нельзя Для этого триггер придется либо заменить другим, либо воссоздать В некоторых реализациях SQL триггер можно заменить (если триггер с данным именем в системе уже существует) с помощью того же оператора CREATE TRIGGER.

CREATE [ OR REPLACE ] TRIGGER ИМЯ_ТРИГГЕРА

[ BEFORE | AFTER]

<...>

Триггер можно удалить с помощью оператора DROP TRIGGER. Синтаксис этого оператора следующий.

DROP TRIGGER ИМЯ_ТРИГГЕPA.

/*ПРИЛОЖЕНИЕ*/

Для того, чтобы более определенно сформулировать цель, к которой разработчикам нужно стремится, Е.Кодд опубликовал 12 правил соответствия реляционной модели, которые опираются на основное правило:

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

Конкретные требования к реляционной СУБД раскрываются в следующих правилах:

1. Информационное правило. Вся информация, хранимая в базе данных, должна быть представлена единственным образом: в виде значений в реляционных таблицах.

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

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

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

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

• определение данных

• определение правил целостности

• манипулирование данными (в диалоге и из программы)

• определение таблиц-представлений (в том числе и возможности их модификации)

• определение правил авторизации

• границы транзакций

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

7. Правило множественности операций. Возможность оперирования базовыми таблицами или таблицами-представлениями распространяется полностью не только на выдачу информации из БД, но и на вставку, модификацию и удаление данных.

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

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

10. Правило сохранения целостности. Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД, задаваемых языком работы с данными и хранимых в системном каталоге.

11. Правило независимости от распределенности. Диалоговые операторы и прикладные программы на логическом уровне не должны зависеть от совершаемого физического разнесения данных (если первоначально СУБД работала с нераспределенными данными) или перераспределения (если СУБД распределенная).

12. Правило ненарушения реляционного языка. Если в реляционной СУБД имеется язык низкого уровня (для работы с отдельными строками), он не должен позволять нарушать или "обходить" правила, сформулированные на языке высокого уровня (множественном) и занесенные в системный каталог.