SQL语句PART5

Confirming granted privileges
Data Dictionary View                Description
ROLE_SYS_PRIVS                System privileges granted to roles
ROLE_TAB_PRIVS                Table privileges granted to roles
USER_ROLE_PRIVS             Roles accessible by the user
USER_SYS_PRIVS               System privileges granted to the user
USER_TAB_PRIVS_MADE     Object privileges granted on the user's objects
USER_TAB_PRIVS_RECD     Object privileges granted to the user
USER_ROLE_PRIVS_MADE  Object privileges granted on the columns of the user's objects
USER_ROLE_PRIVS_RECD:  Object privileges granted to the user on specific columns


Revoking Object Privileges
grammer:
revoke {privileges [, privileges...] | all}
on object from {user [,...user...] | role | pubic} cascade constraints;
// privileges granted to others through the WITH GRANT OPTION clause are also revoked.


 Alter table statement
grammer:
alter table table1 add (column datatype [default expr] [, column datatype]...);
alter table table1 modify (column datatype [default expr] [, column datatype]...);
alter table table1 drop (column);


Alter table (set unused option)
grammer:
alter table <table_name> set unsed (<column_name>);
or
alter table <table_name> set unsed column <column_name>;
then:
alter table <table_name> drop unused columns;


Constraint: Adding a constraint Syntax
grammer:
alter table <table_name> add [constraint <constraint_name>] type (<column_name>);
e.g.:
alter table emp2 modify employee_id primary key;
alter table emp2 add constraint emp_mgr_fk foreign key(manager_id) references emp2(employee_id);


Constraint: on delete cascade
alter table emp2 add constraint emp_dt_fk foreign key(department_id) references departments(department_id) on delete cascade;

Deferred Constraints

Normally, constraints are checked as data is inserted or updated in the row.  When a row is inserted, all the constraints are checked and the row either accepted or rejected.  You can, however, defer the constraint checking until the transaction  commits.  In that case, the row is inserted into the table and constraints are not checked until the COMMIT  is issued.  If the row then fails, it is removed from the table.  You can change the status of the constraints by setting them as DEFERRED or IMMEDIATE.  In order to change the constraint, it must be deferrable. 

SQL> set constraint active_ck deferred;
set constraint active_ck deferred
*
ERROR at line 1:
ORA-02447: cannot defer a constraint that is not deferrable

Here, the active_ck constraint was not created as deferrable.  In fact, none of the constraints we have created so far can be DEFFERED.  Let’s recreate the job_fk as a deferrable constraint.

SQL> alter table emp drop constraint job_fk; 

Table altered.

SQL>  alter table emp
  2     add (constraint job_fk foreign key (job_key)
  3          references job (job_key)
  4         on delete cascade deferrable); 

Table altered. 

SQL> set constraint job_fk deferred; 

Constraint set. 

SQL> set constraint job_fk immediate; 

Constraint set. 

First, I drop the current constraint and recreate it with the deferrable key work.  Now, I can defer the constraint and reset it back to IMMEDIATE.  This seems a bit complicated, so why would you want to defer a constraint?  One example is with foreign key constraints.  You can, and should, set up foreign key constraints to insure that the data in your tables is correctly related.  Once the foreign keys are in place, you must insure that data is inserted/updated to the parent first, then to the child tables.   

With a number of foreign key constraints in place, you could run into the situation where you cannot get the data into the tables without violating at least one foreign key.  If I could just get the data loaded, then the check the foreign keys the data would be accepted.  Here is where the deferred constraint is useful. By deferring the foreign key constraints, you can get the data into the tables and then validate it against the foreign keys.  Invalid data is still rejected.