관계형 데이터베이스에서 카탈로그와 스키마의 차이점은 무엇입니까?


96

저는 스키마가 데이터베이스 자체 이전의 "상위 래퍼"개체라고 생각했습니다. 내말은DB.schema.<what_ever_object_name_under_schema> .

글쎄요, 카탈로그 "래퍼"는 이제 상당히 혼란 스럽습니다. 카탈로그가 필요한 이유는 무엇입니까? 어떤 목적으로 카탈로그를 정확하게 사용해야합니까?

답변:


73

관계형 관점에서 :

카탈로그는 무엇보다도 다양한 스키마 (외부, 개념, 내부)와 모든 해당 매핑 (외부 / 개념, 개념 / 내부)이 보관되는 장소입니다.

즉, 카탈로그에는 시스템 자체에 관심이있는 다양한 개체에 대한 자세한 정보 ( 설명자 정보 또는 메타 데이터 라고도 함 )가 포함됩니다.

예를 들어, 옵티마이 저는 인덱스 및 기타 물리적 스토리지 구조에 대한 카탈로그 정보와 기타 많은 정보를 사용하여 사용자 요청을 구현하는 방법을 결정하는 데 도움을줍니다. 마찬가지로 보안 하위 시스템은 사용자 및 보안 제약에 대한 카탈로그 정보를 사용하여 처음에 이러한 요청을 승인하거나 거부합니다.

데이터베이스 시스템 소개, 7th ed., CJ Date, p 69-70.


SQL 표준 관점에서 :

카탈로그는 SQL 환경에서 명명 된 스키마 모음입니다. SQL 환경에는 0 개 이상의 카탈로그가 있습니다. 카탈로그에는 하나 이상의 스키마가 포함되지만 항상 정보 스키마의보기 및 도메인을 포함하는 INFORMATION_SCHEMA라는 스키마가 포함됩니다.

데이터베이스 언어 SQL , (DIS 9075의 개정 된 텍스트 제안), p 45


SQL 관점에서 :

카탈로그는 종종 데이터베이스 와 동의어입니다 . 대부분의 SQL dbms에서 information_schema 뷰를 쿼리하면 "table_catalog"열의 값이 데이터베이스 이름에 매핑된다는 것을 알 수 있습니다.

이 세 가지 정의보다 더 광범위한 방식으로 카탈로그 를 사용하는 플랫폼을 찾으면 데이터베이스 클러스터, 서버 또는 서버 클러스터와 같은 데이터베이스보다 더 광범위한 것을 참조 할 수 있습니다. 그러나 나는 당신이 당신의 플랫폼의 문서에서 쉽게 찾을 수 있었기 때문에 의심 스럽습니다.


177

Mike Sherrill 'Cat Recall'훌륭한 답변을했습니다 . 간단히 하나의 예를 추가하겠습니다 : Postgres .

클러스터 = Postgres 설치

머신에 Postgres를 설치할 때 해당 설치를 클러스터 라고 합니다 . 여기서 '클러스터' 는 여러 컴퓨터가 함께 작동 하는 하드웨어적인 의미가 아닙니다 . Postgres에서 클러스터 는 동일한 Postgres 서버 엔진을 사용하여 관련없는 여러 데이터베이스를 모두 가동하고 실행할 수 있다는 사실을 나타냅니다.

클러스터 라는 단어 는 Postgres와 동일한 방식으로 SQL 표준 에 의해 정의됩니다 . SQL 표준을 밀접하게 따르는 것이 Postgres 프로젝트의 주요 목표입니다.

SQL-92 사양은 말합니다 :

클러스터는 구현 정의 카탈로그 모음입니다.

정확히 하나의 클러스터가 SQL 세션과 연결됩니다.

이는 클러스터가 데이터베이스 서버 (각 카탈로그가 데이터베이스 임)라고 말하는 무례한 방법입니다.

클러스터> 카탈로그> 스키마> 테이블> 열 및 행

