카탈로그

카탈로그는 데이터베이스가 이름만 보고 테이블을 찾아가게 해 줍니다. 그런데 이 낱말이 가리키는 대상은 둘입니다. 데이터베이스 언어의 표준에서는 스키마 여러 개를 담는 가장 바깥 묶음을 카탈로그라고 부릅니다. 데이터베이스 제품 안에서는 테이블과 열의 목록을 적어 둔 내부 테이블을 시스템 카탈로그라고 부릅니다.

상세

이 절은 데이터베이스 분야에서 카탈로그가 가리키는 두 대상을 차례로 봅니다. 먼저 이름을 세 단계로 적는 방식으로 표준의 카탈로그를 보입니다. 다음으로 PostgreSQL 의 내부 테이블로 시스템 카탈로그를 보입니다.

끝에서는 두 뜻을 표로 견줍니다. 데이터베이스 밖에서 같은 이름을 쓰는 도구도 짚습니다.

서가와 목록 카드

도서관에는 책을 꽂아 두는 서가가 있습니다. 서가 안은 문학, 역사처럼 구역으로 나뉩니다. 책은 구역에 꽂힙니다. 책을 찾을 때는 서가를 다 뒤지지 않고 목록 카드부터 봅니다. 카드에는 책 이름과 꽂힌 서가와 구역이 적혀 있습니다.

데이터베이스 분야는 카탈로그라는 낱말을 서가와 목록 카드 두 곳에 다 붙였습니다. 표준의 카탈로그는 서가 쪽입니다. 서가 안의 구역이 스키마입니다. 꽂힌 책은 테이블입니다. 시스템 카탈로그는 목록 카드 쪽입니다.

이름을 담는 세 단계

SQL(Structured Query Language)은 관계형 데이터베이스에 요청을 적는 언어입니다. 이 언어의 표준은 테이블 이름이 어디에 속하는지를 세 단계로 정합니다.

가장 안쪽 단계는 스키마입니다. 스키마는 테이블과 뷰 같은 객체를 이름별로 담는 칸입니다. 칸이 다르면 이름이 같은 테이블이 둘 있어도 됩니다. 주문을 담는 sales 스키마와 지난 주문을 옮겨 두는 archive 스키마에 orders 테이블이 하나씩 있을 수 있습니다.

카탈로그는 이 스키마 여러 개를 다시 담는 바깥 묶음입니다. 카탈로그가 다르면 스키마 이름이 겹쳐도 됩니다. 쇼핑몰용 shop 카탈로그와 블로그용 blog 카탈로그를 한 서버에 나란히 둘 수 있습니다.

아래 그림은 이 예를 펼친 것입니다. orders 라는 이름이 두 번 나오지만 속한 스키마가 달라서 서로 부딪히지 않습니다.

flowchart TD
    subgraph C1["카탈로그 shop"]
        S1["스키마 sales"] --> T1["테이블 orders"]
        S2["스키마 archive"] --> T2["테이블 orders"]
    end
    subgraph C2["카탈로그 blog"]
        S3["스키마 content"] --> T3["테이블 posts"]
    end

이름은 바깥에서 안으로 점을 찍어 잇습니다. 앞쪽 단계를 생략하면 데이터베이스가 지금 쓰고 있는 카탈로그와 스키마로 채웁니다. 같은 테이블을 가리키는 적는 법은 세 가지입니다.

shop.sales.orders    세 단계를 다 적은 이름
sales.orders         카탈로그는 지금 쓰는 것
orders               스키마도 정해 둔 것으로

표준은 카탈로그마다 그 안에 무엇이 있는지 보여 주는 스키마를 하나씩 두게 합니다. 이 스키마가 정보 스키마입니다. 이름은 INFORMATION_SCHEMA 입니다. 이 스키마는 뒤에서 볼 시스템 카탈로그와 이어집니다.

정보 스키마 안에는 테이블 목록을 보여 주는 표가 있습니다. 이 표는 테이블 하나에 한 행입니다. 행마다 카탈로그 이름, 스키마 이름, 테이블 이름을 적는 칸이 있습니다. 앞에서 본 세 단계를 칸 셋으로 나눠 적은 셈입니다.

제품이 바깥 묶음을 부르는 이름

