Schema是DB的封装。对象关于一个想法/感兴趣的领域，并拥有一个用户。然后，它将由具有抑制角色的其他用户/应用程序共享。所以用户不需要拥有一个模式，但是模式需要有一个所有者。

将用户视为您通常所做的(用户名/密码，具有登录和访问系统中某些对象的权限)，将模式视为用户主目录的数据库版本。用户“foo”通常在“foo”模式下创建东西，例如，如果用户“foo”创建或引用表“bar”，那么Oracle将假设用户指的是“foo.bar”。

这很简单。

If USER has OBJECTS
then call it SCHEMA
else
     call it USER
end if;

用户可以访问不同用户拥有的模式对象。

模式和数据库用户是一样的，但如果模式拥有数据库对象，他们可以对对象做任何事情，但用户只能访问对象，他们不能做任何DDL操作，直到模式用户给你适当的特权。

用户:对数据库资源的访问。就像一把进入房子的钥匙。

架构:关于数据库对象的信息集合。就像你书中的索引，它包含了关于该章节的简短信息。

详情请看这里

这个答案没有定义所有者和模式之间的区别，但我认为它增加了讨论的内容。

在我小小的思想世界里:

我一直纠结于这样一个想法:我创建了N个用户，其中每个用户都“消费”(也就是使用)单个模式。

Tim在oracle-base.com上演示了如何做到这一点(有N个用户，每个用户将被“重定向”到单个模式。

他还有第二种“同义词”方法(这里没有列出)。这里我只引用了CURRENT_SCHEMA版本(他的方法之一):

CURRENT_SCHEMA Approach This method uses the CURRENT_SCHEMA session attribute to automatically point application users to the correct schema. First, we create the schema owner and an application user. 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; Notice that the application user can connect, but does not have any tablespace quotas or privileges to create objects. Next, we create some roles to allow read-write and read-only access. CREATE ROLE schema_rw_role; CREATE ROLE schema_ro_role; We want to give our application user read-write access to the schema objects, so we grant the relevant role. GRANT schema_rw_role TO app_user; We need to make sure the application user has its default schema pointing to the schema owner, so we create an AFTER LOGON trigger to do this for us. 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; / Now we are ready to create an object in the schema owner. 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; Notice how the privileges are granted to the relevant roles. Without this, the objects would not be visible to the application user. We now have a functioning schema owner and application user. SQL> CONN app_user/password Connected. SQL> DESC test_tab Name Null? Type ----------------------------------------------------- -------- ------------------------------------ ID NOT NULL NUMBER DESCRIPTION VARCHAR2(50) SQL> This method is ideal where the application user is simply an alternative entry point to the main schema, requiring no objects of its own.