따라서 Postgres와 SQL Standard 모두에서 다음과 같은 포함 계층 구조가 있습니다.

  • 컴퓨터에는 하나 또는 여러 개의 클러스터가있을 수 있습니다.
  • 데이터베이스 서버는 클러스터 입니다.
  • 클러스터에는 카탈로그가 있습니다. (카탈로그 = 데이터베이스)
  • 카탈로그에는 스키마가 있습니다. (스키마 = 테이블의 네임 스페이스 및 보안 경계)
  • 스키마에는 테이블있습니다 .
  • 테이블에는 있습니다 .
  • 행에는 열로 정의 된 있습니다 .
    이러한 값은 사용자 이름, 송장 기한, 제품 가격, 게이머의 최고 점수와 같이 앱과 사용자가 관심을 갖는 비즈니스 데이터입니다. 열은 값 의 데이터 유형 (텍스트, 날짜, 숫자 등)을 정의합니다.

포트에 연결하여 각각 하나 이상의 스키마 (네임 스페이스)를 포함하는 하나 이상의 카탈로그 (데이터베이스)를 포함하는 클러스터 (데이터베이스 서버)에 연결하는 방법을 나타내는 중첩 상자를 보여주는 다이어그램 행.

다중 클러스터

이 다이어그램은 단일 클러스터를 나타냅니다. Postgres의 경우 호스트 컴퓨터 (또는 가상 OS) 당 둘 이상의 클러스터를 가질 수 있습니다. Postgres의 새 버전 (예 : 9.0 , 9.1 , 9.2 , 9.3 , 9.4 , 9.5 ) 을 테스트하고 배포하기 위해 여러 클러스터가 일반적으로 수행됩니다 .

클러스터가 여러 개인 경우 위의 다이어그램이 복제되었다고 상상해보십시오.

서로 다른 포트 번호를 사용하면 여러 클러스터가 동시에 작동하고 동시에 실행될 수 있습니다. 각 클러스터에는 고유 한 포트 번호가 할당됩니다. 보통5432 은 기본값 일 뿐이며 사용자가 설정할 수 있습니다. 각 클러스터는 들어오는 데이터베이스 연결을 위해 자체 할당 된 포트에서 수신 대기합니다.

예제 시나리오

예를 들어 한 회사에 두 개의 서로 다른 소프트웨어 개발 팀이있을 수 있습니다. 하나는 창고를 관리하는 소프트웨어를 작성하고 다른 팀은 영업 및 마케팅을 관리하는 소프트웨어를 작성합니다. 각 개발 팀은 서로를 인식하지 못하는 자체 데이터베이스를 가지고 있습니다.

그러나 IT 운영 팀은 단일 컴퓨터 상자 (Linux, Mac 등)에서 두 데이터베이스를 모두 실행하기로 결정했습니다. 그래서 그 상자에 Postgres를 설치했습니다. 따라서 하나의 데이터베이스 서버 (데이터베이스 클러스터). 해당 클러스터에서 각 개발 팀에 대한 카탈로그 인 'warehouse'와 'sales'라는 두 개의 카탈로그를 만듭니다.

각 개발 팀은 목적과 액세스 역할이 서로 다른 수십 개의 테이블을 사용합니다. 따라서 각 개발 팀은 테이블을 스키마로 구성합니다. 우연히도 두 개발 팀은 회계 데이터를 추적하므로 각 팀은 '회계'라는 스키마를 갖게됩니다. 동일한 스키마 이름을 사용하는 것은 문제가되지 않습니다. 카탈로그에는 각각 고유 한 네임 스페이스가 있으므로 충돌이 없습니다.

또한 각 팀은 결국 '원장'이라는 회계 목적으로 테이블을 만듭니다. 다시 말하지만 이름 충돌이 없습니다.

이 예를 계층 구조로 생각할 수 있습니다.

  • 컴퓨터 (하드웨어 박스 또는 가상화 된 서버)
    • Postgres 9.2 클러스터 (설치)
      • warehouse 카탈로그 (데이터베이스)
        • inventory 개요
          • [… 일부 테이블]
        • accounting 개요
          • ledger
          • [… 다른 테이블]
      • sales 카탈로그 (데이터베이스)
        • selling 개요
          • [… 일부 테이블]
        • accounting 스키마 (위와 동일한 이름)
          • ledger 테이블 (위와 동일한 이름)
          • [… 다른 테이블]
    • Postgres 9.3 클러스터
      • [… 기타 스키마 및 테이블]

