Ta odpowiedź nie określa różnicy między właścicielem a schematem, ale myślę, że dodaje się do dyskusji.
Walczyłem z pomysłem, że tworzę N liczbę użytkowników, w których chcę, aby każdy z tych użytkowników „zużywał” (aka, używał) jednego schematu.
Ma drugie podejście „synonimiczne” (nie wymienione tutaj). Cytuję tylko wersję CURRENT_SCHEMA (jedno z jego podejść) tutaj:
CURRENT_SCHEMA Podejście
Ta metoda wykorzystuje CURRENT_SCHEMAatrybut sesji do automatycznego wskazywania użytkownikom aplikacji prawidłowego schematu.
Najpierw tworzymy właściciela schematu i użytkownika aplikacji.
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;
Zwróć uwagę, że użytkownik aplikacji może się łączyć, ale nie ma żadnych przydziałów obszaru tabel ani uprawnień do tworzenia obiektów.
Następnie tworzymy niektóre role, aby umożliwić dostęp do odczytu i zapisu oraz tylko do odczytu.
CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;
Chcemy dać naszej aplikacji użytkownika dostęp do odczytu i zapisu do obiektów schematu, dlatego przyznajemy odpowiednią rolę.
GRANT schema_rw_role TO app_user;
Musimy upewnić się, że użytkownik aplikacji ma domyślny schemat wskazujący właściciela schematu, dlatego tworzymy wyzwalacz PO LOGO, aby to zrobić za nas.
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;
/
Teraz jesteśmy gotowi do utworzenia obiektu we właścicielu schematu.
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;
Zwróć uwagę, w jaki sposób uprawnienia są przyznawane odpowiednim rolom. Bez tego obiekty nie byłyby widoczne dla użytkownika aplikacji. Mamy teraz funkcjonującego właściciela schematu i użytkownika aplikacji.
SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
Name Null? Type
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
DESCRIPTION VARCHAR2(50)
SQL>
Ta metoda jest idealna, gdy użytkownik aplikacji jest po prostu alternatywnym punktem wejścia do głównego schematu, nie wymagając własnych obiektów.