Лекция 12: Служебные виды объектов. Работа с редакциями объектов

Настройка на работу с нужной редакцией

Чтобы пользователь Oracle имел право в конкретном сеансе работать с конкретной редакцией:

• он должен иметь привилегию на работу с редакцией, выданную лично ему или, вместо этого, псевдопользователю PUBLIC (то есть всем вообще);
• сеанс должен быть переключен на работу с этой редакцией.

Выдать пользователю личное общее разрешение на работу с объектами требуемой редакции можно примерно так:

GRANT USE ON EDITION app_release_1 TO scott;

USE — это привилегия на объекты вида EDITION, передаваемая к тому же через PUBLIC и через роли. Если редакцию объявить в БД умолчательной, она автоматически полагается выданной для PUBLIC, то есть общедоступной, и не требует личных (или же ролевых) разрешений. По этой причине изначально частных разрешений на работу с ORA$BASE не требуется — оно есть у всех. То же самое произойдет с редакцией APP_RELEASE_1, если в какой-то момент выдать:

ALTER DATABASE DEFAULT EDITION = app_release_1;

На последнюю команду способен обладатель привилегии ALTER DATABASE (а ею обладают SYS и SYSTCODE, но пока что не YARD). Как только такая команда будет выдана, команды GRANT USE, как выше, для придания нужных полномочий пользователю SCOTT не потребуется. Выдачей подобной команды может венчаться отладка новых редакций объектов ("перевод приложения на новую редакцию").

Когда пользователь Oracle получил разрешение (то есть привилегию) на работу с объектами конкретной редакции, он получает право в рамках отдельных сеансов настраиваться на нее:

SQL> CONNECT scott/tiger
Connected.
SQL> SELECT SYS_CONTEXT ( 'USERENV', 'CURRENT_EDITION_NAME' ) FROM dual;
SYS_CONTEXT('USERENV','CURRENT_EDITION_NAME')
--------------------------------------------------------------------
ORA$BASE
SQL> ALTER SESSION SET EDITION = app_release_1;
Session altered.
SQL> SELECT SYS_CONTEXT ( 'USERENV', 'CURRENT_EDITION_NAME' ) FROM dual;
SYS_CONTEXT('USERENV','CURRENT_EDITION_NAME')
--------------------------------------------------------------------
APP_RELEASE_1

Код выше подтверждает то, что по умолчанию при открытии сеанса действует редакция, объявленая ранее умолчательной в БД.

Пример создания и использования разных редакций представления данных (view)

К настоящему моменту в БД имеется две редакции. Будем формировать их содержание редакциями объектов в схеме YARD. Создадим в ней две несложные редакции одного и того же представления данных — с выдачей сведений об отделе сотрудника и без:

CONNECT yard/pass
ALTER SESSION SET EDITION = ora$base;
CREATE OR REPLACE EDITIONING VIEW codepl
  AS
  SELECT codepno, ename, deptno FROM codep
;
ALTER SESSION SET EDITION = app_release_1;
CREATE OR REPLACE EDITIONING VIEW codepl
  AS
  SELECT codepno, ename FROM codep
;

Настройку на редакцию ORA$BASE можно было выше не выполнять, потому что эта редакция умолчательная (это проверялось ранее) и автоматически действует в начале каждого сеанса.

В результате появились две редакции представления данных CODEPL:

SQL> SELECT view_name, edition_name FROM user_editioning_views_ae;
VIEW_NAME                      EDITION_NAME
------------------------------ ------------------------------
CODEPL                           ORA$BASE
CODEPL                           APP_RELEASE_1

Редактируемые представления данных (editioning views) отличаются от обычных не только формальным словом EDITIONING при создании, но и некоторыми техническими свойствами. Они могут строиться на основе единственной таблицы, без фильтрации строк фразой WHERE и с отсутствием преобразований столбцов (в то же время воспроизведение всех столбцов не обязательно). Есть и другие отличия, не востребованные тематикой этого текста.

Чтобы пользователь SCOTT имел доступ к данным, для каждой редакции требуется выдать отдельное разрешение:

ALTER SESSION SET EDITION = ora$base;
GRANT SELECT ON codepl TO scott;
ALTER SESSION SET EDITION = app_release_1;
GRANT SELECT ON codepl TO scott;
Вот как этими разрешениями может воспользоваться SCOTT:
SQL> CONNECT scott/tiger
Connected.
SQL> ALTER SESSION SET EDITION = ora$base;
Session altered.
SQL> SELECT * FROM yard.codepl WHERE ROWNUM = 1;
     CODEPNO ENAME          DEPTNO
---------- ---------- ----------
      7369 SMITH              20
SQL> ALTER SESSION SET EDITION = app_release_1;
Session altered.
SQL> SELECT * FROM yard.codepl WHERE ROWNUM = 1;
     CODEPNO ENAME
---------- ----------
      7369 SMITH

Теперь без отмены прежнего представления данных (которым может пользоваться текущее приложение) открылась возможность отлаживать приложение применительно к новому.

Упражнение. Отберите у пользователя SCOTT привилегию на выборку данных из YARD.CODEPL в редакции APP_RELEASE_1 и наблюдайте результат попытки обращения.

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

Хотя техника редакций объектов хранения не распространяется на данные в исходных таблицах БД, версии представлений иногда помогают подготовить приложение в том числе к переходу на новые структуры таблиц. Фирма Oracle в своей документации приводит пример подобного употребления редакций. Идея этого примера излагается ниже.

Пусть требуется изменить структуру таблицы CODEP, например, добавить новый столбец. Это может быть вызвано желанием заменить столбец ENAME на два столбца: отдельно для имени сотрудника и отдельно для фамилии. Загодя отладить имеющееся приложение для новой структуры можно следующим образом.

Во-первых, создать на основе таблицы представление, воспроизводящее полностью данные таблицы. Командами RENAME подменить имя таблицы на искусственное, а старое CODEP передать представлению. Приложение от такой подмены не пострадает.

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

Далее, добавить в таблицу новый столбец таким образом, чтобы представление продолжало предъявлять старые данные.

Создать новую редакцию представления, учитывающую новый столбец в таблице.

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