Это не определяет разницу между владельцем и схемой.
Но я всегда боролся с идеей, что я создаю N пользователей ... когда я хочу, чтобы каждый из этих пользователей "потреблял""(иначе, используйте) одну схему.
Этот парень показывает, как это сделать (иметь N пользователей) ... перенаправить на одну схему.
Я вставлюего код также, по случайному совпадению, URL-ссылка исчезнет в будущем.
http://www.oracle -base.com / article / misc / schema-owners-and-application-users.php
У него есть второй подход "синонима". Но я только вставляю версию CURRENT_SCHEMA. ОПЯТЬ, Я не беру на себя ответственность за это. Я просто ненавижу, когда кто-то говорит "Ваш ответ по этой ссылке"и BOOM, ссылка не работает.: <</p>
......................................................
(из http://www.oracle -base.com / статьи / разное / владельцы схем и приложения-users.php )
CURRENT_SCHEMA подход
Этот метод использует CURRENT_SCHEMAАтрибут сеанса для автоматического указания пользователям приложения на правильную схему.
Сначала мы создаем владельца схемы и пользователя приложения.
CONN sys/password AS SYSDBA
-- Remove existing users and roles with the same names.
DROP USER schema_owner CASCADE;
DROP USER app_user CASCADE;
DROP ROLE schema_rw_role;
DROP ROLE schema_ro_role;
-- Schema owner.
CREATE USER schema_owner IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp
QUOTA UNLIMITED ON users;
GRANT CONNECT, CREATE TABLE TO schema_owner;
-- Application user.
CREATE USER app_user IDENTIFIED BY password
DEFAULT TABLESPACE users
TEMPORARY TABLESPACE temp;
GRANT CONNECT TO app_user;
Обратите внимание, что пользователь приложения может подключиться, но не можетиметь какие-либо квоты или привилегии табличного пространства для создания объектов.
Далее мы создадим некоторые роли, разрешающие доступ на чтение и запись и доступ только для чтения.
CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;
Мы хотим, чтобы пользователь нашего приложения читал-записать доступ к объектам схемы, поэтому мы предоставляем соответствующую роль.
GRANT schema_rw_role TO app_user;
Нам нужно убедиться, что у пользователя приложения есть схема по умолчанию, указывающая на владельца схемы, поэтому мы создаем триггер AFTER LOGON длясделайте это для нас.
CREATE OR REPLACE TRIGGER app_user.after_logon_trg
AFTER LOGON ON app_user.SCHEMA
BEGIN
DBMS_APPLICATION_INFO.set_module(USER, 'Initialized');
EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER';
END;
/
Теперь мы готовы создать объект в владельце схемы.
CONN schema_owner/password
CREATE TABLE test_tab (
id NUMBER,
description VARCHAR2(50),
CONSTRAINT test_tab_pk PRIMARY KEY (id)
);
GRANT SELECT ON test_tab TO schema_ro_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON test_tab TO schema_rw_role;
Обратите внимание, как привилегии предоставляются соответствующим ролям.Без этого объекты не были бы видны пользователю приложения.Теперь у нас есть работающий владелец схемы и пользователь приложения.
SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
Name Null? Type
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
DESCRIPTION VARCHAR2(50)
SQL>
Этот метод идеален, когда пользователь приложения является просто альтернативной точкой входа в основную схему, не требующей собственных объектов.