Oracle에서 사용자와 스키마의 차이점은 무엇입니까?


314

Oracle에서 사용자와 스키마의 차이점은 무엇입니까?


17
+1 나는 항상 구별에 대해 궁금했습니다 :-/.
sleske 2009

9
모든 의심을 지 웁니다 아래에 흥미로운 기사가있다 : http://radiofreetooting.blogspot.com/2007/02/user-schema.html는
하기 Sandeep JINDAL

9
Oracle 스키마는 Windows OS의 내 문서 폴더와 같습니다. 사용자는 다른 사용자에게 스키마의 내용을 볼 수있는 권한을 부여 할 수 있습니다. Oracle 스키마는 기본적으로 사용자의 작업 공간입니다.
Tarzan

3
또한 DBA에 대한 설명 : dba.stackexchange.com/questions/37012/...를 .

답변:


136

에서 톰 질문

스키마는 모든 의도와 목적을위한 스키마로 사용자 계정과 그 안에있는 모든 개체의 모음 인 것으로 간주해야합니다.

SCOTT는 다양한 권한 부여 및 기타 사항이 포함 된 EMP, DEPT 및 BONUS 테이블을 포함하는 스키마입니다.

SYS는 수많은 테이블, 뷰, 그랜트 등을 포함하는 스키마입니다.

SYSTEM은 스키마입니다 .....

기술적으로-스키마는 일반적으로 DDL을 사용하여 생성 된 데이터베이스에서 사용하는 메타 데이터 세트 (데이터 사전)입니다. 스키마는 테이블, 열 및 속성과 같은 데이터베이스의 속성을 정의합니다. 데이터베이스 스키마는 데이터베이스의 데이터에 대한 설명입니다.


47
같은 페이지에서 : 모든 의도와 목적을 위해 user = schema = user = schema = 같은 것을 고려하십시오.
18:47에

4
그러나 동일한 스키마를 사용하는 두 명의 사용자가 있습니까?
John John Pichler 2016 년

6
"단일 스키마의 객체를 여러 사용자가 '소유'할 수있다"는 의미는 "아니요"입니다. "단일 스키마의 객체를 여러 사용자가 사용할 수 있습니다"라는 대답은 가장 확실합니다.
Mahesh

95

문제는 Oracle이 스키마 라는 용어를 일반적으로 의미하는 것과 약간 다르게 사용 한다는 것입니다.

  1. Oracle의 스키마 (Nebakanezer의 답변에 설명되어 있음) : 기본적으로 사용자 계정이 소유 한 모든 테이블 및 기타 객체 세트, 사용자 계정과 거의 동일
  2. 일반적으로 스키마 : 주어진 시스템 / 애플리케이션에 대한 데이터베이스를 구성하는 모든 테이블, 프로 시저 등의 집합 ( "개발자가 새 애플리케이션의 스키마에 대해 DBA와 논의해야합니다")

의미 2의 스키마는 비슷하지만 의미 1의 스키마와는 다릅니다. 예를 들어 여러 DB 계정을 사용하는 응용 프로그램의 경우 의미 2의 스키마는 여러 Oracle 스키마로 구성 될 수 있습니다. :-).

또한 스키마 는 다른 상황 (예 : 수학)에서 상당히 관련이없는 여러 가지를 의미 할 수 있습니다.

오라클은 "스키마"를 오버로드하는 대신 "userarea"또는 "accountobjects"와 같은 용어를 사용해야합니다.


@djangofan Afaik이 질문은 MS SQL이 아니라 Oracle에 관한 것입니다.
peterh-복 직원 모니카

62

에서 WikiAnswers :

  • 스키마는 테이블, 뷰, 시퀀스, 저장 프로 시저, 동의어, 인덱스, 클러스터 및 데이터베이스 링크와 같은 논리적 구조를 포함한 데이터베이스 개체의 모음입니다.
  • 사용자는 스키마를 소유합니다.
  • 사용자와 스키마의 이름이 동일합니다.
  • CREATE USER 명령은 사용자를 작성합니다. 또한 해당 사용자에 대한 스키마를 자동으로 만듭니다.
  • CREATE SCHEMA 명령은 "스키마"를 생성하지 않으며, 단일 트랜잭션에서 여러 테이블과 뷰를 작성하고 고유 한 스키마에서 여러 부여를 수행 할 수 있습니다.
  • 모든 의도와 목적을 위해 사용자를 스키마로, 스키마를 사용자로 간주 할 수 있습니다.

또한 권한이있는 사용자는 자신이 아닌 다른 스키마의 개체에 액세스 할 수 있습니다.


3
좋은 지적 다시 작성 SCHEMA-내가 생각하는 명령에 대해 잘못 선택된 이름!
Jeffrey Kemp

