角色（数据库权限集）与存储过程函数和数据包之间的交互方式是Oracle安全模型中最难以处理的一个部分Oracle中的对象权限可以直接或通过角色间接授予用户
假设一个HR用户向用户ABEL授予EMPLOYEES表的一些许可
GRANT select insert update delete
这个语句直接把上述四个权限授予给用户ABEL另一方面假设一名HR用户这样做
GRANT select insert update delete ON employees TO hr_role;
如果ABEL已被授予HR_ROLE角色那么他现在通过这个角色就直接拥有了以上权限
不管使用哪种方法现在ABEL都拥有了HREMPLOYEES表的SELECT权限如果ABEL通过SELECT语句直接从表中选择数据那么他如何获得许可并不重要
但是如果ABEL试图建立从这个表中选择的存储过程函数或数据包那么他是直接获得许可还是通过角色取得许可就存在很大差异
Oracle要求直接向用户授予一个存储过程中的非拥有对象许可在编辑过程中角色被临时关闭用户不能访问授予给他们的任何内容这样做是出于性能和安全考虑
角色可以通过SET ROLE命令动态激活和禁用如果Oracle需要不断检查哪个角色和许可当前处于激活状态则会带来巨大的管理负担
下面的代码是一个更新HR雇员文件的简短存储过程（这段代码用一个同义字EMPLOYEES来代表HREMPLOYEES）当ABEL在第一种情况下试图用直接权限编辑这个文件时编辑取得成功当他在第二种情况下仅用间接权限编辑时编辑失败
CREATE OR REPLACE PROCEDURE update_emp (
p_employee_id IN NUMBER
p_salary IN NUMBER
)
AS
v_department_idemployeesdepartment_id%TYPE;
BEGIN
SELECT department_id INTO v_department_id
FROM employees
WHERE employee_id = p_employee_id;
UPDATE employees
SET salary = p_salary
WHERE employee_id = p_employee_id;
IF v_department_id = THEN
UPDATE local_employees
SET salary = p_salary
WHERE employee_id = p_employee_id;
END IF;
END;
/
有趣的是向PUBLIC授予许可和直接授予所有用户许可相同PUBLIC常被认为是一个角色但它并不是一个角色它是一个用户集而不是一个许可集如果向PUBLIC授权HREMPLOYEES的许可ABEL将能够建立他自己的存储过程虽然在EMPLOYEES表中我们不推荐这样做但任何授予给PUBLIC的表都可以自由地在存储过程中应用
