Этот ответ не определяет разницу между владельцем и схемой, но я думаю, что он добавляет к обсуждению.
Я боролся с идеей, что я создаю N количество пользователей, где я хочу, чтобы каждый из этих пользователей "потреблял" (иначе говоря, использовал) одну схему.
У него есть второй подход "синоним" (не указан здесь). Я цитирую только версию CURRENT_SCHEMA (один из его подходов) здесь:
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>
Этот метод идеален, когда пользователь приложения просто
альтернативная точка входа в основную схему, не требующая объектов
свой.