4
"CREATE SCHEMA 명령은"스키마 "를 의미하지 않습니다." 혼란의 99 %가 이것에서 비롯된 것 같습니다. 그리고이 문장 조각은 그것을 아주 잘 정리합니다. 감사합니다.
granadaCoder


이것이 가장 좋은 대답이라고 생각합니다.
hagrawal

50

사용자를 평상시와 같이 (로그인하고 시스템의 일부 객체에 액세스 할 수있는 사용자 이름 / 비밀번호) 스키마를 사용자 홈 디렉토리의 데이터베이스 버전으로 생각하십시오. 사용자 "foo"는 일반적으로 "foo"스키마 아래에 항목을 작성합니다. 예를 들어, 사용자 "foo"가 "bar"테이블을 작성하거나 참조하는 경우 Oracle은 사용자가 "foo.bar"를 의미한다고 가정합니다.


2
깔끔한 설명이지만 왜 사용자와 스키마 모두에 "foo"를 사용 했습니까?! 그들은 같아야합니까?
JonnyRaa

Oracle에서 USER는 계정 이름이고 SCHEMA는 해당 사용자가 소유 한 오브젝트 세트입니다. 그러나 Oracle은 CREATE USER 문의 일부로 SCHEMA 오브젝트를 작성하고 SCHEMA의 이름은 USER와 동일하지만 동일합니다. 물론 혼동은 USER와 SCHEMA 사이에 일대일 대응이 있고 사용자 스키마가 그 이름을 공유한다는 사실에서 부분적으로 발생합니다.
Mahesh

17

이 답변은 소유자와 스키마의 차이점을 정의하지 않지만 토론에 추가한다고 생각합니다.

나의 작은 생각의 세계에서 :

나는 각 사용자가 단일 스키마를 "소비"(일명 사용)하기를 원하는 N 명의 사용자를 생성한다는 생각으로 어려움을 겪었다.

oracle-base.com의 Tim은이를 수행하는 방법을 보여줍니다 (N 명의 사용자가 있고 각 사용자가 단일 스키마로 "리디렉션 됨").

그는 두 번째 "동의어"접근 방식을 가지고 있습니다 (여기에 나열되지 않음). CURRENT_SCHEMA 버전 (그의 접근법 중 하나) 만 여기에 인용하고 있습니다.

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>

이 방법은 응용 프로그램 사용자가 기본 스키마에 대한 대체 진입 점이며 자체 개체가 필요없는 경우에 이상적입니다.


1
역할을 사용하면 PL / SQL 코드에 대한 권한 문제가 해결되지 않을 수 있습니다. 스토어드 프로 시저가 컴파일 될 때 역할에 대한 오브젝트 부여는 직관적 인 방식으로 전파되지 않습니다. 그러나이 접근법은 실제로 훌륭하기 때문에이 대답을 찬성했지만 내가 알 수있는 한 거의 알려지지 않았으며 거의 ​​사용되지 않았습니다.
Andrew Wolfe

15

매우 간단합니다.

If USER has OBJECTS
then call it SCHEMA
else
     call it USER
end if;

사용자는 다른 사용자가 소유 한 스키마 객체에 액세스 할 수 있습니다.


1
실제로 사람들이 전화를 걸 때 혼란이 발생합니다-사용자는 스키마입니다. 설명했듯이 사용자가 스키마가 아닐 수도 있습니다. 사용자는 다른 사용자 스키마에 액세스하는 사용자 일 수 있습니다.
Sandeep Jindal 2011

3

스키마는 intrest의 아이디어 / 도메인에 대한 DB.objects의 캡슐화이며 한 명의 사용자가 소유합니다. 그런 다음 역할이 억제 된 다른 사용자 / 응용 프로그램에서 공유됩니다. 따라서 사용자는 스키마를 소유 할 필요는 없지만 스키마에는 소유자가 있어야합니다.


1

사용자 계정은 집 열쇠를 가지고 있지만 아무것도 소유하지 않는 친척과 같습니다. 즉, 사용자 계정에 데이터베이스 개체가 없습니다 ... 데이터 사전이 없습니다 ...

스키마는 데이터베이스 개체의 캡슐화입니다. 그것은 집안의 모든 것을 소유하는 집주인과 같으며 사용자 계정은 소유자, 즉 스키마가 필요한 보조금을 줄 때만 집에서 물건에 액세스 할 수 있습니다.


1

--USER 및 SCHEMA

사용자와 스키마라는 단어는 서로 바꿔 사용할 수 있으므로 대부분의 사람들이 아래의 단어에 혼란을 느끼는 이유는 무엇입니까?

--User User는 데이터베이스 (서버)를 연결하는 계정입니다. CREATE USER user_name IDENTIFIED BY password를 사용하여 사용자를 만들 수 있습니다.

