了解Oracle存储过程中的角色

    角色（数据库权限集）与存储过程、函数和数据包之间的交互方式是Oracle安全模型中最难以处理的一个部分。Oracle中的对象权限可以直接或通过角色间接授予用户。 网管u家u.bitsCN.com

    假设一个HR用户向用户ABEL授予EMPLOYEES表的一些许可：

中国网管联盟bitsCN.com

GRANT select, insert, update, delete

网管网www.bitscn.com

    这个语句直接把上述四个权限授予给用户ABEL。另一方面，假设一名HR用户这样做： 网管联盟bitsCN_com

GRANT select, insert, update, delete ON employees TO hr_role;

    如果ABEL已被授予HR_ROLE角色，那么他现在通过这个角色就直接拥有了以上权限。 网管论坛bbs_bitsCN_com

    不管使用哪种方法，现在ABEL都拥有了HR.EMPLOYEES表的SELECT权限。如果ABEL通过SELECT语句直接从表中选择数据，那么他如何获得许可并不重要。

    但是，如果ABEL试图建立从这个表中选择的存储过程、函数或数据包，那么他是直接获得许可，还是通过角色取得许可就存在很大差异。 网管网www.bitscn.com

    Oracle要求直接向用户授予一个存储过程中的非拥有对象许可。在编辑过程中角色被临时关闭，用户不能访问授予给他们的任何内容。这样做是出于性能和安全考虑。 网管下载dl.bitscn.com

    角色可以通过SET ROLE命令动态激活和禁用，如果Oracle需要不断检查哪个角色和许可当前处于激活状态，则会带来巨大的管理负担。 网管网www.bitscn.com

    下面的代码是一个更新HR雇员文件的简短存储过程（这段代码用一个同义字EMPLOYEES来代表HR.EMPLOYEES）。当ABEL在第一种情况下试图用直接权限编辑这个文件时，编辑取得成功；当他在第二种情况下仅用间接权限编辑时，编辑失败。 网管下载dl.bitscn.com

CREATE OR REPLACE PROCEDURE update_emp ( 网管网www_bitscn_com

p_employee_id IN NUMBER

,p_salary IN NUMBER 网管u家u.bitscn@com

) 网管u家u.bitsCN.com

AS

v_department_idemployees.department_id%TYPE; 网管联盟bitsCN_com

BEGIN 网管网www.bitscn.com

SELECT department_id INTO v_department_id

网管u家u.bitsCN.com

FROM employees

网管网www_bitscn_com

WHERE employee_id = p_employee_id;

网管u家u.bitsCN.com

UPDATE employees 网管联盟bitsCN@com

SET salary = p_salary 网管论坛bbs_bitsCN_com

WHERE employee_id = p_employee_id; 网管下载dl.bitscn.com

IF v_department_id = 100 THEN 网管联盟bitsCN_com

UPDATE local_employees

SET salary = p_salary

中国网管联盟bitsCN.com

WHERE employee_id = p_employee_id;

网管下载dl.bitscn.com

END IF; 中国网管联盟bitsCN.com

END; 网管网www_bitscn_com

/ 中国网管论坛bbs.bitsCN.com

    有趣的是，向PUBLIC授予许可和直接授予所有用户许可相同。PUBLIC常被认为是一个角色，但它并不是一个角色。它是一个用户集而不是一个许可集。如果向PUBLIC授权HR.EMPLOYEES的许可，ABEL将能够建立他自己的存储过程。虽然在EMPLOYEES表中我们不推荐这样做，但任何授予给PUBLIC的表都可以自由地在存储过程中应用。 中国网管联盟bitsCN.com