PostgreSQL 8.3.3문서
Prev Fast Backward Chapter 5. 데이터 정의 Fast Forward Next

5.7. 스키마

PostgreSQL데이터베이스 클러스터에는 복수의 이름 첨부 데이터베이스가 포함됩니다. 유저 및 유저의 그룹은 클러스터 전체를 공유하지만, 다른 데이터는 데이터베이스 간에 공유되지 않습니다. 서버에 접속하고 있는 클라이언트는 단일의 데이터베이스, 즉 접속 요구로 지정한 데이터베이스 내의 데이터 밖에 액세스 할 수 없습니다.

Note: 클러스터의 유저는 클러스터내의 모든 데이터베이스의 액세스권한을 가지고 있다고는 할 수 없습니다. 유저명을 공유한다고 하는 것은 예를 들면joe라고 하는 같은 유저명을 가지는 다른 유저가 같은 클러스터내의 2개의 데이터베이스에 존재할 수 없다고 하는 것입니다. 그러나 joe가 일부의 데이터베이스만 액세스 할 수 있도록 시스템을 구성할 수 있습니다.

데이터베이스에는 하나 이상의 이름을 가진 schema가 포함합니다. 스키마는 테이블을 포함합니다. 스키마에는 데이터형, 함수 및 연산자 등 다른 이름의 오브젝트도 포함됩니다. 같은 오브젝트명을 다른 schema로 사용해도 모순은 일어나지 않습니다. 예를 들면, schema1와 myschema의 양쪽 스키마에mytable라고 하는 테이블이 포함되어 있어도 상관없습니다. 스키마는 데이터베이스와 달리 엄격하게 분리되어 있지 않기 때문에, 유저는 권한만 가지고 있으면 접속하고 있는 데이터베이스 내의 어느 스키마의 오브젝트라도 액세스 할 수 있습니다.

스키마의 사용이 선호되는 이유는 몇 개인가 있습니다.

스키마는 포함될 수 없다는 점을 제외하고, operating system의 디렉토리와 닮아 있습니다.

5.7.1. 스키마의 작성

스키마를 작성하려면 , CREATE SCHEMA 커맨드를 사용합니다. 스키마에 자유롭게 이름을 붙입니다. 예를 들면, 

CREATE SCHEMA myschema;

스키마 내에 오브젝트를 작성하거나 이것에 액세스 하려면, 스키마 명과 테이블명을 점으로 단락지은수식명을 씁니다. 


schema

.

table

이 방법은 뒷 장에서 설명하는 테이블 변경 커맨드나 데이터 액세스 커맨드 등, 테이블명을 필요로 하는 모든 경우에 사용할 수 있습니다 (간단하게, 테이블만을 이야기 합니다. 그러나 형태나 함수와 같은 이름 붙여진 오브젝트의 다른 종류에 대해 같은 생각을 적용할 수 있습니다).

실제로는 보다 일반적인 이하의 구문 


database

.

schema

.

table

을 사용할 수도 있지만, 현재는 이 구문은형식상표준 SQL에 준거하기 위해 존재하고 있습니다. 기술되는 데이터베이스명은 접속하고 있는 데이터베이스와 같은 이름이어야 합니다.

그러므로, 새로운 스키마에 테이블을 작성하려면 다음과 같이 합니다. 

CREATE TABLE myschema.mytable (
 ...
);

빈 스키마(모든 오브젝트가 삭제된 스키마)를 삭제하려면 다음과 같이 합니다. 

DROP SCHEMA myschema;

오브젝트를 포함한 스키마를 삭제하는 경우에는 다음과 같이 합니다. 

DROP SCHEMA myschema CASCADE;

이 배후에 있는 일반적인 매커니즘에 대한 자세한 사항은 Section 5.11을 참조해 주십시요.

다른 유저가 소유하기 위한 스키마를 작성하고 싶은 경우가 있습니다(이것은 다른 유저의 활동을 명확하게 정의한 이름 공간내에 제한하는 방법의 하나입니다). 그 때의 쿼리 구문은 다음과 같습니다. 

CREATE SCHEMA 
schemaname
 AUTHORIZATION 
username
;

스키마 이름을 생각할 수 있습니다. 이 경우, 스키마 이름은 유저명과 동일해 집니다. Section 5.7.6를 참조하여, 이것이 어떻게 유용하게 사용될 수 있는지 살펴보십시요.

pg_로 시작되는 스키마 명은 시스템 상의 사용을 위해 예약되었기 때문에, 유저가 작성할 수 없습니다.

5.7.2. 공용 스키마

