SQLオブジェクトに対する権限

表のオブジェクト権限

ユーザーが表を作成するには、そのユーザーにCREATE TABLEまたはCREATE ANY TABLE権限が付与されている必要があります。

自分が所有していない表に対して処理を実行する場合、そのユーザーには、その表に関する適切なオブジェクト権限が付与されている必要があります。このような権限には、キャッシュ・グループに含まれる表に関する権限などがあります。表に関するオブジェクト権限には、SELECT、UPDATE、DELETE、INSERT、INDEXおよびREFERENCESがあります。

たとえば、次のように指定します:

Command> GRANT SELECT ON hr.employees TO pat;
Command> GRANT UPDATE ON hr.employees TO pat;

INDEX権限を持つユーザーは、表の索引を作成できます。

REFERENCES権限により、CREATE TABLE文またはALTER TABLE文でREFERENCES句を使用できます。この句は、子表の列(次の例ではtable1.col1)から親表の列(例ではtable2.pk)への外部キー依存性を作成します。

Command> ALTER TABLE pat.table1 ADD CONSTRAINT fk1 FOREIGN KEY (col1) 
REFERENCES pat.table2 (pk);

pat (表の所有者)が文が実行する場合、追加の権限は必要ありません。文を実行する他のユーザーには、ALTER ANY TABLE権限が必要です。

また、ALTER TABLE ... REFERENCES文を実行するユーザーが、REFERENCES句で参照される表を所有していない場合、適用可能な表の列に対するREFERENCESオブジェクト権限が必要です。たとえば、patが次の文を実行するとします。

Command> ALTER TABLE pat.table1 ADD CONSTRAINT fk1 
FOREIGN KEY (col1) REFERENCES terry.table2 (pk);

Patには、次の権限付与が必要になります。

Command> GRANT REFERENCES (pk) ON terry.table2 TO pat;

REFERENCES権限は、親表から外部キーを作成しているユーザーにSELECT権限を暗黙的に付与することに注意してください。ただし、この暗黙的な付与によって親表のSELECT権限がユーザーに付与されるわけではないため、親表に対する権限がREFERENCESのみの場合は、SELECT文が失敗します。

ノート:

外部キー制約によって関連付けられている表がある場合、これらのノートが適用されます:

子表の外部キー制約にON DELETE CASCADEが指定されている場合は、子表に対するDELETE権限が明示的に付与されていなくても、ユーザーは子表からの削除を伴う親表からの行の削除を実行できます。ただし、この動作が自動で行われるようにするには、ユーザーに親表に対するDELETE権限が必要です。
子表に対する挿入または更新を実行すると、親表に対する外部キー制約違反が子表に対する変更に伴って発生していないかどうかが確認されます。違反が発生する場合、ユーザーには子表に対するINSERT権限またはUPDATE権限が必要になりますが、親表に対するSELECT権限は不要です。
子表を作成するユーザーが外部キー依存性を作成するには、親表に対するREFERENCESオブジェクト権限が必要です。

ビューのオブジェクト権限

ユーザーに所有しないビューのSELECTオブジェクト権限を付与すると、そのユーザーはそのビューから選択できるようになります。さらに、ビューの所有者には、そのビューが参照するすべてのオブジェクトに対するSELECTオブジェクト権限が必要です。

ユーザーpatがpatが所有するオブジェクトのみを参照するビューを作成する場合、次の文のように、patにはCREATE VIEW権限のみが必要です。

Command> CREATE VIEW pat.view1 AS SELECT * FROM pat.table1;

patがterryが所有する表を参照するビューを作成する場合、次の文のように、patにはその表に対するSELECTオブジェクト権限も必要です。ビューの所有者には、ビューによって参照される各オブジェクトに対するSELECTオブジェクト権限が付与されている必要があります。

Command> CREATE VIEW pat.view2 AS SELECT * FROM terry.table2;

3人目のユーザーjoeが前述の文を実行するには、joeにCREATE ANY VIEW権限が必要です。また、ビューの所有者としてpatには、terryが所有している表で選択を実行するためにSELECTオブジェクト権限が付与されている必要があります。

ビューから選択すると、実行時にTimesTenでは、必要な基本権限についてそのビューとそのビューによって参照されるビューが検証されます。

次の例を考えてみます。

Command> CREATE VIEW pat.view2 AS SELECT * from terry.table2;
Command> CREATE VIEW joe.view4 AS SELECT * from pat.view2, terry.table4;

patがこの文を実行するには、次の権限が付与されている必要があります。

ユーザーpatがjoeに所有されるスキーマにビューを作成できるように、patにCREATE ANY VIEW権限が付与されている必要があります。
ユーザーjoeに、terry.table4に対するSELECTオブジェクト権限が付与されている必要があります。
ユーザーjoeに、pat.view2に対するSELECTオブジェクト権限が付与されている必要があります。
ユーザーpatに、terry.table2に対するSELECTオブジェクト権限が付与されている必要があります。

