CREATE SCHEMA Purpose Use the CREATE SCHEMA statement to create multiple tables and views and perform

multiple grants in your own schema in a single transaction. To execute a CREATE SCHEMA statement, Oracle Database executes each included statement. If all statements execute successfully, then the database commits the transaction. If any statement results in an error, then the database rolls back all the statements. Note: This statement does not actually create a schema. Oracle Database automatically creates a schema when you create a user (see CREATE USER). This statement lets you populate your schema with tables and views and grant privileges on those objects without having to issue multiple SQL statements in multiple transactions. Prerequisites The CREATE SCHEMA statement can include CREATE TABLE, CREATE VIEW, and GRANT statements. To issue a CREATE SCHEMA statement, you must have the privileges necessary to issue the included statements. Syntax create_schema::=

Description of the illustration create_schema.gif

Keyword and Parameters schema Specify the name of the schema. The schema name must be the same as your Oracle Database username. create_table_statement Specify a CREATE TABLE statement to be issued as part of this CREATE SCHEMA statement. Do not end this statement with a semicolon (or other terminator character).

See Also: CREATE TABLE create_view_statement Specify a CREATE VIEW statement to be issued as part of this CREATE SCHEMA statement. Do not end this statement with a semicolon (or other terminator character). See Also: CREATE VIEW grant_statement Specify a GRANT statement to be issued as part of this CREATE SCHEMA statement. Do not end this statement with a semicolon (or other terminator character). You can use this clause to grant object privileges on objects you own to other users. You can also grant system privileges to other users if you were granted those privileges WITH ADMIN OPTION. See Also: GRANT The CREATE SCHEMA statement supports the syntax of these statements only as defined by standard SQL, rather than the complete syntax supported by Oracle Database. The order in which you list the CREATE TABLE, CREATE VIEW, and GRANT statements is unimportant. The statements within a CREATE SCHEMA statement can reference existing objects or objects you create in other statements within the same CREATE SCHEMA statement. Restriction on Granting Privileges to a Schema The syntax of the parallel_clause is allowed for a CREATE TABLE statement in CREATE SCHEMA, but parallelism is not used when creating the objects. See Also: the parallel_clause in the CREATE TABLE documentation Example Creating a Schema: Example The following statement creates a schema named oe for the sample order entry user oe, creates the table new_product, creates the view new_product_view, and grants the SELECT object privilege on new_product_view to the sample human resources user hr. CREATE SCHEMA AUTHORIZATION oe CREATE TABLE new_product

(color VARCHAR2(10) PRIMARY KEY, quantity NUMBER) CREATE VIEW new_product_view AS SELECT color, quantity FROM new_product WHERE color = 'RED' GRANT select ON new_product_view TO hr; Control Access with Oracle Grant Security Oracle Tips by Burleson Consulting July 28, 2003 For a complete discussion of Oracle grant security, see my book "Oracle Privacy Security Auditing". Oracle offers many ways to control data access rules, including:

Grant security (e.g., system, object, and role privileges) Grant execute security (e.g., definer and invoker rights) Virtual private databases (VPD) N-tier authentication (e.g., RADIUS and authentication servers)

Let's start with the basics by looking at grant security to examine its benefits and pitfalls. The original relational model provides a method for granting privileges to users to allow for access control. This grant model was originally described by E.F. Codd and Chris Date in the original relational model and the model is standard across most commercial relational databases. Oracle grant security takes several forms: object grants, system privilege grants, and rolebased grants. The idea is that every user in the database is granted access to specific data objects to control data access. Oracle Object privileges Object privileges assign the right to perform a particular operation on a specific object. Here are some examples of object privilege assignment: grant grant grant grant select, insert on customer to fred, mary, joe; insert on order_table to update_role; all on customer to fred; select on customer_view to mary;

As you can see, the direct assignment of object privileges requires specific grants for every object to every user in the Oracle database. If you have a schema with 100 tables and 1,000 users, it would require 100,000 individual grant statements to assign security.

Oracle System privileges System privileges cover many areas of access in a broad brush, with grants such as select any table. Examples of system privilege grants include: grant grant grant grant create select create create any cluster to customer_role; any table to fred; any table to public; tablespace to dba_role;

Obviously, system privileges should be used only in cases where security isn't important, because a single grant statement could remove all security from the table. Oracle Role-based security Role security allows you to gather related grants into a collection. Since the role is a predefined collection of privileges that are grouped together, privileges are easier to assign to users, as in this example: create role all_customer; grant select, update on customer to all_customer; grant select on item_table to all_customer; grant all_customer to fred, mary, joe; The benefits of role-based security are obvious, because role-based security allows you to define sets of access rules and then assign them to the appropriate classes of users. However, unlike VPD security, it isn't possible to implement sophisticated rules for data access. With grants, users either have access to the table, or they do not.

