Oracle9i OLAP Services Developer's Guide to the OLAP DML
Release 1 (9.0.1)

Part Number A86720-01
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index


Go to previous page Go to beginning of chapter Go to next page

Defining and Working with Analytic Workspaces, 11 of 12

Adding Security to an Analytic Workspace

Types of security

You can protect analytic workspaces with a password and analytic workspace permission programs. When an analytic workspace is password-protected, users cannot attach it without specifying the password. When you provide an analytic workspace permission program for an analytic workspace, that program associates access rights with OLAP DML objects.

Assigning a password

At any time after you create an analytic workspace, you can assign a password to it by using the DATABASE command with the PASSWORD keyword. This command assigns a password to the current analytic workspace; if the current analytic workspace already has a password, then it replaces the old password with the new one.

Passwords can consist of up to 16 characters. They must begin with a letter or an underscore and can contain letters, numbers, periods (.), and underscores (_). Choose a password you can remember easily. Once you specify a password, you cannot access the analytic workspace without it.

A password does not become effective until you update the analytic workspace. Thereafter, you can attach that analytic workspace only if you supply this password in the DATABASE command.

Example: Assigning and using a password

The following command assigns the password goldfinch to the current analytic workspace (called sales).

database password goldfinch

To access the analytic workspace after this command is executed, you must, as shown below, use the password goldfinch.

database sales goldfinch

Removing a password

To remove a password from the current analytic workspace, use the DATABASE command with the PASSWORD keyword without specifying the password argument. Once you update the analytic workspace, the password is no longer required to attach the analytic workspace.

Using analytic workspace permission programs

When a user attaches an analytic workspace, the analytic workspace is checked to see if it contains a program called PERMIT_READ or PERMIT_WRITE. You do not have to create these programs; however, if they are present, then they are automatically executed when the user attaches an analytic workspace.

IF the user attaches an analytic workspace with . . .  THEN the following program is executed, it exists . . . 

read-only access, 

PERMIT_READ program. 

read/write access, 

PERMIT_WRITE program. 

If you have analytic workspace permission programs defined in analytic workspaces that are currently attached, then the one in the analytic workspace that you are attaching is executed. However, if you have analytic workspace permission programs in more than one currently attached analytic workspace, then you must take special care when you edit them or use them in any other way, to ensure that you access the one in the appropriate analytic workspace.

Analytic workspace permission programs are executed before any AUTOGO program that is associated with the analytic workspace is executed. If a user specifies a password when attaching the analytic workspace, then the password is not immediately compared to the stored password that was specified with DATABASE PASSWORD. Instead, the password is passed as an argument to the analytic workspace permission program for processing.

Creating and designing analytic workspace permission programs

To create permission programs, you define two programs with the names PERMIT_READ and PERMIT_WRITE. In these programs, you can specify PERMIT commands and the values of the permission conditions on which permission is based. You write these programs as user-defined functions that return a Boolean value.

IF the program returns . . .  THEN the analytic workspace . . . 


is attached. 


is not attached. 

For information on writing and debugging OLAP DML programs, see Chapter 8 and Chapter 9.

Levels of access you can control using permission programs

Permission programs allow you to control two levels of access to the analytic workspace in which they reside.

Type of access 


Analytic Workspace level 

Depending on the return value of the permission program, the user is or is not granted access to the entire analytic workspace. 

Object level 

Depending on the PERMIT commands in the permission program, the user is or is not restricted to the access to specific objects or sets of object values.

Note: All of the objects referred to in a given permission program must exist in the same analytic workspace. 

Using PERMIT commands to restrict access

For example, using the PERMIT command, you can deny access to the SALARY variable to one group of users, and you can deny access to the TENURE variable to another group of users. You can even specify that certain users cannot access a subset of the cells in the SALARY variable.

You can specify permission to access OLAP DML objects with PERMIT commands. The PERMIT command can use permission conditions based on values that are returned by the SYSINFO function. In this manner, you can specify permission based on the user ID under which the session is running or the groups to which the user ID belongs.

Making an analytic workspace read-only

To protect an analytic workspace from inadvertent changes, you should ensure that users attach the analytic workspace in read-only (RO) mode unless you know that users need to make permanent changes in the analytic workspace. By default, an analytic workspace is read-only when it is attached. You can also explicitly make the analytic workspace read-only at the system level.

Users can use a read-only analytic workspace in the same way as an ordinary analytic workspace; users can even make changes to it during a session. However, users cannot make the changes permanent on disk by updating. The UPDATE command has no effect on an analytic workspace with read-only access. This protects data you do not want users to change.

Go to previous page Go to beginning of chapter Go to next page
Copyright © 1996-2001, Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index