블로그 작성 배경
Oracle와 PostgreSQL에서의 스키마는 데이터베이스 객체의 저장 및 관리에 있어 중요한 개념으로, 두 DBMS가 각각 다르게 구현하고 있기 때문에 이를 이해하는 것이 중요합니다. 이 글에서는 Oracle과 PostgreSQL에서 스키마가 어떻게 다른지, 그리고 그 차이가 데이터베이스 관리에 어떤 영향을 미치는지 심도 있게 설명하겠습니다.
이번 글은 스키마에 대한 내용을 다루지만 다음 글에는 테이블스페이스에 대해서 다룰 것입니다.
1. 스키마 (Schema)
0. 스키마란?
Oracle과 PostgreSQL의 차이점을 탐구하기 전에, 스키마의 일반적인 정의를 간단히 살펴보겠습니다. 데이터베이스 시스템에서 스키마는 일반적으로 테이블, 뷰, 인덱스 및 프로시저와 같은 데이터베이스 객체의 집합을 나타냅니다. 스키마는 이러한 객체에 대한 네임스페이스를 제공하여 각 객체가 해당 공간 내에서 고유하게 식별되도록 합니다.
Oracle과 PostgreSQL은 많은 유사한 개념을 공유하지만, 근본적인 차이가 있습니다. 그 중 하나가 바로 스키마입니다.
Oracle과 PostgreSQL 모두 스키마를 객체를 구성하는 메커니즘으로 제공하지만, 사용자와의 상호작용, 접근 제어 및 객체 관리 방식에는 상당한 차이가 있습니다.
Oracle에서 "스키마"라는 용어는 사용자 개념과 밀접하게 연결되어 있지만, PostgreSQL에서는 스키마가 다소 다른 역할을 합니다. 사용자와 스키마 간의 일대일 관계에 익숙한 Oracle 사용자에게 이는 혼란을 줄 수 있습니다.
이 글에서는 Oracle과 PostgreSQL 간의 스키마 사용 차이점을 깊이 있게 살펴보고, 이들이 어떻게 구조화되고 사용되는지, PostgreSQL 스키마를 효과적으로 활용하여 데이터베이스 관리 능력을 향상시키는 방법에 대해 설명하겠습니다.
글의 순서는 Oracle에서 스키마가 어떻게 작동하는지 검토한 후, PostgreSQL이 스키마를 다르게 처리하는 방법을 살펴보겠습니다.
1. Oracle의 스키마: 사용자 중심 모델
스키마는 사용자와 동의어
Oracle에서 스키마는 본질적으로 사용자 계정과 동등합니다. 사용자가 Oracle에서 생성될 때, 해당 사용자에 대한 스키마가 자동으로 생성됩니다. 이 스키마는 해당 사용자가 소유한 모든 객체(테이블, 뷰, 인덱스 등)를 포함합니다. 따라서 Oracle 데이터베이스에서는 사용자와 스키마 간에 일대일 관계가 있습니다.
이 구조는 각 사용자가 데이터베이스 내에서 자신의 작업 공간을 갖게 하며, 그들이 생성하는 모든 객체는 자신의 스키마 내에 저장됩니다. 사용자와 스키마 간의 긴밀한 결합은 접근 제어를 단순화하며, 스키마를 소유한 사용자만 해당 스키마의 객체에 접근하고 수정할 수 있습니다. 다른 사용자에게 명시적인 권한을 부여하지 않는 한, 객체에 접근할 수 없습니다.
예를 들어, SEHYUN이라는 사용자가 EMPLOYEES 테이블을 소유하고 있을 때, 이 테이블의 전체 이름은 SEHYUN.EMPLOYEES가 됩니다. 여기서 SEHYUN은 사용자이자 해당 스키마의 소유자이며, EMPLOYEES는 그 스키마 내의 테이블 객체입니다.
사용자-스키마 분리: 주요 제한사항
Oracle의 사용자-스키마 관계는 여러 사용자가 동일한 데이터베이스 객체 세트에서 작업해야 하는 환경에서 몇 가지 제한을 나타냅니다. 각 사용자에게 고유한 스키마가 있기 때문에, 사용자 간에 객체를 공유하는 것은 번거로울 수 있습니다. 예를 들어, 여러 사용자가 SEHYUN.EMPLOYEES 테이블에 접근해야 하는 경우, 각 사용자에게 명시적인 권한을 부여해야 하거나, 객체를 참조할 때 스키마를 포함하지 않고도 사용할 수 있도록 동의어를 사용해야 합니다.
이 제한은 사용자 수와 공유 객체가 증가할수록 보다 복잡한 접근 제어 메커니즘 및 객체 관리로 이어질 수 있습니다. 또한, Oracle에서의 스키마 설계 및 데이터베이스 조직은 사용자 계정을 중심으로 이루어지므로, 특정 사용자가 아닌 부서, 팀 또는 애플리케이션에 속하는 객체를 다루기에는 유연성이 떨어집니다.
2. PostgreSQL의 스키마: 유연한 네임스페이스 모델
스키마는 네임스페이스
PostgreSQL에서 스키마는 데이터베이스 내의 논리적 네임스페이스로 작용하며, 특정 사용자와 직접 연결되지 않습니다. 이 구별은 중요합니다. Oracle에서는 각 사용자가 스키마를 소유하지만, PostgreSQL은 동일한 데이터베이스 내에 여러 스키마를 생성할 수 있으며, 이 스키마에는 서로 다른 사용자가 소유한 객체가 포함될 수 있습니다.
PostgreSQL에서 스키마에 대한 이러한 유연한 접근 방식은 보다 확장 가능하고 모듈화된 조직 수준을 제공합니다. PostgreSQL의 스키마는 관련된 객체를 그룹화하는 폴더 또는 컨테이너로 생각할 수 있습니다. 이를 통해 같은 데이터베이스 내에서 기능, 부서 또는 애플리케이션별로 객체를 조직하기가 용이해집니다.
예를 들어, 인사 관리 애플리케이션을 위한 PostgreSQL 데이터베이스를 고려해 보십시오. hr이라는 스키마를 두고 그 안에 employees, departments, salaries와 같은 테이블을 포함할 수 있습니다. 이 테이블의 완전한 이름은 hr.employees가 됩니다. 여러 사용자가 이 스키마에 접근할 수 있으며, 그 안의 객체는 서로 다른 사용자가 소유할 수 있습니다.
사용자와 스키마의 분리
Oracle의 사용자와 스키마 간의 엄격한 결합과는 달리, PostgreSQL은 더 큰 유연성을 제공합니다. 사용자는 여러 스키마에 걸쳐 객체를 소유할 수 있으며, 스키마는 서로 다른 사용자가 소유한 객체를 포함할 수 있습니다. 이러한 분리는 데이터베이스 조직 및 접근에 대한 보다 세분화된 제어를 제공하며, 많은 사용자와 애플리케이션이 있는 환경에서 특히 유리할 수 있습니다.
예를 들어, PostgreSQL에서는 조직의 각 부서(hr, finance, sales)에 대한 스키마를 생성하고 각 스키마 내에서 서로 다른 사용자가 소유한 객체를 가질 수 있습니다. 이를 통해 보다 깔끔한 구조를 제공하고, 사용자가 자주 스키마 경계를 넘거나 스키마 특정 권한에 의존할 필요 없이 같은 데이터베이스 내에서 작업할 수 있게 합니다.
또한, PostgreSQL에서는 검색 경로(Search Path)를 설정하여 사용자가 스키마 이름을 명시하지 않고도 쉽게 객체에 접근할 수 있습니다. 이를 통해 쿼리의 간결성을 높이고, 스키마 이름을 반복적으로 입력해야 하는 불편함을 줄일 수 있습니다.
3. Oracle과 PostgreSQL 스키마 간의 비교
1. 스키마와 사용자 간의 관계
- Oracle: 스키마는 사용자 계정과 직접 연결되며, 사용자와 스키마 간의 일대일 관계가 존재합니다. 스키마는 본질적으로 사용자의 데이터베이스 작업 공간을 나타냅니다.
- PostgreSQL: 스키마는 사용자와 독립적입니다. 여러 사용자가 동일한 스키마 내에서 객체를 소유할 수 있으며, 하나의 사용자가 여러 스키마에서 객체를 소유할 수 있습니다. 이는 보다 유연하고 모듈화된 데이터베이스 조직 접근법을 가능하게 합니다.
2. 스키마 생성
- Oracle: 사용자가 생성될 때 자동으로 스키마가 생성됩니다. Oracle에서는 스키마를 명시적으로 생성하지 않고, 대신 사용자를 생성하면 해당 사용자에 대한 스키마가 생성됩니다.
- PostgreSQL: CREATE SCHEMA 명령어를 사용하여 명시적으로 스키마를 생성합니다. 단일 데이터베이스 내에 여러 스키마를 생성할 수 있으며, 이러한 스키마는 객체를 논리적으로 구성하는 데 사용될 수 있습니다.
3. Object 구성
- Oracle: 객체는 생성한 사용자와 연결된 스키마에 속하며, 이를 통해 각 사용자는 자신의 객체 집합을 관리합니다. 이는 접근 제어 및 객체 공유를 복잡하게 할 수 있습니다.
- PostgreSQL: 객체는 여러 스키마 간에 유연하게 분산될 수 있으며, 각 스키마는 관련 객체를 그룹화하여 데이터베이스를 보다 논리적으로 조직할 수 있도록 지원합니다
4. 접근 제어
- Oracle: 스키마는 사용자와 연결되어 있으므로 접근 제어는 사용자 권한과 밀접하게 관련되어 있습니다. 사용자가 다른 사용자의 스키마에 있는 객체에 접근해야 할 경우, 권한을 명시적으로 부여하거나 동의어를 사용하여 객체 접근을 간소화해야 합니다.
- PostgreSQL: 접근 제어는 더 유연합니다. 여러 사용자가 동일한 스키마 내에서 객체를 소유하고 공유할 수 있습니다. 권한을 스키마 수준에서 부여할 수 있어, 사용자는 매 쿼리에서 스키마 이름을 언급하지 않고도 객체에 접근할 수 있습니다.
5. 완전한 객체 이름
- Oracle: 객체는 schema_name.object_name 형식으로 참조됩니다. 각 스키마가 사용자와 일치하므로, 객체는 일반적으로 user_name.object_name 형식으로 참조됩니다.
- PostgreSQL: 객체는 schema_name.object_name 형식으로 참조되지만, 스키마는 사용자와 독립적이므로, 스키마 이름은 객체의 소유자가 아닌 데이터베이스의 논리적 조직을 반영합니다.
6. 대규모 환경에서의 스키마 관리
- Oracle: 대규모 환경에서 스키마 관리는 사용자와 스키마 간의 1:1 관계로 인해 더 복잡할 수 있습니다. 이 구조는 더 세부적인 접근 제어 메커니즘을 필요로 하며, 객체 공유를 더 번거롭게 만들 수 있습니다.
- PostgreSQL: 스키마와 사용자의 분리는 대규모 환경을 관리하는 것을 쉽게 만들어 줍니다. 스키마는 관련 객체를 그룹화하는 데 사용될 수 있으며, 사용자는 복잡한 접근 제어 메커니즘 없이 여러 스키마의 객체에 접근할 수 있습니다.
고려사항: Oracle에서 PostgreSQL로 전환
Oracle로 구성된 DBMS에서 PostgreSQL로 이동할 때 가장 큰 조정은 아마도 사용자와 스키마의 분리일 것입니다. Oracle에서는 사용자 중심의 스키마 접근 방식으로 인해 데이터베이스 조직이 개별 사용자 계정 주위를 형성합니다. 그러나 PostgreSQL에서는 스키마가 사용자와 독립적인 더 유연한 조직 도구로 간주됩니다.
필자의 경험: Oracle의 스키마 모델에서 PostgreSQL로 전환할 때 고려해야 할 몇 가지 주의사항
1. 새로운 시각에서 바라보는 데이터베이스 설계
Oracle에서는 각 애플리케이션이나 부서마다 새 사용자를 생성하고 사용자와 스키마 간의 1:1 관계에 의존하여 객체를 조직하는 데 익숙할 것입니다. PostgreSQL에서는 개별 사용자가 아닌 기능, 애플리케이션 모듈 또는 조직 부서를 기준으로 스키마를 생성하는 것을 고려해야 합니다.
예를 들어, HR 부서에 대한 별도의 사용자를 생성하는 대신 hr 스키마를 만들고 해당 스키마 내에 모든 관련 객체(예: 테이블, 뷰, 함수)를 조직할 수 있습니다. 여러 사용자는 필요에 따라 이 스키마에 대한 접근 권한을 부여받을 수 있습니다.
2. 검색 경로 활용하기
PostgreSQL은 검색 경로를 구성할 수 있으며, 이는 시스템이 완전한 이름이 지정되지 않은 객체 이름을 어떻게 해결하는지를 결정합니다. 검색 경로를 적절히 설정함으로써 쿼리를 간소화하고 매 쿼리마다 스키마 이름을 지정할 필요를 줄일 수 있습니다.
예를 들어, 대부분의 작업이 hr 스키마에서 이루어지는 경우, 검색 경로를 hr을 먼저 포함하도록 설정하여 employees와 같은 테이블을 참조할 수 있습니다. 이 경우 매 쿼리에서 스키마 이름을 접두어로 붙일 필요가 없습니다.
3. 접근 제어를 위한 역할 사용하기
PostgreSQL에서는 역할(사용자 또는 사용자 그룹을 나타낼 수 있음)을 사용하여 스키마 전반에 걸친 객체에 대한 접근을 관리합니다. 역할을 효과적으로 사용하면 어떤 사용자가 어떤 스키마에 접근할 수 있는지 및 해당 스키마 내의 객체에 대해 어떤 작업을 수행할 수 있는지를 제어할 수 있습니다.
예를 들어, hr 스키마의 테이블에서 SELECT 권한이 있는 read_only 역할을 생성하고, HR 데이터에 대한 읽기 전용 접근이 필요한 사용자에게 이 역할을 부여할 수 있습니다.
4. 스키마 마이그레이션 계획하기
Oracle 데이터베이스를 PostgreSQL로 마이그레이션할 경우, Oracle 사용자와 스키마를 PostgreSQL 스키마에 어떻게 매핑할지 신중하게 계획해야 합니다. Oracle은 스키마를 사용자와 직접 연결하기 때문에, 동일한 구조를 따르면 PostgreSQL에서 많은 스키마가 생성될 수 있습니다.
대신, 사용자 소유가 아닌 논리적 관계를 기반으로 관련 객체를 더 적은 스키마로 통합하는 것을 고려하세요. 이는 데이터베이스 구조를 단순화하고 장기적으로 관리하기 쉽게 만드는 데 도움이 될 수 있습니다.
결론: PostgreSQL의 유연성 활용하기
Oracle에서 PostgreSQL로 전환하려면 스키마 및 데이터베이스 조직에 대한 사고 방식을 전환해야 합니다. Oracle에서는 스키마가 사용자와 긴밀하게 결합되어 있어 직관적이지만 때때로 제한적인 환경을 형성합니다. 반면 PostgreSQL은 스키마와 사용자를 분리하여 데이터베이스 객체를 조직하고 관리하는 데 있어 더 유연하고 확장 가능한 시스템을 제공합니다.
Oracle과 PostgreSQL의 스키마 작업 방식의 차이를 이해함으로써, PostgreSQL에서 데이터베이스를 구조화하고 접근 제어를 관리하는 방법에 대해 더 정보에 기반한 결정을 내릴 수 있습니다. 유연한 네임스페이스 모델과 강력한 스키마 관리 도구를 제공하는 PostgreSQL은 복잡한 데이터베이스를 조직하는 데 robust한 플랫폼을 제공합니다. 협업과 확장성을 촉진하는 방식으로 구성할 수 있습니다.
