Efecto de revocar privilegios de roles

Cuando se revocan privilegios, esto a veces puede hacer que los objetos de base de datos dependientes, como vistas, paquetes o desencadenantes, no sean válidos o no sean operativos.

Los ejemplos siguientes muestran qué sucede con un objeto de base de datos cuando se revocan algunos privilegios de un identificador de autorización y los privilegios se mantienen a través de un rol o a través de medios diferentes.

Ejemplo de revocación de privilegios de roles

El administrador de seguridad crea el rol DEVELOPER y otorga al usuario BOB la pertenencia a este rol:
```
CREATE ROLE DEVELOPER
GRANT ROLE DEVELOPER TO USER BOB
```
El usuario ALICE crea una tabla, WORKITEM:
```
CREATE TABLE WORKITEM (x int)
```

El administrador de base de datos otorga privilegios SELECT e INSERT sobre la tabla WORKITEM a PUBLIC y también al rol DEVELOPER:

GRANT SELECT ON TABLE ALICE.WORKITEM TO PUBLIC
GRANT INSERT ON TABLE ALICE.WORKITEM TO PUBLIC
GRANT SELECT ON TABLE ALICE.WORKITEM TO ROLE DEVELOPER
GRANT INSERT ON TABLE ALICE.WORKITEM TO ROLE DEVELOPER

El usuario BOB crea una vista, PROJECT, que utiliza la tabla WORKITEM, y un paquete, PKG1, que depende de la tabla WORKITEM:
```
CREATE VIEW PROJECT AS SELECT * FROM ALICE.WORKITEM
PREP emb001.sqc BINDFILE PACKAGE USING PKG1 VERSION 1
```
Si el administrador de base de datos revoca el privilegio SELECT en la tabla ALICE.WORKITEM de PUBLIC y, a continuación, la vista BOB.PROJECT permanece operativo y el paquete PKG1 sigue siendo válido porque el definidor de vista, BOB, sigue teniendo los privilegios necesarios a través de su pertenencia al rol DEVELOPER:
```
REVOKE SELECT ON TABLE ALICE.WORKITEM FROM PUBLIC
```
Si el administrador de base de datos revoca el privilegio SELECT en la tabla ALICE.WORKITEM del rol DEVELOPER, la vista BOB.PROJECT pasa a estar inoperativo y el paquete PKG1 deja de ser válido porque el definidor de vista y paquete, BOB, no tiene los privilegios necesarios por otros medios:
```
REVOKE SELECT ON TABLE ALICE.WORKITEM FROM ROLE DEVELOPER
```

Ejemplo de revocación de autorización DBADM

En este ejemplo, el rol DEVELOPER tiene autorización DBADM y se otorga al usuario BOB.

El administrador de seguridad crea el rol DEVELOPER:
```
CREATE ROLE DEVELOPER
```
El administrador del sistema otorga autorización DBADM al rol DEVELOPER:
```
GRANT DBADM ON DATABASE TO ROLE DEVELOPER
```
El administrador de seguridad otorga al usuario la pertenencia a BOB en este rol:
```
GRANT ROLE DEVELOPER TO USER BOB
```
El usuario ALICE crea una tabla, WORKITEM:
```
CREATE TABLE WORKITEM (x int)
```

El usuario BOB crea una vista PROJECT que utiliza la tabla WORKITEM, un paquete PKG1 que depende de la tabla WORKITEM y un desencadenante, TRG1, que también depende de la tabla WORKITEM:

CREATE VIEW PROJECT AS SELECT * FROM ALICE.WORKITEM
PREP emb001.sqc BINDFILE PACKAGE USING PKG1 VERSION 1
CREATE TRIGGER TRG1 AFTER DELETE ON ALICE.WORKITEM 
              FOR EACH STATEMENT MODE DB2SQL
       INSERT INTO ALICE.WORKITEM VALUES (1)

El administrador de seguridad revoca el rol DEVELOPER del usuario BOB:
```
REVOKE ROLE DEVELOPER FROM USER BOB
```
La revocación del rol DEVELOPER hace que el usuario BOB pierda la autorización DBADM porque el rol que tenía dicha autorización se ha revocado. La vista, el paquete y el desencadenante se ven afectados como se indica a continuación:
- Ver BOB. PROJECT sigue siendo válido.
- El paquete PKG1 deja de ser válido.
- Desencadenar BOB.TRG1 sigue siendo válido.
Ver BOB.PROJECT y desencadenante BOB.TRG1 se pueden utilizar mientras que el paquete PKG1 no se puede utilizar. Los objetos de vista y desencadenante creados por un ID de autorización que tiene autorización DBADM no se ven afectados cuando se pierde la autorización DBADM.