표준의 카탈로그를 제품이 늘 카탈로그라고 부르지는 않습니다. 같은 단계를 다른 이름으로 부르거나, 아예 그 단계를 두지 않기도 합니다. 두 제품이 표준의 두 단계에 붙인 이름을 견주면 이렇습니다.

PostgreSQL 에서는 표준의 카탈로그에 해당하는 것이 데이터베이스입니다. 서버에 접속할 때 데이터베이스 이름을 하나 고릅니다. 연결 하나로는 그 데이터베이스 하나만 봅니다. 그래서 blog 에 접속한 채로 shop.sales.orders 를 읽을 수는 없습니다.

세 단계 이름을 적는 것 자체는 PostgreSQL 도 받아 줍니다. 다만 맨 앞 이름은 지금 접속한 데이터베이스와 같아야 합니다. shop 에 접속해 있다면 shop.sales.orders 는 sales.orders 와 같은 뜻입니다. 표준과 모양을 맞추려고 받아 주는 것이라 실무에서는 맨 앞을 거의 안 적습니다.

이 데이터베이스들을 서버 프로그램 하나가 한꺼번에 맡은 묶음이 데이터베이스 클러스터입니다. 표준의 말로는 카탈로그 클러스터입니다.

MySQL 은 거꾸로 한 단계를 접었습니다. 데이터베이스와 스키마가 같은 것을 가리킵니다. 그 위의 카탈로그 단계는 쓰지 않습니다. 정보 스키마의 표에 카탈로그 칸은 남아 있지만 값은 언제나 def 입니다. 늘 같은 값이라 이름을 가르는 데 쓰이지 않는 칸입니다.

그러니 문서에서 카탈로그를 만나면 어느 제품의 어휘인지부터 봐야 합니다. PostgreSQL 이면 데이터베이스로 읽습니다. MySQL 이면 늘 def 만 들어 있는, 쓰이지 않는 칸입니다.

데이터베이스가 자기 자신을 적어 두는 표

두 번째 뜻은 목록 카드 쪽입니다. 테이블 이름, 열 이름과 타입, 인덱스, 권한처럼 데이터를 설명하는 데이터를 메타데이터라고 부릅니다. 데이터베이스는 이 메타데이터를 자기 안의 테이블에 적어 둡니다. 이 테이블들이 시스템 카탈로그입니다.

시스템 카탈로그가 있어야 데이터베이스가 요청을 이해합니다. SELECT id FROM orders 를 받으면 orders 가 있는지, 거기에 id 열이 있는지, 이 사용자가 읽어도 되는지를 먼저 확인해야 합니다. 이 질문의 답이 전부 시스템 카탈로그에 있습니다.

시스템 카탈로그는 사람이 직접 고치지 않습니다. 테이블을 만들고 바꾸고 지우는 문장, 곧 DDL(Data Definition Language, 데이터 정의 언어)이 대신 고칩니다. CREATE TABLE 을 실행하면 데이터베이스가 새 테이블의 이름과 열을 카탈로그에 적습니다. 손으로 고치면 카탈로그와 실제 데이터가 어긋날 수 있어서 이렇게 나눕니다.

테이블의 실제 행은 카탈로그가 아니라 데이터 파일에 저장됩니다. 테이블 하나를 만들고 읽는 동안 시스템 카탈로그와 데이터 파일이 각각 언제 끼는지 그려 보면 이렇습니다.

sequenceDiagram
    participant 앱
    participant DB as 데이터베이스
    participant 카탈로그 as 시스템 카탈로그
    participant 파일 as 데이터 파일
    앱->>DB: CREATE TABLE orders
    DB->>카탈로그: orders 와 열 목록을 적는다
    앱->>DB: SELECT id FROM orders
    DB->>카탈로그: orders 와 id 열이 있나
    카탈로그-->>DB: 있다
    DB->>파일: orders 를 읽는다
    DB-->>앱: 결과

만들 때는 카탈로그에 적기만 합니다. 읽을 때는 카탈로그를 먼저 거친 다음에야 데이터 파일로 갑니다.

교재에 따라서는 같은 것을 데이터 딕셔너리라고도 부릅니다. 이름만 다르고 가리키는 것은 같습니다.

PostgreSQL 의 시스템 카탈로그

PostgreSQL 에서는 시스템 카탈로그를 SELECT 로 읽어 볼 수 있습니다. 테이블과 인덱스 같은 객체의 목록은 pg_class 라는 카탈로그에 있습니다. 아래는 orders 가 어떤 종류의 객체인지 묻는 문장입니다.

