0. 시작하면서.

7.2.x 버전에서 7.3 버전으로 바뀌면서 새롭게 등장한 개념이 SCHEMA 개념입니다. (일단 일반적인 테이블 구조를 뜻하는 스키마와 구분하기 위해서, 영문 대문자로 표기하는 SCHEMA는 PostgreSQL에서 새로 등장한 SCHEMA를 뜻합니다, 읽으실 때 혼돈 없으시길)

SCHEMA는 가장 정확한 한국어 번역으로 '이름공간'(namespace) 입니다. - 개인적으로 이놈을 왜 SCHEMA로 했는지 이해가 안가고 있습니다. 그냥 직관적인 namespace로 할 것이지, 아무튼 내부적으로는 namespace로 처리됩니다. 시스템 카타로그 테이블명이 pg_namespace입니다. 이곳에서 SCHEMA 정보를 관리합니다.

1. SCHEMA 도입 배경.

오라클을 사용해 보신 분은 아시겠지만, 오라클은 하나의 DATABASE를 여러명의 사용자가 사용하면서, 각 사용자들이 만들어내는 객체들(TABLE, VIEW ....)들의 독립성을 보장하기 위해서, PostgreSQL의 SCHEMA 개념이 오래전부터 사용되었습니다. (정확히 언제부터 사용되었는지는 모릅니다) 아무튼 오라클은 디폴트로 하나의 데이터베이스가 만들어지고, 그 안에서 사용자가 만들어지면, 그 사용자만의 독립이름공간인 SCHEMA를 자동으로 생성하고, 그 사용자는 디폴트로 그 공간 안에서만 객체를 만들고 이용할 수 있도록 합니다. - 물론 GRANT 명령으로 SCHEMA를 넘나드는 작업도 하겠지만.

아무튼 윗글의 요지는 하나의 데이터베이스 안에서 여러사용자가 함께 사용할 때, 각 사용자들의 자료에 대한 독립성을 부여하기 위해서 SCHEMA 개념이 도입되었습니다. 즉, 똑같은 테이블명이 하나의 데이터베이스안에 사용자별로 여러개가 존재할 수 있도록 하자는데 그 출발점을 둡니다.

물론 엄격히 말해서, 굳이 사용자와 SCHEMA를 1:1 관계로 볼 필요도 없습니다. 하나의 사용자가 당연히 여러개의 SCHEMA를 가질 수도 있으니.

SCHEMA 개념이 도입되었다는 것은 좀더 오라클 다워졌다(?)는 것을 의미하기도 하는 샘이지요.

하지만, MySQL의 database_name.table_name 형태의 테이블 참조와는 모양새는 같지만 의미가 전혀 다릅니다. 차라리, 오라클의 user_name.table_name 의 의미가 더 강합니다.

2. SCHEMA의 필요성

지금까지 잘 해왔는데, 이놈이 왜 필요한가?

바로, 이럴 때 필요합니다. 참하게 움직입니다.

사무용 자료구조일 경우.

기존 테이블 명이

영업부_지출수입장부

경리부_지출수입장부

경리부에서는 특별히 지정하지 않는한 영업부 관련을 전혀 볼 필요가 없음에도 불구하고, 영업부_지출수입장부 정보가 노출되어있습니다.

이런 경우, 영업부, 경리부 두개의 SCHEMA가 존재하고,

각각 '지출수입장부'로 각각의 SCHEMA에 종속적인 테이블을 만들어낸다면, 윗 문제를 깔끔하게 처리할 수 있겠지요.

마치 데이터베이스를 독립적으로 사용하지 않고도, 아울러 새로운 DB Connection을 하지 않고도 하나의 쿼리에서 두개의 테이블 JOIN도 가능하겠지요.

3. PostgreSQL의 SCHEMA

새롭게 등장했으니, 이제부터라도 써 먹어 보겠다면,

기억해 두셔야할 것은,

1) 자동으로 사용자 단위의 SCHEMA가 만들어지지는 않는다.

2) CREATE DATABASE 권한을 가진 사용자나 그 DATABASE 소유주만 SCHEMA를 만들 수 있다.

3) 현재는(7.3 버전) SCHEMA 안에 둘수 있는 것이 TABLE, VIEW 두개 뿐이다.

4) SCHEMA의 접근권한과 그 안에 속한 테이블의 접근권한은 독립적이다.

네가지 정도인것 같네요.

일단 새로 만들어질 자료구조가 SCHEMA 기반으로 움직일 것이라면, DATABASE를 만든 다음 해야할 작업이 바로 SCHEMA 만들기입니다.

일반적으로 스키마 이름은 사용자이름과 동일한 것으로 만듭니다.

한 사용자가 디폴트로 사용하는 SCHEMA 이름은 사용자이름과 같은 것을 먼저 찾습니다. 없으면, public SCHEMA를 (DATABASE가 만들어지면, 자동으로 public 이라는 SCHEMA를 만듭니다. 7.2.x 이하 버전에서의 일반적인 DATABASE 구조인 샘이지요)

SCHEMA가 만들어지면, 다음은 그 SCHEMA의 접근 권한을 지정합니다. 소유주 사용자 외 다른 사용자들이 새로 만든 이 SCHEMA에 속한 객체들을 참조 할 수 있도록 할 것인지 말것인지.

(GRANT 명령 참조)

접근권한 설정이 끝나면, 다음부터 기존해 해 왔던대로 테이블을 만들고, 사용자의 접근권한을 설정하고.......

4. SCHEMA 접근 방법

select * from schema_name.table_name

이런식입니다, Oracle이나, MySQL을 사용해 보신분이라면, 크게 낯선 방식도 아니지요.

물론 자기가 사용할 디폴트 SCHEMA 이름을 지정안해도 되고요.

5. 글 마치며

개인적으로 스키마라는 놈이 도입될 것이다라는 글을 읽고 내심 데이터베이스간의 자료구조 설계 자체를 우째 재활용하는 것이 아닐까 기대했었는데, 그건 아니고, 오라클 비슷하게 움직이려고 만든 놈이였더군요. (기대에 대한 실망을 ... )

아무튼 차근하게 바른길(?)을 따라가며, 움직여지는 PostgreSQL 놈은 저에게 있어 언제나 멋진놈입니다. :)

8.x 대 버전에서 tablespace 개념과 undo, redo 기능이 도입되길 바라며..