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