Roles serve to simplify rights management. A user who is assigned a role automatically has the same rights as the role.
The assignment of rights is simplified.
An example: You define one role per department in your company. If a user changes department, you don't have to remove every single right and assign all rights to the new department individually, you just change the role of the user.
Definitely, because without the use of roles all rights for each user must be stored in the DBC tables. The required rights are assigned to the role once and then only one single assignment from user to role per user is needed. This results in less congestion on the DBC tables.
CREATE ROLE DWHPRO_ADMIN;
For example, you can add read access:
GRANT SELECT ON Customer TO DWHPRO_ADMIN;
You can revoke read access like this:
REVOKE SELECT ON Customer FROM DWHPRO_ADMIN;
Roles can, in turn, be assigned to roles. In this way, the role inherits all rights of the superordinate role. Nesting can only take place on one level.
But: Nested roles have a negative performance impact as permissions have to be collected from the DBC tables in a more complicated way!
GRANT ROLE TO DWHPRO WITH GRANT OPTION;
This right can only be given to users, not to databases or roles!
The active role can be selected with the following statement:
SET ROLE RoleA;
Should all roles be active simultaneously? This is the syntax:
SET ROLE ALL;
A default role which is used when a user logs on can be defined when creating/changing the user:
CREATE/MODIFY USER dwhpro … DEFAULT ROLE = DWHPRO_ADMIN;
In table DBC.RoleInfoV
In table DBC.RoleMembersV