oracle的体系结构之权限管理和用户schema（二）

2.oracle的权限管理

oracle数据库有最重要的两个用户，sys 和 system，sys拥有最高权限。

oracle权限分为两种：一种是系统权限 ，一种是对象权限。

下面简单的演示一下，用system用户登录并创建test用户

现在用新创建的这个用户登录

提示没有create session权限。

说明：新创建的用户没有任何权限，连登录数据库的权限都没有

现在依旧用system用户为test用户赋予登录权限

授权过后就可以登录了，现在创建表试试

依旧是权限不足，没有创建表的权限，又必须要管理员为其赋予创建表的权限。由于篇幅问题，这里就不演示了。

用户可以用“select * from session_privs;”查询自己拥有的权限。关于权限的查询可以看下“http://hi.baidu.com/jason_xux/item/f970db14f772caf386ad4e46”。

到这儿想必大家知道权限是怎么一回事了吧。

(1)系统权限和对象权限

关于系统权限，顾名思义就是对系统一些操作的权限，比如刚刚的登录的‘create session’就是一种系统权限，‘create table’‘create user’等都是一些比较常见的系统权限。

对象权限就是对对象的权限，当然这句是废话，呵呵，所谓对象就是‘表’ ‘存储过程’之类的。对象归创建者所有，但是你要想要其他用户可以访问你创建的对象就必须你或者管理员赋予给他权限。

（2）角色

在实际应用中，一个用户可能需要多种权限，比如一个软件开发者需要登录权限 创建表的权限 创建存储过程 创建视图之类的权限，如果一条一条的为该用户赋予权限的话就会加重DBA的负担，如果可以把这些权限一次性赋予给改用户就好了，oracle提供了一种角色的东西(sql server也有)，角色可以理解为权限的集合。

oracle内置了很多角色，用“select * from dba_roles;”可以查询。“select * from user_role_privs;”查询自己拥有的角色。

下面我们依旧来演示一下

首先切换到system用户，收回test用户的‘create session’权限，然后创建名为‘test_role’角色，将‘create session’‘create table’权限赋予‘test_role’角色，再将‘test_role’角色赋予test用户，这样test用户就拥有‘create session’‘create table’两种权限了。

（3）用户schema

schema是数据对象的集合，这其实跟sql server里的数据库差不多，只不过sql server将数据库与用户分离开来了，oracle中一般一个用户对应一个schema，默认的缺省值和用户名相同，当我们在访问表的时候，默认会访问和该用户名一样的schema里面的表，如我们用scott用户执行“select * from emp”，这条查询语句和“select * from scott.emp”是一样的，既然一个用户对应一个schema，那么这个schema是在什么时候创建的呢，schema好像并不是在创建user时就创建的，而是在该用户创建了第一个对象之后才将schema真正创建的，只有user下存在对象，他对应的schema才会存在，如果user下不存在任何对象了，schema也就不存在了。

我在网上找到了一个很形象的比喻：

“我们可以把Database看作是一个大仓库，仓库分了很多很多的房间，Schema就是其中的房间，一个Schema代表一个房间，Table可以看作是每个Schema中的床，Table（床）被放入每个房间中，不能放置在房间之外，那岂不是晚上睡觉无家可归了，然后床上可以放置很多物品，就好比 Table上可以放置很多列和行一样，数据库中存储数据的基本单元是Table，现实中每个仓库放置物品的基本单位就是床， User就是每个Schema的主人，（所以Schema包含的是Object，而不是User），user和schema是一一对应的，每个user在没有特别指定下只能使用自己schema（房间）的东西，如果一个user想使用其他schema（房间）的东西，那就要看那个schema（房间）的user（主人）有没有给你这个权限了，或者看这个仓库的老大（DBA）有没有给你这个权限了。换句话说，如果你是某个仓库的主人，那么这个仓库的使用权和仓库中的所有东西都是你的（包括房间），你有完全的操作权，可以扔掉不用的东西从每个房间，也可以放置一些有用的东西到某一个房间，你还可以给每个User分配具体的权限，也就是他到某一个房间能做些什么，是只能看（Read-Only），还是可以像主人一样有所有的控制权（R/W），这个就要看这个User所对应的角色Role了。”---摘自网络

（4）权限的级联赋予与收回

如果所有的权限的赋予和收回都要DBA来操作的话，那确实对DBA残酷了点儿，那能不能又DBA给某个用户赋予某种权限 然后由该用户在向其他用户赋予该权限呢？答案是可以的。

下面继续演示一下。

我们用system登录，将test的test_role角色撤销，这时test用户不具备任何权限，创建用户test1，再将test_role角色赋予给test用户 但是后面跟了“with admin option”，这就意味着test用户可以将test_role角色赋予给其他角色。我们用test用户登录，将test_role赋予给test1用户，再用test1用户登录 果然可以成功，呵呵 这当然也是废话。接下来用system用户将test的test_role角色收回，这时test用户不在可以登录 ，但是test1用户依然可以登录。这就说明“with admin option”是可以将权限或者角色级联传递，但是管理员收回时不会级联收回。

注意：“with admin option”只能用于系统权限的传递。

下面看下对象权限的级联传递

我们用scott用户登录，将dept的查询权限交给test用户，并允许test用户继续传递。用test用户登录，可以看到test是可以查询scott的dept表的，继续将scott的dept查询权限赋予给test1，显现现在test1也是可以查询scott的dept。现在由scott将test的权限收回，现在test用户明显不能查询了，再看test1，可以看到现在test1也不具有对scott的dept表查询权限了。

注意：“with grant option”只能用于对象权限。查询其他用户的数据对象时，对象前必须加上其schema。如上面的“scott.dept”。

总结：系统权限收回时不会级联收回，对象权限收回时会级联收回。

好了，这篇就到这儿吧！下篇《oracle的体系结构之存储结构（三）》