--개요

실제로 Oracle Database에는 데이터를 처리하기위한 논리적 및 물리적 구조가 포함되어 있습니다. Schema also Logical Structure는 데이터베이스 (메모리 구성 요소)에서 데이터를 처리합니다. 사용자가 생성 할 때 oracle에 의해 자동으로 생성됩니다 .It is created with all objects when the user created. 해당 스키마와 관련된 사용자가 생성 한 모든 객체를 포함합니다 .For example if you create a user with name santhosh then oracle creates a schema santhosh, oracle은 santhosh라는 사용자가 만든 모든 객체를 santhosh에 저장합니다. 개요.

CREATE SCHEMA 문으로 스키마를 만들 수 있지만 Oracle은 해당 스키마에 대한 사용자를 자동으로 만듭니다.

DROP SCHEMA schama_name RESTRICT 문을 사용하여 스키마를 삭제할 수 있지만 스키마가 포함 된 오브젝트를 삭제할 수 없으므로 스키마를 삭제하려면 비어 있어야합니다. 여기서 제한 단어는 해당 오브젝트가없는 스키마를 강제로 지정합니다.

oracle은 사용자 포함 객체를 삭제할 수 없으므로 사용자 스키마에 사용자 포함 객체를 삭제하려고하면 CASCADE 단어를 지정해야합니다. DROP USER user_name CASCADE는 oracle이 스키마에서 오브젝트를 삭제 한 다음 사용자를 자동으로 삭제합니다.이 스키마를 참조하는 오브젝트는 뷰 및 개인 동의어와 같은 다른 스키마에서 오브젝트가 유효하지 않은 상태가됩니다.

나는 지금 당신이 그들 사이에 차이가 있기를 바랍니다.이 주제에 대해 의심이 있으시면 언제든지 문의하십시오.

감사합니다.


0

스키마와 데이터베이스 사용자는 동일하지만 스키마가 데이터베이스 개체를 소유하고 있고 개체를 수행 할 수 있지만 사용자가 개체에 액세스하는 경우 스키마 사용자가 적절한 권한을 부여 할 때까지 DDL 작업을 수행 할 수 없습니다.


0

Oracle에 대한 저의 작은 지식을 바탕으로 USER와 SCHEMA는 다소 유사합니다. 그러나 큰 차이점도 있습니다. "USER"가 오브젝트를 소유 한 경우 USER를 SCHEMA라고 할 수 있습니다. 그렇지 않으면 ... "USER"만 남습니다. USER가 적어도 하나의 객체를 소유하면 위의 모든 정의를 통해 .... USER를 SCHEMA라고 할 수 있습니다.



0

MariaDB 또는 MySQL에 더 익숙한 대부분의 사람들에게는 MariaDB 또는 MySQL에서 서로 다른 스키마 (다른 테이블, 뷰, PLSQL 블록 및 DB 객체 등 포함)가 있고 USERS는 그에 액세스 할 수있는 계정이기 때문에 혼란스럽지 않습니다. 개요. 따라서 특정 사용자는 특정 스키마에 속할 수 없습니다. 해당 스키마에 권한이 부여되면 사용자가 해당 스키마에 액세스 할 수 있습니다. 사용자와 스키마는 MySQL 및 MariaDB와 같은 데이터베이스로 구분됩니다.

Oracle 스키마와 사용자는 거의 동일하게 취급됩니다. 해당 스키마를 사용하려면 스키마 이름이 사용자 이름 일 뿐이라고 느낄 수있는 권한이 있어야합니다. 여러 스키마에서 다른 데이터베이스 오브젝트에 액세스 할 수있는 권한이 스키마에 부여 될 수 있습니다. 오라클에서는 사용자가 스키마를 소유하고 있다고 말할 수 있습니다. 왜냐하면 사용자를 생성 할 때 이에 대한 DB 객체를 생성하고 그 반대도 마찬가지이기 때문입니다.


-1

스키마는 객체의 컨테이너입니다. 사용자가 소유합니다.


1
이는 사용자가 여러 스키마를 소유 할 수 있음을 의미합니다. 나는 그것이 가능하다고 믿지 않습니다 (Oracle에서). 사용자 A는 스키마에 대한 전체 관리자 권한을 가질 수 있지만 , 그러한 사용자 이름으로 로그인 한 사람이 없더라도 B후자는 항상 사용자 가 소유 합니다 B.

-1

글쎄, 나는 데이터베이스 사용자가 DDL 권한을 가지고 있다면 이것이 스키마이고 그렇지 않으면 사용자라는 것을 읽었다.


이것은 실제로 유용한 구분입니다. CREATE privs가없는 사용자와 CREATE priv가없는 사용자
Andrew Wolfe
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.