Oracle 사용자와 스키마의 차이점
Oracle에서 사용자와 스키마의 차이점은 무엇입니까?
톰에게 묻다
스키마는 사용자 계정이며 스키마에 포함된 모든 개체의 컬렉션을 모든 목적과 목적을 위한 스키마로 간주해야 합니다.
SCORT는 EMP, DEPT 및 BONS 테이블과 다양한 보조금 등을 포함하는 스키마입니다.
SYS는 수많은 테이블, 뷰, 인가 등을 포함하는 스키마입니다.
SYSTEM은 스키마입니다.....
기술적으로 - 스키마는 데이터베이스에서 사용하는 메타데이터(데이터 사전) 집합이며, 일반적으로 DDL을 사용하여 생성됩니다. 스키마는 테이블, 열 및 등록 정보와 같은 데이터베이스의 속성을 정의합니다.데이터베이스 스키마는 데이터베이스의 데이터에 대한 설명입니다.
문제는 Oracle이 스키마라는 용어를 일반적으로 사용하는 것과 약간 다르다는 것입니다.
- Oracle의 스키마(Nebakanezer의 답변에서 설명됨): 기본적으로 사용자 계정에 의해 소유되는 모든 테이블 및 기타 객체의 집합이므로 사용자 계정과 거의 동일합니다.
- 스키마 전반:특정 시스템/애플리케이션의 데이터베이스를 구성하는 모든 테이블, sprocs 등의 세트('개발자는 새로운 어플리케이션의 스키마에 대해 DBA와 논의해야 합니다.")
2의 스키마는 1의 스키마와 비슷하지만 동일하지는 않습니다. 예를 들어 여러 DB 계정을 사용하는 응용 프로그램의 경우 2의 스키마는 여러 Oracle 스키마:-)로 구성될 수 있습니다.
또한 스키마는 다른 맥락(예: 수학)에서 상당히 관련이 없는 다른 많은 것들을 의미할 수 있습니다.
Oracle은 "schema"가 아닌 "userarea" 또는 "accountobjects"와 같은 용어를 사용해야 합니다.
WikiAnswers에서:
- 스키마는 테이블, 뷰, 시퀀스, 저장 프로시저, 동의어, 인덱스, 클러스터 및 데이터베이스 링크와 같은 논리 구조를 포함하는 데이터베이스 개체의 모음입니다.
- 사용자가 스키마를 소유합니다.
- 사용자와 스키마의 이름은 동일합니다.
- CREATE USER 명령은 사용자를 생성합니다.또한 해당 사용자의 스키마도 자동으로 생성됩니다.
- CREATE SCHEMA 명령은 암시하는 것처럼 "schema"를 생성하는 것이 아니라 여러 테이블과 뷰를 생성하고 단일 트랜잭션에서 자신의 스키마에서 여러 개의 인가를 수행할 수 있도록 합니다.
- 사용자를 스키마로 간주하고 스키마를 사용자로 간주할 수 있습니다.
또한 사용자는 권한이 있는 경우 자신의 스키마 이외의 스키마 내의 개체에 액세스할 수 있습니다.
사용자(시스템 내 일부 개체에 로그인하고 액세스할 수 있는 권한이 있는 사용자 이름/비밀번호)와 스키마를 사용자의 홈 디렉토리의 데이터베이스 버전으로 간주합니다.사용자 "foo"는 일반적으로 스키마 "foo" 아래에 내용을 작성합니다.예를 들어 사용자 "foo"가 테이블 "bar"를 작성하거나 참조하는 경우 Oracle은 사용자가 "foo.bar"를 의미한다고 가정합니다.
이 답변은 소유자와 스키마의 차이를 정의하지 않지만 논의를 더하는 것 같습니다.
내 작은 생각의 세계에서는:
각 사용자가 단일 스키마를 "소비"(일명 "사용")하도록 N명의 사용자를 생성해야 한다는 생각에 어려움을 겪어 왔습니다.
oracle-base.com의 Tim은 이 방법을 보여줍니다(N명의 사용자가 있으며 각 사용자는 단일 스키마에 "연결"됩니다).
그는 두 번째 "동음이의" 접근 방식을 가지고 있다(여기에는 나열되지 않음).여기서는 CURRENT_SCHEMA 버전(그의 접근 방식 중 하나)을 인용합니다.
CURRENT_SCHEMA
★★★에서는 " " 를 합니다.
CURRENT_SCHEMA
session Attribute를 사용하여 응용 프로그램 사용자에게 올바른 스키마를 자동으로 지정합니다.먼저 스키마 소유자와 애플리케이션 사용자를 만듭니다.
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;
사용자는 서로 다른 사용자가 소유한 스키마 개체에 액세스할 수 있습니다.
Schema는 intrest의 아이디어/도메인에 관한 DB.objects를 캡슐화한 것으로 ONE 사용자가 소유하고 있습니다.그런 다음 역할이 억제된 다른 사용자/애플리케이션에 의해 공유됩니다.따라서 사용자는 스키마를 소유할 필요가 없으며 스키마에는 소유자가 있어야 합니다.
--사용자 및 스키마
사용자와 스키마라는 단어는 서로 교환이 가능하기 때문에 대부분의 사람들이 아래의 단어에 대해 혼동하는 이유를 설명했습니다.
--User User는 데이터베이스(서버)에 접속하기 위한 계정입니다.CREATE USER user_name IDENTED BY password를 사용하여 사용자를 생성할 수 있습니다.
- 스키마
실제로 Oracle Database에는 데이터를 처리하기 위한 논리적 및 물리적 스트러커처가 포함되어 있습니다.데이터베이스(메모리 컴포넌트)의 데이터를 처리하기 위한 스키마도 논리 구조입니다.사용자가 생성할 때 Oracle에 의해 자동으로 생성됩니다.이 파일에는 해당 스키마에 연결된 사용자가 만든 모든 개체가 포함됩니다.예를 들어, 내가 santhosh라는 이름의 사용자를 만든 경우 oracle은 santhosh라는 스키마를 만들고 oracle은 사용자 santhosh가 작성한 모든 개체를 santhosh 스키마에 저장합니다.
CREATE SCHEMA 문을 사용하여 스키마를 만들 수 있지만 Oracle은 자동으로 해당 스키마의 사용자를 만듭니다.
DROP SCHEMA schama_name RESTRICT 문을 사용하여 스키마를 드롭할 수 있지만 scehema가 포함된 개체를 삭제할 수 없으므로 스키마를 드롭하려면 스키마를 비워 두어야 합니다.여기서 restrict 단어는 out 객체가 있는 스키마를 강제로 지정합니다.
oracle에서는 사용자 포함 개체를 삭제할 수 없기 때문에 스키마 내의 개체를 포함하는 사용자를 삭제하려고 할 경우 CASCADE 단어를 지정해야 합니다.DROP USER user_name CASCADE를 사용하면 oracle은 스키마 내의 객체를 삭제하고 사용자를 자동으로 드롭합니다.이 스키마 오브젝트를 참조하는 오브젝트는 뷰나 개인 동의어 등의 다른 스키마에서 비활성화 상태가 됩니다.
나는 당신이 이제 그들 사이의 차이를 알았기를 바라며, 만약 당신이 이 주제에 대해 의문점이 있다면, 주저하지 말고 물어보세요.
감사해요.
사용자 계정은 집에 대한 키를 가지고 있지만 소유하는 것은 아무것도 없는 친척과 같습니다. 즉, 사용자 계정은 데이터베이스 개체를 소유하지 않습니다. 데이터 사전이 없습니다.
반면 스키마는 데이터베이스 개체의 캡슐화입니다.그것은 당신의 집에 있는 모든 것을 소유하고 있는 집의 소유자와 같은 것이고, 사용자 계정은 소유자가 필요한 보조금을 줄 때만 집의 상품에 접근할 수 있을 것이다.
스키마와 데이터베이스 사용자는 동일하지만 스키마가 데이터베이스 개체를 소유하여 사용자가 개체에 액세스하는 것만으로 모든 작업을 수행할 수 있는 경우 스키마 사용자가 적절한 권한을 부여할 때까지 DDL 작업을 수행할 수 없습니다.
오라클에 대한 나의 작은 지식을 바탕으로...USER와 SCHEMA는 다소 유사합니다.하지만 큰 차이도 있다."USER"가 개체를 소유하면 사용자를 스키마라고 부를 수 있습니다. 그렇지 않으면...「USER」만 남습니다.사용자가 적어도 하나의 개체를 소유하면 위의 모든 정의에 따라...USER를 SCHEMA라고 부를 수 있게 되었습니다.
사용자: 데이터베이스 리소스에 액세스합니다.집에 들어갈 수 있는 열쇠처럼요.
스키마: 데이터베이스 개체에 대한 정보 모음입니다.장에 대한 짧은 정보가 들어 있는 책의 색인처럼.
MariaDB 또는 MySQL에 대해 더 잘 알고 있는 대부분의 사람들에게 이것은 조금 혼란스러운 것처럼 보입니다. 왜냐하면 MariaDB 또는 MySQL에서는 스키마가 서로 다른(다른 테이블, 뷰, PLSQL 블록 및 DB 객체 등을 포함) 스키마가 있고 USER가 이러한 스키마에 액세스할 수 있는 계정이기 때문입니다.따라서 특정 사용자가 특정 스키마에 속할 수 없습니다.해당 스키마에 권한을 부여해야 사용자가 스키마에 액세스할 수 있습니다.사용자와 스키마는 MySQL 및 MariaDB와 같은 데이터베이스로 구분됩니다.
Oracle 스키마와 사용자는 거의 동일하게 취급됩니다.해당 스키마를 사용하려면 사용 권한이 있어야 합니다. 여기서 스키마 이름은 사용자 이름일 뿐입니다.스키마 간에 서로 다른 스키마의 서로 다른 데이터베이스 개체에 액세스할 수 있는 권한을 부여할 수 있습니다.Oracle에서는 사용자가 스키마를 소유하고 있다고 말할 수 있습니다.사용자를 작성할 때 스키마의 DB 오브젝트를 작성하거나 그 반대도 마찬가지이기 때문입니다.
스키마는 개체의 컨테이너입니다.사용자가 소유하고 있습니다.
데이터베이스 사용자가 DDL 권한을 가지고 있으면 스키마이고 그렇지 않으면 사용자라고 읽었습니다.
언급URL : https://stackoverflow.com/questions/880230/difference-between-a-user-and-a-schema-in-oracle
'sourcecode' 카테고리의 다른 글
Wordpress - 메타 필드 내용을 기반으로 게시물을 가져옵니다. (0) | 2023.03.05 |
---|---|
스프링 부트 버전 관리 규약이란 무엇입니까? (0) | 2023.03.05 |
credentials를 사용한Http 요청은 무엇이며 왜 사용하는가? (0) | 2023.03.05 |
Json을 사용하여 이종 JSON 어레이를 공변량 목록으로 역직렬화 <>.그물 (0) | 2023.03.05 |
빈 등록 httpSessionManager가 중복되어 Spring Boot 2.1에서 Keycloak을 사용할 수 없습니다. (0) | 2023.03.05 |