順序のオブジェクト権限

自分が所有していない順序に対して処理を実行する場合、ユーザーには、SELECTオブジェクト権限が付与されている必要があります。順序に対するSELECT権限を持つユーザーは、最終的にその順序を更新するNEXTVALのような処理も含めて、順序に対するすべての処理を実行できます。

たとえば、hrスキーマのemployees_seq順序に対するSELECT権限をユーザーpatに付与するには、次のようにします。

Command> GRANT SELECT ON hr.employees_seq TO pat;

ユーザーpatは、この後、次の文を使用してこの順序の次の値を生成できます。

Command> SELECT hr.employees_seq.NEXTVAL FROM DUAL;
< 207 >
1 row found.

マテリアライズド・ビューのオブジェクト権限

マテリアライズド・ビューを作成するには、ユーザーに少なくともCREATE MATERIALIZED VIEW権限が必要です。別のユーザーのスキーマ内にマテリアライズド・ビューを作成する場合は、CREATE ANY MATERIALIZED VIEW権限が必要です。

さらに、マテリアライズド・ビューの所有者には、そのマテリアライズド・ビュー内のすべてのディテール表に対するCREATE TABLE権限およびSELECT権限が必要です。既存のマテリアライズド・ビューの所有者がそのマテリアライズド・ビューに基づく任意のディテール表に対するSELECT権限を失うと、そのマテリアライズド・ビューは無効になります。

自分が所有していないマテリアライズド・ビューから選択する場合、ユーザーには、そのマテリアライズド・ビューに対するSELECT、INDEXやREFERENCESなどのオブジェクト権限が付与されている必要があります。

ノート:

マテリアライズド・ビューのステータスは、SYS.DBA_OBJECTS、SYS.ALL_OBJECTSおよびSYS.USER_OBJECTSビューのSTATUS列に示されます。マテリアライズド・ビューの所有者は、USER_OBJECTSビューでそのステータスを確認できます。

また、マテリアライズド・ビューが無効な場合、ttIsql describeの出力によってマテリアライズド・ビューにINVALIDが追加されます。

さらに、マテリアライズド・ビューについては次のとおりです。

該当する権限を持つユーザーは、マテリアライズド・ビューのディテール表も更新できます。ただし、無効なマテリアライズド・ビューにそれらの変更は反映されません。
無効なマテリアライズド・ビューを再検証するには、適切な権限をそのビューの所有者に付与した後、ビューを破棄してから再作成する必要があります。

シノニムのオブジェクト権限

シノニムは、データベース・オブジェクトの別名です。シノニムは、オブジェクトの名前や所有者を隠すために使用できるため、セキュリティや利便性を目的として頻繁に使用されます。また、シノニムでSQL文を簡略化できます。

シノニムは、シノニムが参照するオブジェクトに関係なく、変更なしでアプリケーションを機能させることができ、独立性を提供します。シノニムはDML文の他、一部のDDL文やキャッシュ文で使用できます。

ユーザーが、プライベート・シノニムまたはパブリック・シノニムを作成または破棄するには、次の権限が必要です。

表2-1 シノニムの権限

アクション	必要な権限
ユーザー自身のスキーマでプライベート・シノニムを作成します。	`CREATE SYNONYM`
他のユーザーのスキーマでプライベート・シノニムを作成します。	`CREATE ANY SYNONYM`
パブリック・シノニムを作成します。	`CREATE PUBLIC SYNONYM`
ユーザー自身のスキーマでプライベート・シノニムを破棄します。	権限は不要です。
他のユーザーのスキーマでプライベート・シノニムを破棄します。	`DROP ANY SYNONYM`
パブリック・シノニムを破棄します。	`DROP PUBLIC SYNONYM`

さらに、シノニムを使用するには、ユーザーには、シノニムが参照するオブジェクトに対する適切はアクセス権限が必要です。たとえば、ビューに対するシノニムを作成し、作成したシノニムを使用してビューから選択を行うには、そのビューに対するSELECT権限が必要です。

ALLオブジェクト権限

ALLキーワードを使用すると、オブジェクトに対するすべての権限をユーザーに付与できます。オブジェクトに対する任意の処理を実行する権限がユーザーに付与されます。オブジェクト所有者およびADMIN権限を持つユーザーは、GRANT ALL文およびREVOKE ALL文を実行できます。

たとえば、GRANT ALL ON hr.employees TO patでは、employees表のすべての権限がユーザーpatに付与されます。すべてのオブジェクトに対する権限を付与した後、権限を個別に取り消すことができます。

Command> GRANT ALL ON hr.employees TO pat;
Command> REVOKE DELETE ON hr.employees FROM pat;

ここでユーザーpatに対して行われているように、ユーザーに付与されたオブジェクト権限についてREVOKE ALLを実行することもできます。

Command> REVOKE ALL ON hr.employees FROM pat;