4 Users and Privileges for Data Mining

This chapter explains how to create data mining users and control their mining activities through the use of database privileges.

Create a Database User

To create a database user, you must be logged in as a system administrator. You can use any tool that transmits SQL to the database, for example Database Control, SQL*Plus, or SQL Developer.

Example: Create a Database User in SQL*Plus

To create a database user in SQL*Plus:

From the Windows Start menu, select the Oracle home of the local database.

Note:
If there are n database installations, they will appear as Oracle – OraDb11g_home1, Oracle – OraDb11g_home2, ...... Oracle – OraDb11g_homen in the Start menu.
Each of these refers to a separate ORACLE_HOME. Be sure to select the appropriate one.
Choose Application Development.
Choose SQL*Plus.

Enter user-name: sys / as sysdba
    Enter password: password

To create a user named dmuser, type these commands. Specify a password of your choosing.
```
CREATE USER dmuser IDENTIFIED BY password
       DEFAULT TABLESPACE USERS
       TEMPORARY TABLESPACE TEMP
       QUOTA UNLIMITED ON USERS;
Commit;
```
Specify the USERS and TEMP tablespaces. These tablespaces are included in the starter database that was created during the installation, and they are typically included in a database by default. (See "Install Oracle Database"). The USERS and TEMP tablespaces are generally assigned to users that generate examples and demonstrations.

Note:
Tablespaces for Data Mining users should be assigned according to standard DBA practices, depending on system load and system resources.

To login as dmuser, type the following.

CONNECT dmuser
Enter password: password

Grant Data Mining Privileges

A set of basic privileges is required for data mining. Some may not be required for all mining activities, however it is prudent to grant them all as a group. The GRANT statements in Example 4-1 grant these privileges to dmuser.You could execute these statements in SQL*Plus after logging in with system privileges.

Example 4-1 Privileges Required for Data Mining

GRANT CREATE JOB TO dmuser;
GRANT CREATE MINING MODEL TO dmuser;        -- required for creating models
GRANT CREATE PROCEDURE TO dmuser;
GRANT CREATE SEQUENCE TO dmuser;
GRANT CREATE SESSION TO dmuser;
GRANT CREATE SYNONYM TO dmuser;
GRANT CREATE TABLE TO dmuser;
GRANT CREATE TYPE TO dmuser;
GRANT CREATE VIEW TO dmuser;
GRANT EXECUTE ON ctxsys.ctx_ddl TO dmuser;  -- required for text mining
GRANT SELECT ON data TO dmuser;             -- required for data 
                                               that is not in your schema

Additional access rights are required for exporting and importing mining models, as described in "Exporting and Importing Mining Models".

Additional system and object privileges described in "System Privileges for Data Mining" and "Object Privileges for Mining Models" can be used to enable or restrict particular mining activities.

Note:

To create a user for the Data Mining sample programs, you need to run two configuration scripts as described in "Installation and Setup".

System Privileges for Data Mining

A system privilege confers the right to perform a particular action in the database or to perform an action on a type of schema objects. For example, the privileges to create tablespaces and to delete the rows of any table in a database are system privileges.

To grant a system privilege, you must either have been granted the system privilege with the ADMIN OPTION or have been granted the GRANT ANY PRIVILEGE system privilege.

The system privileges listed in Table 4-1 control operations on mining models.

Table 4-1 System Privileges for Data Mining

System Privilege	Allows you to ....
`CREATE MINING MODEL`	Create mining models in your own schema.
`CREATE ANY MINING MODEL`	Create mining models in any schema.
`ALTER ANY MINING MODEL`	Change the name or cost matrix of any mining model in any schema.
`DROP ANY MINING MODEL`	Drop any mining model in any schema.
`SELECT ANY MINING MODEL`	Apply (score) a mining model in any schema, also view model details in any schema.
`COMMENT ANY MINING MODEL`	Add a comment to any mining model in any schema. (See "Adding a Comment to a Mining Model".)
`AUDIT ANY`	Generate an audit trail for any mining model (or any object) in any schema. (See "Auditing Mining Models".)

Example: Grant System Privileges for Data Mining

The following statements allow dmuser to score models and view model details in any schema as long as SELECT access has been granted on the data. However, dmuser can only create models in the dmuser schema.

GRANT CREATE MINING MODEL TO dmuser;
GRANT SELECT ANY MINING MODEL TO dmuser;

The following statement revokes the privilege of scoring or viewing model details in other schemas. When this statement is executed, dmuser can only perform data mining activities in the dmuser schema.

REVOKE SELECT ANY MINING MODEL FROM dmuser;

Object Privileges for Mining Models

An object privilege confers the right to perform a particular action on a specific schema object. For example, the privilege to delete rows from the SH.PRODUCTS table is an example of an object privilege.

A user automatically has all object privileges for schema objects in the user's own schema. A user can grant object privilege on objects in the user's own schema to other users or roles.

The object privileges listed in Table 4-2 control operations on specific mining models.

Table 4-2 Object Privileges for Mining Models

Object Privilege	Allows you to ....
`ALTER MINING MODEL`	Change the name or cost matrix of the specified mining model object.
`SELECT MINING MODEL`	Apply (score) and view model details of the specified mining model object.

Example: Grant Object Privileges on Mining Models

The following statements allow dmuser to apply the model testmodel to the sales table, specifying different cost matrixes with each apply. The user dmuser can also rename the model testmodel. The testmodel model and sales table are in the sh schema, not in the dmuser schema.

GRANT SELECT ON MINING MODEL sh.testmodel TO dmuser;
GRANT ALTER ON MINING MODEL sh.testmodel TO dmuser;
GRANT SELECT ON sh.sales TO dmuser;

This statement prevents dmuser from renaming or changing the cost matrix of testmodel. However, dmuser can still apply testmodel to the sales table.

REVOKE ALTER ON MINING MODEL sh.testmodel FROM dmuser;