oracle - Oracleのスキーマ、ユーザー、および機能ID

Question

オラクルでは、スキーマ、ユーザー、機能IDについて多くのことを混乱させました。私の2つの異なるケースを考えてみましょう

ケースI：

SCOTT@ORCLを考えてみましょう。SCOTTがユーザーだと思うなら。ユーザーのみを作成している間、スキーマを作成します。私が間違っている場合は私を訂正してください。この場合、SCOTTユーザーのみを作成しているときに、SCOTTスキーマが作成されました。別のスキーマを作成する場合、Xと言います。これは、SCOTTユーザーがXスキーマを所有している場合に可能ですか？

ケースII：

SCOTT @ ORCLを考えてみましょう。SCOTTがスキーマのみ、つまりスキーマコマンドのみで作成されていると考える場合。もしそうなら、それを所有しようとしているユーザーなしでスキーマを使用することは何ですか。

oracle関数IDは、データベース内の複数のユーザー/スキーマ（ここにスキーマ/ユーザーを配置できるかどうかはわかりません）を接続するものであると聞きました。ユーザー/スキーマとのOracle機能IDの違いはありますか？

score 9 · Accepted Answer

USER と SCHEMA は、実際には別のエンティティであるにもかかわらず、同じ意味で取り扱われる傾向があるため、多くの人がこのトピックを混乱させています。

スキーマは、ユーザーが所有するデータベースオブジェクトのコレクションです。ユーザーを作成するときに、同時にスキーマを作成します。最初はスキーマは空です。

セッションで現在のスキーマを変更するため、USER と SCHEMA が異なることを示すのは簡単です。これは、所有者の名前を前に付けなくても、別のユーザーのスキーマ内のオブジェクトを参照できることを意味します。

SQL> desc t1
 Name                                      Null?    Type
 ----------------------------------------- -------- -------------
 ID                                                 NUMBER

SQL> alter session set current_schema=APC
  2  /

Session altered.

SQL> desc t1
ERROR:
ORA-04043: object t1 does not exist

SQL> sho user
USER is "X"
SQL>

この場合、APC は T1 というテーブルを持っていないか、X に許可していません。X が自分のテーブルを確認できる唯一の方法は、自分の名前を前に付けるか、現在のスキーマを自分自身に戻すことです。 .

最初の質問に答えるために、スキーマは常にユーザーと同じ名前を持ちます。したがって、SCOTT がスキーマ X を所有することはできません。スキーマ X はユーザー X によって所有されています。

2 番目の質問に答えると、ユーザーなしでスキーマを作成することは不可能です。

確かに、CREATE SCHEMA コマンドがありますが、これには事前にユーザーを作成する必要があります。実際にはスキーマを作成するのではなく、いくつかのデータベースオブジェクトを作成します。実際には、これは ADD OBJECTS TO SCHEMA コマンドに近いものです。

SQL> conn sys as sysdba
Enter password:
Connected.

SQL> create user x identified by x
  2  default tablespace users quota 10m on users
  3  /

User created.

SQL> grant create session, create table to x
  2  /

Grant succeeded.

SQL> conn x/x
Connected.

SQL> create schema authorization x
  2      create table t1 (id number)
  3      create table t2 (id number)
  4  /

Schema created.

SQL> select table_name from user_tables
  2  /

TABLE_NAME
------------------------------
T1
T2

SQL>

CREATE SCHEMA コマンドはかなり制限されています。テーブル、ビュー、およびインデックスを作成し、オブジェクトに対する権限を付与できます。その利点は、単一のトランザクションで複数のオブジェクトを作成できることです。そのため、1 つのトランザクションが失敗した場合、すべての作成がロールバックされます。これは、各 create ステートメントを個別に実行する場合には不可能です。

「機能ID」について言及するとき、あなたが何を考えているのかわかりません。これは、Oracle の標準機能ではありません。

score 1 · Accepted Answer

これは、所有者とスキーマの違いを定義しません。

