14. Динамічний і статичний sql

1. DBMS_SQL

2. EXECUTE IMMEDIATE

Многие задачи требуют использования динамического SQL в PL/SQL. Вот лишь некоторые из них.

1. Разработка обобщенных процедур, выполняющих стандартные действия вроде выгрузки данных в файлы.

2. Разработка универсальных процедур загрузки данных в неизвестные заранее таблицы. Мы рассмотрим использование динамического SQL для загрузки данных в таблицу.

3. Динамический вызов других PL/SQL-процедур во время выполнения.

4. Генерация условий (например, конструкции WHERE) в процессе работы на основе введенных пользователем данных. Это, пожалуй, основная причина использования динамического SQL большинством разработчиков.

5. Выполнение операторов ЯОД. Поскольку PL/SQL не разрешает включать статические операторы ЯОД в код приложения, остается использовать динамический SQL. Это позволит выполнять операторы, начинающиеся с ключевых слов CREATE, ALTER, GRANT, DROP и т.п.

Решаться перечисленные задачи будут с помощью двух средств языка PL/SQL:

• с использованием стандартного пакета DBMS_SQL. Этот пакет существует уже достаточно давно, он появился в версии 7.1. Пакет обеспечивает процедурный метод выполнения динамического SQL, аналогичный использованию функциональных интерфейсов (таких как JDBC или ODBC);

• с использованием встроенного динамического SQL (который реализуется в PL/SQL оператором EXECUTE IMMEDIATE). Это декларативный способ выполнения динамического SQL в языке PL/SQL и в большинстве случаев он синтаксически намного проще, чем использование пакета DBMS_SQL; кроме того, он обеспечивает более высокую производительность.

В лабораторной работе необходимо сравнить два метода и сформулировать, когда имеет смысл использовать каждый из них. Как только стало понятно, что необходимо использовать динамический SQL (статический SQL – лучший выбор в большинстве случаев), придется выбирать реализацию на основе пакета DBMS_SQL или встроенного динамического SQL.

Пакет DBMS_SQL необходимо использовать в следующих случаях.

1. Если заранее не известно количество или типы столбцов, с которыми придется работать. Пакет DBMS_SQL включает процедуры для описания результирующего множества. Встроенный динамический SQL не позволяет получить такое описание. При использовании встроенного динамического SQL необходимо знать ха­рактеристики результирующего множества при компиляции, если результаты необходимо обрабатывать в PL/SQL.

2. Если заранее неизвестно количество или типы связываемых переменных, с которыми придется работать. Пакет DBMS_SQL по ходу выполнения позволяет привязать с помощью процедур входные переменные к операторам. Встроенный динамический SQL требует учета количества и типов связываемых переменных на этапе компиляции.

3. Когда необходимо выбирать или вставлять тысячи строк и можно использовать обработку массивов. Пакет DBMS_SQL поддерживает обработку массивов – возможность выбрать N строк за раз, одним вызовом. Встроенный динамический SQL обычно не позволяет этого сделать, но это ограничение можно обойти, как будет показано далее.

4. Если в сеансе многократно выполняется один и тот же оператор. Пакет DBMS_SQL позволяет один раз разобрать оператор, а затем выполнять его многократно. При использовании встроенного динамического SQL мягкий разбор будет осуществляться при каждом выполнении. Такие дополнительные повторные разборы нежелательны.

Встроенный динамический SQL имеет смысл использовать в следующих случаях.

1. Когда количество и типы столбцов, с которыми придется работать, заранее изве­стны.

2. Когда заранее известно количество и типы связываемых переменных (можно также использовать контексты приложений, чтобы с помощью более простого встро­енного динамического SQL выполнять операторы с заранее неизвестным коли­чеством или типами связываемых переменных).

3. Когда необходимо выполнять операторы ЯОД.

4. Если динамически формируемые операторы будут выполняться лишь несколько раз (оптимальный вариант – однократно).

Роль пакета DBMS_SQL

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

За работу с динамическими SQL-запросами отвечает пакет DBMS_SQL. В общем, работа с ним происходит по следующей схеме.

1. Строится сам текст запроса с метками для параметров. Текст запроса может быть представлен в виде строки или коллекции строк.

2. Функцией DBMS_SQL.Open_Cursor выделяется идентификатор курсора, который будет использоваться для работы с запросом. Идентификатор ссылается на внутреннюю структуру Oracle, определяющую курсор. Этот идентификатор используется процедурами пакета DBMS_SQL.

3. Выполняется разбор текста запроса DBMS_SQL.Parse.

4.Устанавливаются значения параметров запроса DBMS_SQL.Bind_Variable.

5. Если запрос возвращает данные, то определяются столбцы и буферные переменные, в которых будут размещаться возвращаемые данные. DBMS_SQL.Define_Column.