Design for Oracle grant security If you choose to implement grant security for your Oracle database, you must do some careful up-front planning to ensure that each role is carefully designed to cover access for a specific class of users without overlapping other roles. The steps for implementing grant security are: 1. 2. 3. 4. 5. 6. Define roles for all known classes of users. Define access rules for each role. Define all row-level and column-level restrictions. Create views for all data access. Assign the views to the roles. Assign the roles to the users.

To alleviate the issue of overlapping roles, many Oracle designers create a hierarchy of roles, using roles within roles to exactly match the data access requirements to user groups.

User group access Note the careful overlap of access privileges between the programmer and analyst roles. It's not uncommon for roles to legitimately overlap when it comes to access, and the Oracle designer must pay careful attention to the access outline. In the real world, the design of the roles can get quite complex. To illustrate, let's look at a simple example. Design for row-level and column-level access In the real world, it isn't enough simply to grant access to whole tables; often you may need to restrict access to specific rows within a table. Without VPDs, the only way to do this with grants is to create separate views for each row-level restriction and then assign the views to the roles and the roles to the users. For example, assume that you must design roles based on the following business rules:

Only managers may view the salary column of the employee table (column restriction).

Other employees may view only employee names and phone number for publisher P001 (row restriction).

To implement this design within Oracle using role-based security, perform the following steps:

Create the base roles for managers and employees. Create the appropriate views. Grant the views to the roles. Grant the roles to the users.

In Oracle, the views in Listing A implement this design scheme. SQL> create role emp_role; Role created. SQL> create role mgr_role; Role created. SQL> create view emp_view as select emp_first_name, emp_last_name from emp where pub_key = 'P001'; View created. SQL> create view 2 mgr_view 3 as 4 select 5 emp_first_name, emp_last_name, emp_salary 6 from 7 emp; View created. SQL> SQL> -- Grant the privileges to the role SQL> grant create session, connect, resource to emp_role, mgr_role; Grant succeeded.

2 3 4 5 6 7 8 9

SQL> grant select on emp_view to emp_role; Grant succeeded. SQL> grant select on mgr_view to mgr_role; Grant succeeded. SQL> create user fred_emp identified by fred; User created. SQL> grant emp_role to fred_emp; Grant succeeded. SQL> create user mary_mgr identified by mary; User created. SQL> grant mgr_role to mary_mgr; Grant succeeded. Now that you've assigned the appropriate grant statements, test your views and see if they work (Listing B): SQL> connect fred_emp/fred; Connected. SQL> select * from pubs.emp_view; EMP_FIRST_NAME EMP_LAST_NAME ------------------------------------------------sam king mary korn SQL> connect mary_mgr/mary; Connected. SQL> select * from pubs.mgr_view; EMP_FIRST_NAME EMP_LAST_NAME EMP_SALARY -------------------- ------------------------------sam king 95000

bill 35000 mary 28000 fred 45000 janet 63000 john 14000

jackson korn linus tokheim lavender

Loopholes in grant security There are several issues with grant security that can create loopholes in your design. These include:

Assigning grants to PUBLIC. Assigning roles using the WITH ADMIN option. Overlapping unplanned access roles. Assigning system privileges (select any table) to roles. Creating public synonyms.

For example, within Oracle you can explicitly grant to PUBLIC all tables that you wish to have general read-only access. This system privilege supercedes the role-based security and creates a giant loophole, as in this example: Create public synonym customer for pubs.customer; Grant select on customer to public; Another important loophole is public synonyms for tables. Remember, the default in Oracle is that nobody except the object owner is allowed to perform any operation on the table. Also, the full table name must be specified in the SQL or Oracle will imply that the table does not exist: connect pubs/pubs Connected. create table test_table as select object_name, object_type from dba_objects; Table created.

select count(*) from test_table; COUNT(*) ---------31350 1 row selected. Now, when you connect as the user, SCOTT, he is unable to see the table rows, as in the example: connect scott/tiger Connected. select count(*) from test_table * ERROR at line 1: ORA-00942: table or view does not exist In this case, you know that the table exists, but Oracle considers only the fully-qualified table name: Connect pubs/pubs create public synonym test1_table for pubs.test1_table; Synonym created. Connect scott/tiger select count(*) from test_table; COUNT(*) ---------31350 1 row selected.