しかし、私は N 個のユーザーを作成するという考えに常に苦労してきました..これらの各ユーザーに単一のスキーマを「消費」(別名、使用) させたい場合。

この男はこれを行う方法を示しています (N 人のユーザーがいる...単一のスキーマに「リダイレクト」されます。

彼のコードも貼り付けます。将来、URL リンクが無効になる可能性があるためです。

http://www.oracle-base.com/articles/misc/schema-owners-and-application-users.php

彼には 2 番目の「同義語」アプローチがあります。ただし、CURRENT_SCHEMA バージョンのみを貼り付けています。繰り返しますが、私はこれを信用しません。誰かが「あなたの答えはこのリンクにあります」と言ってブーム、リンクが死んでいるのが嫌いです。:<

................................................................... ....

( http://www.oracle-base.com/articles/misc/schema-owners-and-application-users.phpから)

CURRENT_SCHEMA アプローチ

このメソッドは、CURRENT_SCHEMA セッション属性を使用して、アプリケーションユーザーを正しいスキーマに自動的にポイントします。

まず、スキーマ所有者とアプリケーションユーザーを作成します。

CONN sys/password AS SYSDBA

-- Remove existing users and roles with the same names.
DROP USER schema_owner CASCADE;
DROP USER app_user CASCADE;
DROP ROLE schema_rw_role;
DROP ROLE schema_ro_role;

-- Schema owner.
CREATE USER schema_owner IDENTIFIED BY password
  DEFAULT TABLESPACE users
  TEMPORARY TABLESPACE temp
  QUOTA UNLIMITED ON users;

GRANT CONNECT, CREATE TABLE TO schema_owner;

-- Application user.
CREATE USER app_user IDENTIFIED BY password
  DEFAULT TABLESPACE users
  TEMPORARY TABLESPACE temp;

GRANT CONNECT TO app_user;

アプリケーションユーザーは接続できますが、テーブルスペースのクォータやオブジェクトを作成する権限を持っていないことに注意してください。

次に、読み取り/書き込みアクセスと読み取り専用アクセスを許可するロールをいくつか作成します。

CREATE ROLE schema_rw_role;
CREATE ROLE schema_ro_role;

アプリケーションユーザーにスキーマオブジェクトへの読み取り/書き込みアクセス権を付与したいので、関連するロールを付与します。

GRANT schema_rw_role TO app_user;

アプリケーションユーザーがスキーマ所有者を指すデフォルトスキーマを持っていることを確認する必要があるため、これを行うための AFTER LOGON トリガーを作成します。

CREATE OR REPLACE TRIGGER app_user.after_logon_trg
AFTER LOGON ON app_user.SCHEMA
BEGIN
  DBMS_APPLICATION_INFO.set_module(USER, 'Initialized');
  EXECUTE IMMEDIATE 'ALTER SESSION SET current_schema=SCHEMA_OWNER';
END;
/

これで、スキーマオーナーにオブジェクトを作成する準備が整いました。

CONN schema_owner/password

CREATE TABLE test_tab (
  id          NUMBER,
  description VARCHAR2(50),
  CONSTRAINT test_tab_pk PRIMARY KEY (id)
);

GRANT SELECT ON test_tab TO schema_ro_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON test_tab TO schema_rw_role;

関連するロールに特権がどのように付与されるかに注目してください。これがないと、オブジェクトはアプリケーションユーザーに表示されません。これで、機能するスキーマ所有者とアプリケーションユーザーができました。

SQL> CONN app_user/password
Connected.
SQL> DESC test_tab
 Name                                                  Null?    Type
 ----------------------------------------------------- -------- ------------------------------------
 ID                                                    NOT NULL NUMBER
 DESCRIPTION                                                    VARCHAR2(50)

SQL>

この方法は、アプリケーションユーザーがメインスキーマへの単なる代替エントリポイントであり、独自のオブジェクトを必要としない場合に理想的です。

oracle - Oracleのスキーマ、ユーザー、および機能ID

2 に答える 2

Related

Reference