각 개발 팀의 소프트웨어는 클러스터에 연결합니다. 이를 수행 할 때 자신의 카탈로그 (데이터베이스)를 지정해야합니다. Postgres를 사용하려면 하나의 카탈로그에 연결해야하지만 해당 카탈로그로 제한되지는 않습니다. 초기 카탈로그는 SQL 문이 카탈로그 이름을 생략 할 때 사용되는 단순한 기본값입니다.

따라서 개발 팀이 다른 팀의 테이블에 액세스해야하는 경우 데이터베이스 관리자가 액세스 권한 을 부여 했다면 그렇게 할 수 있습니다. 액세스는 catalog.schema.table 패턴의 명시 적 이름 지정으로 이루어집니다 . 따라서 '창고'팀이 다른 팀의 ( '영업'팀) 원장을 확인해야하는 경우 sales.accounting.ledger. 자신의 원장에 액세스하려면 accounting.ledger. 그들은 소스 코드의 동일한 부분에 두 원장에 액세스하는 경우, 그들은 자신의 (선택 사항) 카탈로그 이름을 포함하여 혼동을 피하기 위해 선택할 수있다 warehouse.accounting.ledgersales.accounting.ledger.


그건 그렇고 ...

특정 데이터베이스 테이블 구조의 전체 디자인을 의미하는보다 일반적인 의미로 사용되는 스키마 라는 단어를들을 수 있습니다 . 대조적으로 SQL 표준에서이 단어는 특히 Cluster > Catalog > Schema > Table계층 구조 의 특정 계층을 의미 합니다.

Postgres는 CREATE DATABASE 명령 과 같은 다양한 위치에서 단어 데이터베이스카탈로그 를 모두 사용합니다 .

모든 데이터베이스 시스템이이 전체 계층을 제공하는 것은 아닙니다 Cluster > Catalog > Schema > Table. 일부에는 단일 카탈로그 (데이터베이스) 만 있습니다. 일부는 스키마가없고 한 세트의 테이블 만 있습니다. Postgres는 매우 강력한 제품입니다.


8
이면 ...Catalog > Schema...누군가가 pgAdmin (PostgreSQL UI)의 "Catalog"및 "Schema"노드가 Catalog의 자식 노드 인 Schema 노드 대신 형제 노드 인 이유를 말해 줄 수 있습니까?
레드 완두콩

6
"Schema"노드는 귀하의 것이지만 "Catalogs"노드는 그렇지 않습니다. 은 "카탈로그"노드는 정확히 두 개의 항목이 있습니다 : (1) PostgreSQL (pg_catalog), 시스템 카탈로그와 같은 데이터베이스의 메타 데이터 정의를 저장 "같은 pg_"테이블의 수십 pg_index, pg_trigger하고 pg_constraint. (2) ANSI (information_schema), SQL 표준에 의해 정의 된 동일한 시스템 카탈로그의 읽기 전용보기입니다 information_schema. pgAdmin의 "Catalogs"노드에 대한 더 나은 이름은 "System"또는 "System Tables"일 수 있습니다.
Basil Bourque 2015

감사. "모든 데이터베이스 시스템이 클러스터> 카탈로그> 스키마> 테이블의 전체 계층 구조를 제공하는 것은 아닙니다."mysql 및 SQL Server의 경우 어떤 것인지 궁금합니다.
Tim

+1. 스키마의 모든 테이블이 동일한 관계형 스키마 (즉, 동일한 속성 세트 및 / 또는 동일한 제약 세트)를 가지고 있습니까? 내 질문 stackoverflow.com/questions/48232448/… 도 볼 수 있습니까? 감사.
Tim

1
@Tim 스키마는 파일 시스템에서 파일을 구성하는 네임 스페이스 인 것처럼 테이블 그룹을 구분하는 네임 스페이스입니다 (스키마 중첩 없음). 테이블은 앱의 데이터를 행별 속성 / 열로 저장합니다.
Basil Bourque
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.