Cette réponse ne définit pas la différence entre un propriétaire et un schéma, mais je pense qu'elle ajoute à la discussion.
J'ai eu du mal avec l'idée que je crée N nombre d'utilisateurs où je veux que chacun de ces utilisateurs "consomme" (alias, utilise) un schéma unique.
Il a une seconde approche "synonyme" (non listée ici). Je ne cite ici que la version CURRENT_SCHEMA (une de ses approches):
CURRENT_SCHEMA Approche
Cette méthode utilise l' CURRENT_SCHEMAattribut de session pour pointer automatiquement les utilisateurs d'application vers le schéma correct.
Tout d'abord, nous créons le propriétaire du schéma et un utilisateur d'application.
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;
Notez que l'utilisateur de l'application peut se connecter, mais qu'il n'a aucun quota ou privilège d'espace de table pour créer des objets.
Ensuite, nous créons des rôles pour autoriser l'accès en lecture-écriture et en lecture seule.
CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;
Nous voulons donner à notre utilisateur d'application un accès en lecture-écriture aux objets de schéma, nous accordons donc le rôle approprié.
GRANT schema_rw_role TO app_user;
Nous devons nous assurer que l'utilisateur de l'application a son schéma par défaut pointant vers le propriétaire du schéma, nous créons donc un déclencheur AFTER LOGON pour le faire pour nous.
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;
/
Nous sommes maintenant prêts à créer un objet dans le propriétaire du schéma.
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;
Remarquez comment les privilèges sont accordés aux rôles concernés. Sans cela, les objets ne seraient pas visibles pour l'utilisateur de l'application. Nous avons maintenant un propriétaire de schéma et un utilisateur d'application qui fonctionnent.
SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
Name Null? Type
----------------------------------------------------- -------- ------------------------------------
ID NOT NULL NUMBER
DESCRIPTION VARCHAR2(50)
SQL>
Cette méthode est idéale lorsque l'utilisateur de l'application est simplement un point d'entrée alternatif au schéma principal, ne nécessitant aucun objet propre.