SELECT relkind FROM pg_class
 WHERE relname = 'orders';  -- r

relname 칸에는 객체 이름이 들어 있습니다. relkind 칸은 객체의 종류를 한 글자로 적습니다. r 은 보통 테이블이라는 표시입니다. 인덱스였다면 다른 글자가 나옵니다.

시스템 카탈로그는 대부분 데이터베이스마다 따로 있습니다. shop 에 테이블을 만들어도 blog 의 카탈로그에는 아무것도 안 생깁니다.

PostgreSQL 에는 새 데이터베이스의 본보기로 쓰는 데이터베이스가 있습니다. 이것을 템플릿 데이터베이스라고 부릅니다. 데이터베이스를 새로 만들 때 여기서 카탈로그까지 복사해 옵니다. 그 뒤로는 각자 바뀝니다.

몇몇 카탈로그는 클러스터 전체가 함께 씁니다. 데이터베이스 목록을 담는 pg_database 가 그런 카탈로그입니다. PostgreSQL 에서 표준의 카탈로그는 데이터베이스입니다. 그 데이터베이스들의 목록을 시스템 카탈로그 pg_database 가 들고 있는 셈입니다.

시스템 카탈로그의 모양은 제품마다 다릅니다. pg_class 는 PostgreSQL 에만 있습니다. 앞에서 본 정보 스키마는 같은 메타데이터를 표준이 정한 모양으로 보여 주는 뷰입니다. 그래서 제품이 바뀌어도 같은 모양을 기대할 수 있습니다.

대신 그 제품에만 있는 기능의 정보는 정보 스키마에 없습니다. 어느 쪽을 읽을지는 도구가 무엇을 바라는지로 고릅니다. 여러 제품에서 돌아야 하는 도구는 정보 스키마를 읽습니다. 한 제품의 세부가 필요하면 시스템 카탈로그를 읽습니다.

두 뜻을 가르는 법

두 뜻은 같은 낱말을 쓰지만 담는 것이 다릅니다. 표준의 카탈로그는 사용자가 만든 테이블을 담는 그릇입니다. 시스템 카탈로그는 그 테이블에 대한 정보를 담는 표입니다.

문장에서 가르는 단서는 이웃한 낱말입니다. 데이터베이스나 스키마와 나란히 서서 무언가를 담는다고 하면 표준의 카탈로그입니다. 「시스템」이 붙거나 테이블과 열의 정보를 찾는다는 이야기면 시스템 카탈로그입니다.

데이터베이스 밖의 카탈로그

목록이라는 원래 뜻 때문에 이 낱말은 다른 분야에도 붙습니다. 이 절은 이름이 겹치는 것만 짚습니다. 자세한 것은 각 항목에 맡깁니다.

• 데이터 카탈로그 — 회사 안의 여러 데이터베이스와 파일을 사람이 검색해 찾게 정리한 도구입니다. 데이터베이스가 혼자 읽는 시스템 카탈로그와 달리 사람이 읽습니다.
• 서비스 카탈로그 — 조직이 돌리는 서비스와 그 담당자를 모아 둔 목록입니다.
• Airbyte 의 카탈로그 — 데이터 수집 도구 Airbyte 가 원천에서 꺼내 올 수 있는 데이터의 목록을 부르는 이름입니다.

관련 항목

카탈로그를 이루는 이름의 단계

카탈로그 클러스터 · 스키마 · 테이블 · 뷰 · 식별자 · 네임스페이스

카탈로그를 다른 이름으로 부르는 제품의 단위

데이터베이스 · 데이터베이스 클러스터 · PostgreSQL · MySQL · SQL 표준 · SQL

시스템 카탈로그가 담는 메타데이터

메타데이터 · 시스템 카탈로그 · 데이터 딕셔너리 · information_schema · pg_class · pg_database · 인덱스 · 권한

시스템 카탈로그를 고치고 읽는 문장과 프로그램

DDL · 데이터베이스 관리 시스템 · 질의 옵티마이저 · 템플릿 데이터베이스 · 스키마 진화

이름이 겹치는 다른 분야의 카탈로그

데이터 카탈로그 · 서비스 카탈로그 · 카탈로그 (Airbyte) · 데이터 거버넌스