1520

Глава 23

Итак, имеются три пользователя, у каждого из которых собственная пара таблиц EMP/DEPT. Данные же в этих таблицах существенно отличаются. У пользователя SCOTT - обычный набор данных ЕМР, у пользователя TKYTE данных в два раза больше, а у пользователя APPLICATION эти таблицы пусты. Теперь создадим приложение:

application@TKYTE816> create or replace procedure emp dept rpt

2 AUTHID GURRENT USER

3 as

4 begin

5 dbmsoutput.putline(Зарплаты и количество сотрудников по -> отделам) ;

6 dbmsoutput.putline(chr(9)Отдел Зарплата Количество);

7 dbmsoutput.putline(chr (9) -) ;

8 for x in (select dept.deptno, sum(sal) sal, count(*) cnt

9 from emp, dept

10 where dept.deptno = emp.deptno

11 group by dept.deptno)

12 loop

13 dbms output.put line(chr(9)

14 to char(x.deptno,99999)

15 to char(x.sal,99,999)

16 to char(x.cnt,99,999));

17 end loop;

18 dbms output.put line(==================) ;

19 end;

20 /

Procedure created.

application@TKYTE816> grant execute on emp dept rpt to public 2 /

Grant succeeded.

application@TKYTE816> set serveroutput on format wrapped application@TKYTE816> exec emp dept rpt; Зарплаты и количество сотрудников по отделам Отдел Зарплата Количество

PL/SQL procedure successfully completed.

Когда процедуру выполняет пользователь APPLICATION таблицы пусты, как и ожидалось. При выполнении же этого приложения пользователями SCOTT и TKYTE:

tkyte@TKYTE816> connect scott/tiger

scott@TKYTE816> set serveroutput on format wrapped scott@TKYTE816> exec application.ernp dept rpt Зарплаты и количество сотрудников по отделам Отдел Зарплата Количество

Права вызывающего и создателя

1521

PL/SQL procedure successfully completed.

scott@TKYTE816> connect tkyte/tkyte tkyte@TKYTE816> set serveroutput on format wrapped

tkyte@TKYTE816> exec application.emp dept rpt Зарплаты и количество сотрудников по отделам Отдел Зарплата Количество

10 17,500 6

20 21,750 10

30 18,800 12

PL/SQL procedure successfully completed.

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

Когда использовать права создателя

Работа с правами создателя продолжает оставаться доминирующим методом использования скомпилированных хранимых объектов. Для этого имеются две основные при-чин1.

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

Защита. Процедуры с правами создателя имеют такие особенности с точки зрения защиты, которые делают их применение единственно верным выбором почти во всех случаях.

Производительность и масштабируемость

Процедура, работающая с правами создателя, - замечательная вещь с точки зрения защиты и производительности. В разделе Как работают процедуры с правами вызывающего будет показано, что, благодаря статическому связыванию на этапе компиляции, можно существенно повысить эффективность во время выполнения. Все проверки защиты, зависимостей и т.п. выполняются один раз, при компиляции. Для процедуры, работающей с правами вызывающего, большая часть этих действий будет делаться во время выполнения. Более того, может потребоваться многократно выполнять эти действия в одном сеансе, после выполнения оператора ALTER SESSION или SET ROLE. Любое изменение среды выполнения приводит к изменению поведения процедуры с правами вызывающего. Процедура же с правами создателя от этих изменений не зависит.

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

1522

Глава 23

логичная процедура, работающая с правами создателя. Поскольку среда выполнения для процедуры с правами создателя статична, все выполняемые ею статические SQL-опера-торы могут совместно использоваться в разделяемом пуле. Как было показано в других главах этой книги, необходимо заботиться о правильном использовании разделяемого пула (использовать связываемые переменные, избегать излишних разборов и т.д.). Использование процедур с правами создателя гарантирует максимально эффективное использование разделяемого пула. Процедуры же с правами вызывающего могут приводить к неэффективному использованию разделяемого пула. Вместо того чтобы один запрос, SELECT * FROM T, при использовании в процедуре означал бы одно и то же для всех пользователей, он может иметь для пользователей разный смысл. В разделяемом пуле будет больше различных SQL-операторов. Использование прав создателя обеспечивает более эффективное использование разделяемого пула.

Защита

Используя права создателя, можно создать процедуру, безопасно и корректно обрабатывающую определенный набор объектов базы данных. Затем можно предоставить другим пользователям возможность выполнять эту процедуру с помощью оператора GRANT EXECUTE ON <процедура> ТО <пользователь>/риЫ1с/<роль>. Эти пользователи смогут запускать процедуру для чтения/записи таблиц (способом, предусмотренным в коде этой процедуры), но никаким другим способом читать или записывать данные в наши таблицы они не могут. Другими словами, мы только что создали надежн1й процесс изменения или чтения объектов безопасным образом и теперь можем предоставлять пользователям право на это, не опасаясь, что они смогут каким-либо другим способом прочитать или изменить эти объекты. Они не смогут вставлять записи в таблицу сотрудников с помощью утилиты SQL*Plus. Это можно будет делать только с помощью хранимой процедуры, реализующей все необходимые проверки. Этот способ работы существенно влияет на разработку приложения и предоставление прав на использование ваших данных. Больше не придется выполнять операторы GRANT INSERT таблицы, как это делалось для клиент-серверного приложения, непосредственно в1пол-няющего SQL-операторы INSERT. Вместо этого придется выполнить оператор GRA EXECUTE для процедуры, которая может проверять и оценивать данные и их защищенность. Беспокоиться о целостности данных при этом тоже больше не нужно (процедура точно задает, что и как необходимо делать, а других способов работы с данными просто нет).

Сравните это с работой типичных клиент-серверных и даже многих З-уровневых приложений. В клиент-серверном приложении операторы INSERT, UPDATE, DELETE и т.п. включены непосредственно в код клиентского приложения. Для работы этого приложения, пользователю необходимо предоставить привилегии INSERT, UPDATE и DELETE непосредственно для базовых таблиц. Теперь весь мир имеет доступ к базовым таблицам через любой интерфейс, способный взаимодействовать с СУБД Oracle. При использовании процедуры с правами создателя такой проблемы нет. Единственн1й способ изменения таблиц - с помощью надежной процедуры, которой вполне можно доверять. Это очень важное свойство.