6. Запрос выполняется. DBMS_SQL.Execute.

7. Если запрос возвращает данные, то производится выборка данных из курсора и необходимая их обработка. DBMS_SQL.Fetch_Rows, DBMS_SQL.Column_Value.

8. Курсор закрывается. DBMS_SQL.Close_Cursor.

Встроенный динамический SQL

Встроенный динамический SQL впервые появился в Oracle 8i. Он позволяет декларативно выполнять динамический SQL в среде PL/SQL. Большинство действий можно выполнить с помощью одного оператора, EXECUTE IMMEDIATE, а остальные – с помощью оператора OPEN FOR. Оператор EXECUTE IMMEDIATE имеет следующий син­таксис

EXECUTE IММEDIATE 'оператор'

[INTO {переменная1[, переменная2, ... переменнаяК ] | запись}]

[USING [IN | ОUТ | IN OUT] связываемая_переменная1, ...связываемая_ переменная N]

[{RETURNING | RETURN} INTO результат1 [, ..., результатN]...] ;

где:

– оператор – любой оператор SQL или PL/SQL-блок;

– переменная1, переменная2, ... пepeмeннaяN или запись — переменные PL/SQL, в которые необходимо выбрать данные (столбцы одной строки результатов оператора SELECT);

– связываемая_переменная1,... cвязывaeмaя_пepeмeннaяN – набор переменных PL/ SQL, используемых для передачи входных данных/результатов;

– результат1, ... peзультат N — набор PL/SQL-переменных, используемых для раз­мещения результатов, возвращаемых конструкцией RETURN оператора ЯМД.

Примеры:

CREATE OR REPLACE PROCEDURE

(p_DISC IN VARCHAR2) IS

V_CUR NUMBER ;

V_CR VARCHAR2(100);

Begin

V_Cur:=DBMS_SQL.OPEN.CURSOR

V_Cr:= ’CREATE TABLE temp_table’

DBMS_SQL, PARSE (V_Cur, V_Cr, DBMS_SQL.V7)

DBMS_SQL.CLOSE_CURSOR (V_Cur);

END;

Пример команды DML

CREATE OR REPLACE PROCEDURE UPT (P_DEPT IN class.dept%TYPE, p_cr IN class.num.cr% TYPE,

p.RowsUp OUT INTEGER) IS

V_Cur INTEGER;

V_Up VARCHAR2(100);

Begin

V_Cur = DBMS_SQL.OPEN_CURSOR;

V_C = ‘UPDATE class

SET num.cr = nc

WHERE dept = dept’

DBMS_SQL.PARSE (V.Cur, V.Up, DBMS_SQL.V7);

DBMS_SQL.BIND_VARIABLE

(V_Cur, ‘:nc’, p.cr);

DBMS_SQL.BIND.VARIABLE (V.Cur, ‘:dept, p.DEPT’)

p_RowsUp = DBMS_SQL.EXECUTE (V_Cur)

DBMS.SQL.CLOSE.CURSOR (V_Cur);

END;

15. Основні концепції об’єктно-орієнтованого підхода+16. ООСУБД. Преимущества и недостатки

Несмотря на то, что объектные базы существуют более десятка лет, это направление в СУБД считается новым и ставит перед исследователями множество теоретических проблем. Ключевой, конечно же, теория объектной модели данных. И даже не столько теория, сколько приемлемый по сложности математический аппарат для работы с объектами. Ведь почему реляционные обрели такую популярность? Оттого, что реляционная модель интуитивно понятна, а ее математическое описание довольно несложно. Есть сомнения относительно существования такой теории.

В отсутствие общепринятой модели черезвычайную важность проибретает значение стандартов. Несмотря на усилия группы ODMG, унификация интерфейсов объектный баз различных производителей явно недостаточна. Аналогичные стандарты в мире реляционных баз хотя не идеальны, но намного более строги.

Несмотря на указанные трудности направление объектных баз интенсивно развивается и имеет хорошие перспективы как в виде технологии так и в виде коммерческих продуктов на рынке.

Преимущества ОО СУБД:

- расширяемость

- устранение проблем несоответствия

- более выразительный язык запросов

- поддержка долговременных транзакций

- повышенная производительность

Недостатки ОО СУБД

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

17. Об’єктні бази даних і стандарт ODMG

Объектно-ориентированная (объектная) СУБД — система управления базами данных, основанная на объектной модели данных.

Эта система управления обрабатывает данные как абстрактные объекты, наделённые свойствами, в виде неструктурированных данных, и использующие методы взаимодействия с другими объектами окружающего мира.

