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

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

---

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

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

---

관계형 관점에서 :

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

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

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

데이터베이스 시스템 소개, 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"열의 값이 데이터베이스 이름에 매핑된다는 것을 알 수 있습니다.

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

---

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 ) 을 테스트하고 배포하기 위해 여러 클러스터가 일반적으로 수행됩니다 .

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

Different port numbers allow the multiple clusters to live side-by-side all up and running at the same time. Each cluster would be assigned its own port number. The usual 5432 is only the default, and can be set by you. Each cluster is listening on its own assigned port for incoming database connections.

Example Scenario

For example, a company could have two different software development teams. One writes software to manage the warehouses while the other team builds software to manage sales and marketing. Each dev team has their own database, blissfully unaware of the other’s.

But the IT operations team took a decision to run both databases on a single computer box (Linux, Mac, whatever). So on that box they installed Postgres. So one database server (database cluster). In that cluster, they create two catalogs, a catalog for each dev team: one named 'warehouse' and one named 'sales'.

Each dev team uses many dozens of tables with different purposes and access roles. So each dev team organizes their tables into schemas. By coincidence, both dev teams do some tracking of accounting data, so each team happens to have a schema named 'accounting'. Using the same schema name is not a problem because the catalogs each have their own namespace so no collision.

Furthermore, each team eventually creates a table for accounting purposes named 'ledger'. Again, no naming collision.

You can think of this example as a hierarchy…

• Computer (hardware box or virtualized server)
  • Postgres 9.2 cluster (installation)
    • warehouse catalog (database)
      • inventory schema
        • [… some tables]
      • accounting schema
        • ledger table
        • [… some other tables]
    • sales catalog (database)
      • selling schema
        • [… some tables]
      • accounting schema (coincidental same name as above)
        • ledger table (coincidental same name as above)
        • [… some other tables]
  • Postgres 9.3 cluster
    • [… other schemas & tables]

Each dev team's software makes a connection to the cluster. When doing so, they must specify which catalog (database) is theirs. Postgres requires that you connect to one catalog, but you are not limited to that catalog. That initial catalog is merely a default, used when your SQL statements omit the name of a catalog.

So if the dev team ever needs to access the other team's tables, they may do so if the database administrator has given them privileges to do so. Access is made with explicit naming in the pattern: catalog.schema.table. So if the 'warehouse' team needs to see the other team’s ('sales' team) ledger, they write SQL statements with sales.accounting.ledger. To access their own ledger, they merely write accounting.ledger. If they access both ledgers in the same piece of source code, they may choose to avoid confusion by including their own (optional) catalog name, warehouse.accounting.ledger versus sales.accounting.ledger.

---

By the way…

You may hear the word schema used in a more general sense, meaning the entire design of a particular database's table structure. By contrast, in the SQL Standard the word means specifically the particular layer in the Cluster > Catalog > Schema > Table hierarchy.

Postgres uses both the word database as well as catalog in various places such as the CREATE DATABASE command.

Not all database system provides this full hierarchy of Cluster > Catalog > Schema > Table. Some have only a single catalog (database). Some have no schema, just one set of tables. Postgres is an exceptionally powerful product.

참고URL : https://stackoverflow.com/questions/7022755/whats-the-difference-between-a-catalog-and-a-schema-in-a-relational-database