Oracle中用户和架构之间的区别？

Question

Oracle中的用户和架构有什么区别？

Answer 1

从问汤姆

您应该将模式视为用户帐户,并将其中所有对象的集合视为所有意图和目的的模式.

SCOTT是一个模式,包括带有各种授权的EMP,DEPT和BONUS表以及其他内容.

SYS是一个包含大量表格,视图,授权等的模式等.

SYSTEM是一个模式.....

技术上 - 模式是数据库使用的元数据集(数据字典),通常使用DDL生成.模式定义数据库的属性,例如表,列和属性.数据库模式是数据库中数据的描述.

Answer 2

我认为问题在于Oracle使用术语schema与它通常意味着的略有不同.

1. Oracle的架构(如Nebakanezer的答案中所述):基本上是用户帐户拥有的所有表和其他对象的集合,因此大致相当于用户帐户
2. 一般模式:构成给定系统/应用程序数据库的所有表,sprocs等的集合(如"开发人员应与DBA讨论新应用程序的模式.")

意义2中的模式与意义1中的模式类似,但不同.例如,对于使用多个DB帐户的应用程序,意义2中的模式可能包含多个Oracle模式:-).

在其他环境中(例如在数学中),加上模式也意味着一堆其他相当不相关的东西.

Oracle应该使用像"userarea"或"accountobjects"这样的术语,而不是在"schema"中重载...

Answer 3

来自WikiAnswers:

• 模式是数据库对象的集合,包括逻辑结构,如表,视图,序列,存储过程,同义词,索引,集群和数据库链接.
• 用户拥有架构.
• 用户和架构具有相同的名称.
• CREATE USER命令创建用户.它还会自动为该用户创建架构.
• CREATE SCHEMA命令不会创建"模式",因为它意味着它只允许您在单个事务中创建多个表和视图并在您自己的模式中执行多个授权.
• 出于所有意图和目的,您可以将用户视为架构,并将架构视为用户.

此外,如果用户有权这样做,则用户可以访问自己以外的模式中的对象.

Answer 4

像往常一样考虑用户(可以访问登录和访问系统中某些对象的用户名/密码)和作为用户主目录的数据库版本的模式.用户"foo"通常在模式"foo"下创建事物,例如,如果用户"foo"创建或引用表"bar",则Oracle将假定用户表示"foo.bar".

Answer 5

这个答案没有定义所有者和架构之间的区别,但我认为它增加了讨论.

在我的小思维世界中:

我一直在努力创建N个用户,我希望这些用户中的每一个都"消费"(也称为使用)单个模式.

oracle-base.com上的Tim展示了如何执行此操作(拥有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>

此方法非常适用于应用程序用户只是主模式的替代入口点,不需要自己的对象.

Answer 6

这很简单.

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

可以向用户授予对不同用户拥有的模式对象的访问权.