Объектно-ориентированная база данных (ООБД) — база данных, в которой данные моделируются в виде объектов, их атрибутов, методов и классов. Обычно рекомендованы для тех случаев, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру.

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

Некоторые объектно-ориентированные базы данных разработаны для плотного взаимодействия с такими объектно-ориентированными языками программирования как Python, Java, C#, .NET, C++, другие имеют свои собственные языки программирования. ООСУБД используют точно такую же модель, что и объектно-ориентированные языки программирования.

СУБД должна обеспечивать:

1. Долговременное хранение

2. Использование внешней памяти

3. Параллелизм

4. Восстановление

5. Нерегламентированные запросы

Преимущества:

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

2. Данные в реальном мире обычно имеют иерархические характеристики.

3. Для доступа к данным из ООСУБД не обязателен отдельный язык запросов, поскольку доступ происходит непосредственно к объектам.

4. В типичном приложении, построенном на использовании объектно-ориентированного языка и СУРБД, значительное количество времени обычно тратится на взаимосвязывание таблиц и объектов

Недостатки:

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

2. ООСУБД обычно привязана к отдельному языку с помощью отдельного АПИ и данные доступны только через этот АПИ. СУРБД в этом плане имеет большие возможности, благодаря общему языку запросов.

Архитектура ODMG

Предлагаемая ODMG архитектура показана на рис. 2.1. В этой архитектуре определяются способ хранения данных и разные виды пользовательского доступа к этому “хранилищу данных”¹⁷. Единое хранилище данных доступно из языка определения данных, языка запросов и ряда языков манипулирования данными.¹⁸ На рис. 2.1 ODL означает Object Definition Language (язык определения объектов), OQL –Object Query Language (язык объектных запросов) и OML – Object Manipulation Language (язык манипулирования объектами).

Архитектура ODMG

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

Основными компонентами архитектуры являются следующие.

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

- Язык определения данных (ODL ). 

Схемы баз данных описываются в терминах языка ODL , в котором конструкции модели данных конкретизируются в форме языка определения. ODL позволяет описывать схему в виде набора интерфейсов объектных типов, что включает описание свойств типов и взаимосвязей между ними, а также имен операций и их параметров. ODL не является полным языком программирования; реализация типов должна быть выполнена на одном из языков категории OML . Кроме того, ODL является виртуальным языком в том смысле, что в стандарте ODMG не требуется его реализация в программных продуктах ООСУБД, которые считаются соответствующими стандарту. Допускается поддержка этими продуктами эквивалентных языков определения, включающих все возможности ODL , но адаптированных под особенности конкретной системы. Тем не менее, наличие спецификации языка ODL в стандарте ODMG является важным, поскольку в языке конкретизируются свойства модели данных.

- Язык объектных запросов (ODL ). Язык имеет синтаксис, похожий на синтаксис языка SQL, но опирается на семантику объектной модели ODMG . В стандарте допускается прямое использование OQL и его встраивание в один из языков категории OML .

- Языки манипулирования объектами (OML ). Для программирования реализаций операций и приложений требуется наличия объектно-ориентированного языка программирования. OML представляется собой интегрирование языка программирования с моделью ODMG ; это интегрирование производится за счет определенных в стандарте правил языкового связывания (language binding ). Дело в том, что в самих языках программирования, естественно, не поддерживается стабильность объектов. Чтобы разрешить программам на этих языках обращаться к хранимым данным, языки должны быть расширены дополнительными конструкциями или библиотечными элементами. Эту возможность и обеспечивает языковое связывание.

- В одной ООСУБД могут поддерживаться несколько OML . В стандарте ODMG -2 были специфицированы правила связывания для языков C ++ и Smalltalk ¹⁹. Практически завершена работа над спецификаций правил связывания для языка Java.

- Постоянноехранилище объектов. Логическая организация хранилища данных любой ООСУБД, совместимой со стандартном ODMG , должна основываться на модели данных ODMG . Физическая организация у разных ООСУБД может различаться, но в любом случае она должна обеспечивать эффективные структуры данных для хранения иерархии типов и объектов, являющихся экземплярами этих типов. Иерархия типов связана не только с данными, но и с различными библиотеками и компонентами инструментальных средств, поддерживающими разработку приложений. Так что в ООСУБД, совместимой со стандартом ODMG , хранилище представляет собой интегрированную систему, где согласованным образом сохраняются данные и программный код.

- Инструментальные средства и библиотеки. Инструментальные средства, поддерживающие, например, разработку пользовательских приложений и их графических интерфейсов, программируются на одном из OML и сохраняются как часть иерархии классов. Библиотеки функций доступа, арифметических функций и т.д. также сохраняются в иерархии типов и являются единообразно доступными из программного кода разработчика приложения. Ассортимент инструментальных средств и библиотек в стандарте не определяется.