Creating Security Roles
The following topics describe how to enable end users to access cube data through client applications. For information about enabling administrators to access cube data and meta data and to perform administrative functions, see Administrator Security.
|Creating Database Roles||Identifies ways of creating database roles.|
|Creating Cube Roles||Describes ways of creating cube roles, changing their default values, and specifying their cell security.|
|Creating Mining Model Roles||Describes ways of creating mining model roles and changing their default values.|
|Defining Custom Rules for Dimension Security||Describes creating custom rules in database and cube roles.|
|Defining Custom Rules for Cell Security||Describes ways of creating custom rules.|
Microsoft® SQL Server™ 2000 Analysis Services uses Microsoft Windows NT® 4.0 or Microsoft Windows® 2000 user accounts and groups to define roles for end user access to Analysis Services databases and cube data. Essentially, you combine user accounts and groups into roles and then assign the roles to cubes. Set up these user accounts and groups in Windows NT 4.0 User Manager or Windows 2000 Computer Management before you create roles in Analysis Services.
The three types of roles included in Analysis Services are database, cube, and mining model roles.
The database role is defined at the Analysis Services database level; it can be assigned to multiple cubes in the database, thereby granting the role's users access to these cubes. Such an assignment creates a cube role with the same name as the database role. A database role provides defaults for cube roles of the same name. Use Database Role Manager to maintain database roles.
The cube role is created at the cube level when a database role is assigned to a cube; a cube role applies to only that cube. Defaults in a cube role are derived from the database role of the same name, but some of these defaults can be overridden in the cube role. A cube role contains additional options such as cell security that are not contained in a database role. Use Cube Role Manager to maintain cube roles.
To implement cube-specific security using roles, perform two procedures:
- Create database roles by combining user accounts and groups and specifying the kind of access the roles are allowed.
- For each cube in the database, create cube roles by selecting the database roles that can access the cube. You can then change the defaults of the cube roles. These defaults are provided by the database roles.
The mining model role is created at the mining model level when a database role is assigned to a mining model; a mining model role applies to only that mining model. Defaults in a mining model role are derived from the database role of the same name, but some of these defaults can be overridden in the mining model role.
The default access provided by roles is read (that is, read-only), but you can also grant read/write access to select database or cube roles if a cube or dimension is write-enabled.
A write-enabled cube allows users in roles with read/write access to save changes to the cube's data. However, because the changes are saved separately from the original cube data, they affect only displayed cube data and can be deleted if necessary. The separately stored changes are called writeback data. A write-enabled dimension allows users in roles with read/write access to update the dimension's members. These changes are recorded directly in the dimension table.