허접번역이나마 도움이 되었으면 하는맘에 올립니다. 예쁘게 봐주세요. ^^*
==
2.8. schema
PostgreSQL 데이터베이스 클러스터 (Installation)에는, 1개 이상의 이름 첨부 데이터베이스가 포함됩니다. 유저 및 유저그룹은 클러스터 전체로 공유되지만, 다른 데이터는 복수의 데이터베이스간에 공유되지 않습니다. 서버에 접속하고 있는 클라이언트는, 단일 데이터베이스 즉 접속 지정한 데이터베이스 내의 데이터 밖에 액세스 할 수 없습니다.
Note: 클러스터의 유저는, 클러스터내의 모든 데이터베이스에 접근권한을 가지고 있지는 않습니다. 유저 명을 공유한다고 하는 것은, 예를 들어 joe 라고 하는 같은 아이디를 사용하는 다른 사용자가 같은 클러스터내의 2개의 데이터베이스에 존재할 수 없다는 것입니다. 그러나, joe 가 일부의 데이터베이스에만 접근 할 수 있도록 시스템을 구성할 수 있습니다.
데이터베이스에는, 1개 이상의 schema가 포함되어 있으며, schema에는 테이블이 포함됩니다. schema에는, 데이터 형, 함수 및 연산자 등의 다른 오브젝트도 포함됩니다. 같은 오브젝트 명을 복수의 schema에 사용해도 문제가 발생하지 않습니다. 예를 들어, schema1 과 myschema 양쪽 모두의 schema에 mytable 이라고 하는 테이블이 포함되어 있어도 됩니다. schema는 데이터베이스와는 달라 엄격하게 분리되어 있지 않기 때문에, 유저는 권한만 가지고 있으면 접속하고 있는 데이터베이스 내의 어느 schema의 오브젝트라도 접근 할 수 있습니다.
schema를 사용하는 이유.
· 1개의 데이터베이스를 다수의 유저가 서로 간섭하는 일 없이 사용할 수 있도록 하기 위해.
· 관리하기 쉽도록, 데이터베이스 오브젝트를 논리 그룹에 포함하기 위해.
· 서드 파티의 어플리케이션을 다른 schema에 넣는 것으로, 다른 오브젝트의 이름과 충돌하지 않게 하기 위해.
2.8. 1. schema의 작성
schema를 만들려면, CREATE SCHEMA 명령을 사용합니다. schema에 자유롭게 이름을 붙입니다.
예) CREATE SCHEMA myschema;
schema내에 오브젝트를 작성하거나 이것에 접근 하려면, schema명과 테이블 명을 점(마침표)으로 연결하여 씁니다. schema.table
실제로는, 보다 일반적인 이하의 구문 database.schema.table
를 사용할 수도 있지만, 현재 이 구문은 SQL 에 준하기 위해 존재합니다. 구문의 데이터베이스 명은, 접속한 데이터베이스와 같은 이름이어야 합니다.
새로운 schema에 테이블을 만들려면 다음과 같이 합니다. CREATE TABLE myschema.mytable ( ... );
이 방법은, 다음에 설명하는 테이블 변경 명령이나 데이터 접근명령 등, 테이블 명을 필요로 하는 경우 모두 사용할 수 있습니다.
비어있는 schema (모든 오브젝트가 삭제된 schema)를 삭제하려면 다음과 같이 합니다. DROP SCHEMA myschema;
Schema에 포함된 모든 오브젝트와 함께 삭제하려면 다음과 같이 합니다. DROP SCHEMA myschema CASCADE;
다른 유저가 소유하는 schema를 작성하는 구문은 다음과 같습니다. CREATE SCHEMA schemaname AUTHORIZATION username;
schema명은 생략 할 수도 있으며, 그 경우 schema명은 유저명과 같게 됩니다.
pg_ 로 시작되는 schema명은, 시스템에 예약되어 있어 유저가 만들 수 없습니다.
2.8. 2. public schema
지금까지는 schema명을 지정하지 않고 테이블을 만들어 왔습니다. 기본적으로 테이블 (및 다른 오브젝트)을 만들면 자동으로 "public" 이라고 하는 schema에 만들어 집니다. 새로운 데이터베이스에는 모두 "public" 이라는 schema가 포함되어 있습니다. 그래서 아래 2개의 구문은 동일합니다. CREATE TABLE products ( ... );
과 CREATE TABLE public.products ( ... );
2.8. 3. schema 검색 경로
수식 명을 쓰는 것은 시간이 들고, 어느 쪽으로 해도, 어플리케이션에 특정의 schema명을 기입하지 않는 편이 좋습니다. 테이블이 많은 경우, 테이블 명 밖에 갖지 않는 비수식명으로 참조하게 됩니다. 시스템은 검색하는 schema의 리스트인 검색 경로에 따라, 어느 테이블을 가리키고 있는지를 판별합니다. 검색 경로로 최초로 일치되는 테이블이, 해당 테이블이라고 해석됩니다. 검색 경로 내에 일치하는 테이블이 없으면 데이터베이스의 다른 schema내에 일치하는 테이블이 있는 경우에도 에러가 보고됩니다.
검색 경로 최초로 리스트 되는 schema는, 현행 schema로 불립니다. 현행 schema는 검색되는 최초의 schema인 것과 동시에, schema명을 지정하지 않고 CREATE TABLE 명령으로 테이블을 작성했을 경우에 새로운 테이블이 작성되는 schema이기도 합니다.
현행의 검색 경로를 확인하려면 다음의 명령을 사용합니다. SHOW search_path;
기본 설정에서는 다음과 같이 표시됩니다. search_path -------------- $user, public
첫 번째 $user 는 현재 작업중인 유저와 같은 이름의 schema를 검색하는 것을 지정합니다. 그러나 유저 명과 같은 schema는 아직 존재하지 않기 때문에 이 엔트리는 무시됩니다. 두번째는 위에서 설명한 public schema를 참조하고 있습니다.
검색 경로 내에 존재하는 최초의 schema는 신규 오브젝트가 만들어지는 기본 장소가 됩니다. 즉, 오브젝트가 public schema에 만들어 집니다. 오브젝트가, schema 수식 없이 다른 구문으로 참조되는 경우 (데이블 변경, 데이터 변경, 혹은 구문의 명령 등), 일치하는 오브젝트가 발견될 때까지 검색 경로 내에서 탐색됩니다. 그래서 기본 구성에서는, 비 수식의 접근(schema를 지정하지 않았을 경우)은 public schema 밖에 참조할 수 없습니다.
새로운 schema를 경로에 추가하려면 다음과 같이 합니다. SET search_path TO myschema, public;
($user 는 아직 필요 없기 때문에, 여기에서는 생략합니다. ) 그리고 다음과 같이 schema 수식 없이 테이블에 접근합니다. DROP TABLE mytable;
또, myschema 는 경로내의 최초의 schema 이므로, 새로운 오브젝트는 기본적으로 myschema 에 만들어 집니다.
아래와 같이 쓸 수도 있습니다. SET search_path TO myschema;
이와 같이 하면, 이후 schema명 지정 없이 public schema에 접근 할 수가 없게 됩니다. public schema는 기본으로 존재한다고 하는 것 외엔 특별한 의미는 없습니다. 다른 schema와 같이 삭제 할 수도 있습니다.
검색 경로는 데이터형명, 함수 명, 연산자명에 대해서도, 테이블명의 경우와 같이 작동합니다. 데이터 형 및 함수의 이름은, 테이블명과 완전히 똑같이 사용할 수가 있습니다.
2.8. 4. schema 및 권한
유저는, 기본적으로 소유하고 있지 않은 schema의 오브젝트를 볼 수 없습니다. 이러한 오브젝트를 보려면, 그 schema의 소유자로부터 schema의 USAGE 권한을 부여 받아야 합니다. 그 schema내의 오브젝트에 대해 쓰기나 수정, 삭제 등의 작업을 하기 위해선 추가적인 권한이 필요합니다.
다른 유저의 schema내에서 오브젝트를 작성하는 일도 가능하며 CREATE 권한이 필요합니다. public schema에 관해서는 모든 유저가 CREATE 권한을 가지고 있는 것에 주의하세요. 즉, 모든 유저는 그 유저가 접속할 수 있는 임의의 데이터베이스상에 오브젝트를 작성할 수 있습니다. 이것을 원하지 않는다면, CREATE 권한을 취소해야 합니다. REVOKE CREATE ON public FROM PUBLIC;
(첫 번째 "public" 는 schema입니다. 두 번째 "PUBLIC" 는 "모든 유저”를 의미합니다. 최초의 public 는 식별자로, 두번째 PUBLIC 는 예약어(reserved word)이므로, 각각 소문자, 대문자로 표기합니다.
2.8. 5. 시스템 카탈로그 schema
각 데이터베이스에는, public 및 사용자 schema 외에 pg_catalog 가 포함되어 있습니다. pg_catalog schema에는 시스템 테이블과 모든 데이터 형, 함수 및 연산자가 포함되어 있어 항상 검색 경로에 포함되어 있습니다. 경로에 명시적으로 리스트 되어 있지 않은 경우는, 경로의 schema를 검색하기 전에 기본적으로 검색됩니다. 이것에 의해 항상 검색되는 것이 보증됩니다. 그러나, 유저 정의 이름으로 생성한 이름을 오버라이드(override) 하는 경우는, pg_catalog 를 명시적으로 경로 마지막에 둘 수가 있습니다.
PostgreSQL 의 7.3 보다 이전 버전에서는, pg_ 로 시작되는 테이블 명은 예약어 였습니다. 그러나 현재는, 시스템 schema 이외의 schema에도 pg_ 로 시작되는 이름을 붙일 수 있게 되었습니다. 그러나, 이러한 이름은 사용하지 않는 것이 좋습니다. 향후의 버전으로 유저 테이블과 같은 이름의 시스템 카탈로그가 정의되어 충돌하는 사태를 피하기 위해서 입니다. (기본 검색 경로는 유저의 테이블 명에 정의하며, 비 수식의 참조(schema 명을 명시하지 않은 수식)는 시스템 카탈로그로서 해결할 수 있습니다.) 시스템 카탈로그는 향후에도 pg_ 로 시작되는 규칙에 따르므로 유저가 pg_ 를 사용하지 않는 이상 비 수식의 유저 정의 테이블 명이 시스템 카탈로그와 충돌하는 일은 없을 것입니다.
2.8. 6. 사용 패턴
schema는 다양한 방법으로 데이터의 구조에 사용할 수 있습니다. 기본 구성으로 간단하게 지원되는 몇 개의 추천 패턴이 있습니다.
· schema를 작성하지 않는 경우는, 모든 유저가 public schema에 접근 합니다. 이것은 schema를 전혀 사용할 수 없는 상황과 같습니다. 이 설정은 주로 데이터베이스에 접근하는 유저가 1명 또는 2, 3명 정도밖에 없는 경우에 추천 합니다. 또 이 설정에서는, schema를 인식하지 않는 셋툽으로부터의 이행을 용이하게 실시할 수 있습니다.
· 각각의 유저에게, 유저명과 같은 이름의 schema를 작성할 수가 있습니다. 기본 검색 경로가 $user 로 시작되는 것을 이미 알고 있습니다. 즉, 각 유저가 개별의 schema(유저명과 동일한)를 가지고 있으면 기본적으로 각각의 유저 schema에 접근하게 됩니다.
이 설정을 사용하는 경우는, public schema에 대한 접근 권한을 취소해 (또는 public schema를 삭제 해), 유저가 완전하게 자신의 schema 밖에 접근 할 수 없게 할 수도 있습니다.
· 공유 어플리케이션 (공유된 테이블, 서드 파티 제공의 추가 함수 등)을 설치 하려면, 각각 다른 schema에 넣도록 합니다. 또 다른 유저가 이것들에 접근 할 수 있도록 적절한 권한을 부여하는 것을 잊지 않아야 합니다. 권한을 부여함으로써 다른 유저는 추가된 오브젝트를 schema명으로 수식하는 것에 의해 참조하거나 schema를 각각의 경로에 추가하거나 할 수가 있습니다.
2.8. 7. 이식성
SQL 표준에서는, 복수의 유저가 소유하는 1 개의 schema에 들어가 있는 오브젝트라고 하는 개념은 존재하지 않는다. 그 뿐만 아니라, 경우에 따라서는 소유자와 다른 이름의 schema를 작성하는 것이 허가되어 있지 않은 경우도 있습니다.
실제, SQL 표준으로 지정되어 있는 기본 schema 지원만 하고 있는 데이타베이스 시스템에서는, schema라고 하는 개념과 유저라고 하는 개념은 거의 같다. 그 때문에, 수식(?)명과는 username. tablename 이라고 생각하는 유저가 많이 있습니다. PostgreSQL 에 대해서도, 유저 마다 1 개의 schema를 작성하면, 이와 같이 됩니다.
또 SQL 표준에는, public schema라고 하는 개념도 없다. 표준에 최대한 따르기 위해서는, public schema는 사용하지 말던지, 혹은 삭제해 버리는 것을 추천합니다.
물론, schema를 전혀 사용하고 있지 않기도 하고, 또는, 데이타베이스간 액세스를 (경우에 따라서는 제한하기 위한) 허가하는 것에 의해 이름 공간의 사용을 지원하고 있는 SQL 데이타베이스도 있습니다. 이러한 시스템으로 작업할 필요가 있는 경우는, schema를 전혀 사용하지 않게 하는 것으로 최대한의 이식성을 실현할 수 있습니다.
|