이전까지는 스키마 명을 지정하지 않고 테이블을 작성해 왔습니다. 디폴트에서는 이러한 테이블(및 다른 오브젝트)은 자동으로"public"라는 이름의 스키마에 넣어집니다. 새로운 데이터베이스에는 모두 이러한 스키마가 포함되어 있습니다. 그 때문에, 이하의 2개의 구문은 동등합니다. 

CREATE TABLE products ( ... );

and 

CREATE TABLE public.products ( ... );

5.7.3. 스키마 검색 경로

수식명을 쓰는 것은 시간이 들고, 어느 쪽으로 해도, 어플리케이션에 특정한 스키마 명을 기입하지 않는 것이 좋은 일이 많습니다. 그 때문에, 테이블은 많은 경우, 테이블명 밖에 가지지 않는 비수식명으로서 참조됩니다. 시스템은 검색하는 스키마의 리스트인검색 경로에 따라, 어느 테이블을 가리키고 있는지를 판별합니다. 검색 경로에서 최초로 일치한 테이블이, 원하는 테이블이라고 해석됩니다. 검색 경로내에 일치하는 테이블이 없거나 데이터베이스의 다른 스키마 내에 일치하는 테이블이 있는 경우에서도 에러가 보고됩니다.

검색 경로의 최초로 호출된 스키마는 최근 스키마(the current schema)라고 불립니다. 최근 스키마는 검색되는 최초의 스키마이면서 스키마를 지정하지 않고CREATE TABLE커맨드로 테이블을 작성했을 경우, 새로운 테이블이 작성되는 스키마이기도 합니다.

최근 검색 경로를 나타내려면 다음의 커맨드를 사용합니다. 

SHOW search_path;

디폴트의 설정에서는 다음과 같이 돌려주어집니다. 

 search_path
--------------
 "$user",public

최초 요소는 현재 유저와 같은 이름의 스키마를 검색하도록 지정하고 있습니다. 그러한 스키마가 존재하지 않는 경우, 이 항목은 무시됩니다. 2번째의 요소는 방금 전 설명한 공용 스키마를 참조하고 있습니다.

검색 경로내에서 최초로 존재하는 스키마가, 신규 오브젝트가 작성되는 디폴트의 장소가 됩니다. 이것이, 디폴트로 오브젝트가 공용 스키마에 작성되는 이유입니다. 오브젝트가 스키마 수식없이 다른 문맥으로 참조되는 경우(테이블 간의 변경, 데이터 변경, 혹은 쿼리 커맨드 등), 일치하는 오브젝트가 발견될 때까지 검색 경로내에서 탐색됩니다. 그 때문에 디폴트 구성에서는 비수식의 액세스는 공용 스키마 밖에 참조할 수 없습니다.

새로운 스키마를 경로에 추가하려면 다음과 같이 합니다. 

SET search_path TO myschema,public;

($user는 아직 필요하지 않기 때문에, 여기에서는 생략 하고 있습니다. ) 그리고 다음과 같이 스키마 수식없이 테이블에 액세스 합니다. 

DROP TABLE mytable;

또한, myschema는 경로의 최초 요소이므로, 새로운 오브젝트는 디폴트로 여기에 작성됩니다.

이하와 같이 쓸 수도 있습니다. 

SET search_path TO myschema;

이와 같이 하면, 더이상 수식명없이 공용 스키마에 액세스 할 수 없게 됩니다. 공용 스키마는 디폴트로 존재한다고 하는 것 이외에 특별한 의미는 없습니다. 다른 스키마와 같이 삭제할 수도 있습니다.

스키마 검색 경로를 조작하는 다른 방법은 Section 9.19을 참조해 주십시요.

검색 경로는 데이터형명, 함수명, 연산자명에 대해서도, 테이블명의 경우와 같이 기능합니다. 데이터형 및 함수의 이름은 테이블명과 완전히 똑같이 수식할 수 있습니다. 식에서 수식 연산자명을 쓰는 경우에는 특별한 결정이 있습니다. 그것은 이하와 같습니다. 

OPERATOR(

schema

.

operator

)

이 규칙은 구문이 애매하게 되는 것을 막기 위한 것입니다. 이하에 예를 들면, 

SELECT 3 OPERATOR(pg_catalog.+) 4;

실제에서 이러한 보기 힘든 구문을 쓰지 않아도 되도록, 연산자에 대해서도 검색 경로가 사용되고 있습니다.

5.7.4. 스키마 및 권한

유저는 디폴트에서는 소유하고 있지 않는 스키마의 오브젝트를 액세스 할 수 없습니다. 액세스 하기 위해서는 그 스키마의 소유자로부터 스키마의USAGE권한을 부여받을 필요가 있습니다. 그 스키마내의 오브젝트에 대해서 조작을 실시하려면, 추가적인 권한이 필요한 경우가 있습니다.

