Oracle에서 사용자와 스키마의 차이점은 무엇입니까?
답변
에서 톰 질문
스키마는 모든 의도와 목적을위한 스키마로 사용자 계정과 그 안에있는 모든 개체의 모음 인 것으로 간주해야합니다.
SCOTT는 다양한 권한 부여 및 기타 사항이 포함 된 EMP, DEPT 및 BONUS 테이블을 포함하는 스키마입니다.
SYS는 수많은 테이블, 뷰, 그랜트 등을 포함하는 스키마입니다.
SYSTEM은 스키마입니다 …..
기술적으로-스키마는 일반적으로 DDL을 사용하여 생성 된 데이터베이스에서 사용하는 메타 데이터 세트 (데이터 사전)입니다. 스키마는 테이블, 열 및 속성과 같은 데이터베이스의 속성을 정의합니다. 데이터베이스 스키마는 데이터베이스의 데이터에 대한 설명입니다.
답변
문제는 Oracle이 스키마 라는 용어를 일반적으로 의미하는 것과 약간 다르게 사용 한다는 것입니다.
- Oracle의 스키마 (Nebakanezer의 답변에 설명되어 있음) : 기본적으로 사용자 계정이 소유 한 모든 테이블 및 기타 객체 세트, 사용자 계정과 거의 동일
- 일반적으로 스키마 : 주어진 시스템 / 애플리케이션에 대한 데이터베이스를 구성하는 모든 테이블, 프로 시저 등의 집합 ( “개발자가 새 애플리케이션의 스키마에 대해 DBA와 논의해야합니다”)
의미 2의 스키마는 비슷하지만 의미 1의 스키마와는 다릅니다. 예를 들어 여러 DB 계정을 사용하는 응용 프로그램의 경우 의미 2의 스키마는 여러 Oracle 스키마로 구성 될 수 있습니다. :-).
또한 스키마 는 다른 상황 (예 : 수학)에서 상당히 관련이없는 여러 가지를 의미 할 수 있습니다.
오라클은 “스키마”를 오버로드하는 대신 “userarea”또는 “accountobjects”와 같은 용어를 사용해야합니다.
답변
에서 WikiAnswers :
- 스키마는 테이블, 뷰, 시퀀스, 저장 프로 시저, 동의어, 인덱스, 클러스터 및 데이터베이스 링크와 같은 논리적 구조를 포함한 데이터베이스 개체의 모음입니다.
- 사용자는 스키마를 소유합니다.
- 사용자와 스키마의 이름이 동일합니다.
- CREATE USER 명령은 사용자를 작성합니다. 또한 해당 사용자에 대한 스키마를 자동으로 만듭니다.
- CREATE SCHEMA 명령은 “스키마”를 생성하지 않으며, 단일 트랜잭션에서 여러 테이블과 뷰를 작성하고 고유 한 스키마에서 여러 부여를 수행 할 수 있습니다.
- 모든 의도와 목적을 위해 사용자를 스키마로, 스키마를 사용자로 간주 할 수 있습니다.
또한 권한이있는 사용자는 자신이 아닌 다른 스키마의 개체에 액세스 할 수 있습니다.
답변
사용자를 평상시와 같이 (로그인하고 시스템의 일부 객체에 액세스 할 수있는 사용자 이름 / 비밀번호) 스키마를 사용자 홈 디렉토리의 데이터베이스 버전으로 생각하십시오. 사용자 “foo”는 일반적으로 “foo”스키마 아래에 항목을 작성합니다. 예를 들어, 사용자 “foo”가 “bar”테이블을 작성하거나 참조하는 경우 Oracle은 사용자가 “foo.bar”를 의미한다고 가정합니다.
답변
이 답변은 소유자와 스키마의 차이점을 정의하지 않지만 토론에 추가한다고 생각합니다.
나의 작은 생각의 세계에서 :
나는 각 사용자가 단일 스키마를 “소비”(일명 사용)하기를 원하는 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>
이 방법은 응용 프로그램 사용자가 기본 스키마에 대한 대체 진입 점이며 자체 개체가 필요없는 경우에 이상적입니다.
답변
매우 간단합니다.
If USER has OBJECTS
then call it SCHEMA
else
call it USER
end if;
사용자는 다른 사용자가 소유 한 스키마 객체에 액세스 할 수 있습니다.
답변
스키마는 intrest의 아이디어 / 도메인에 대한 DB.objects의 캡슐화이며 한 명의 사용자가 소유합니다. 그런 다음 역할이 억제 된 다른 사용자 / 응용 프로그램에서 공유됩니다. 따라서 사용자는 스키마를 소유 할 필요는 없지만 스키마에는 소유자가 있어야합니다.