다른 유저의 스키마 내에서 오브젝트를 작성하는 일도 가능합니다. 거기에는 스키마에서 부여된 CREATE권한이 있어야 합니다. 디폴트에서 public 스키마에 관해서는 모든 유저가CREATE와 USAGE권한을 가지고 있는 것을 주의하십시요. 즉, 모든 유저는 그 유저가 접속할 수 있는 임의의 데이터베이스의 public스키마에 오브젝트를 작성할 수 있다는 것입니다. 이것이 바람직하지 않은 경우는 이하와 같이 권한을 취소할 수 있습니다. 

REVOKE CREATE ON SCHEMA public FROM PUBLIC;

(최초의"public"는 스키마입니다. 2번째의"public"는 "모든 유저"를 의미합니다. 최초의 public는 식별자로, 2번째의 public는 키워드이므로, 각각 소문자, 대문자를 사용하고 있습니다. Section 4.1.1의 가이드 라인을 생각해 주십시요. )

5.7.5. 시스템 카탈로그 schema

각 데이터베이스에는 public및 유저 작성의 스키마 외에pg_catalog스키마가 포함되어 있습니다. 이 스키마에는 시스템 테이블과 모든 내장 데이터형, 함수 및 연산자가 포함되어 있습니다. pg_catalog는 항상 검색 경로에 포함되어 있습니다. 경로에 명시적으로 리스트되어 있지 않은 경우는 경로의 스키마를 검색하기 전 에 암묵적으로 검색됩니다. 이것에 의해 내장 이름이 항상 검색되는 것이 보증됩니다. 그러나 유저 정의 이름으로 내장의 이름을 덧쓰기하는 경우는 pg_catalog를 명시적으로 경로의 마지막에 둘 수 있습니다.

PostgreSQL의 7.3 이전 버전에서 pg_로 시작되는 테이블명은 예약되어 있었습니다. 그러나 현재는 변경되어 시스템 스키마 이외의 스키마에도pg_로 시작되는 이름을 붙일 수 있게 되었습니다. 다만, 이러한 이름은 사용하지 않는 것이 유리하다고 말할 수 있습니다. 향후 버전에서 유저 테이블과 같은 이름의 시스템 카탈로그가 정의되어 충돌하는 사태를 피하기 위해서 입니다. (디폴트 검색 경로를 통해 유저의 테이블명에 비수식의 참조가 시스템 카탈로그로서 해결되게 됩니다). 시스템 카탈로그는 계속해서 pg_로 시작되는 규칙을 따를 것이므로, 유저가 pg_ 라고 하는 접두사를 사용하지 않는 이상 비수식의 유저 정의 테이블명이 시스템 카탈로그와 충돌하지 않을 것입니다.

5.7.6. 사용 패턴

스키마는 여러가지 방법으로 데이터의 편성에 사용할 수 있습니다. 디폴트 구성으로 간단하게 서포트할 수 있는 추천의 사용 패턴이 몇 개 있습니다.

5.7.7. 이식성

표준 SQL에서는 다른 유저가 소유하는 같은 스키마의 오브젝트라는 개념은 존재하지 않습니다. 그 뿐만 아니라, 실행에 따라서는 소유자와 다른 이름의 스키마를 작성하는 것이 허가되어 있지 않은 경우도 있습니다. 실제, 표준으로 규정되고 있는 기본 스키마 서포트만을 실행하고 있는 데이터베이스 시스템에서는 스키마라고 하는 개념과 유저라고 하는 개념은 거의 같습니다. 그 때문에, 수식명이 username . tablename 의 구성이라고 생각하는 유저가 많이 있습니다. PostgreSQL에 대해도, 유저마다 1개의 스키마를 작성하면, 이와 같이 됩니다.

또한, 표준 SQL에는 public스키마라고 하는 개념도 없습니다. 표준에 최대한 따르기 위해서는 public스키마는 사용해야 하지는 않습니다(아마 삭제하는 것이 좋을지도 모릅니다).

물론, 스키마를 전혀 실행하지 않기도 하고, 또는 데이터베이스간 액세스를(경우에 따라서는 제한되어) 제공하도록 허가하는 이름 공간의 사용을 서포트하는 SQL 데이터베이스도 있습니다. 이러한 시스템으로 작업할 필요가 있는 경우는 스키마를 전혀 사용하지 않게 하는 것으로 최대한의 이식성을 실현할 수 있습니다.

Prev Home Next
권한 Up 상속