📣 들어가며
최근 JDBC로 (정확히는 node-jdbc) 테이블 목록을 가져올 일이 있었는데,getTables api 를 요청해도 빈 배열만 반환됐다. 분명 테이블들이 있는데도...
한참의 삽질 끝에 getCatalogs 또는 getSchemas api 를 사용 후,
스키마나 카탈로그 정보로 테이블 목록을 가져와야한다는 걸 알 수 있었다.
그런데 카탈로그가 있는 DB가 있고, 없는 DB가 있었다.
때문에 카탈로그가 없다면 스키마를 적절히 조회해서 그 조회 정보로 테이블을 가져왔어야했는데,
도통 감이 잡히지 않아 이번 포스팅을 작성해본다.
사실 이런 의문점은 DBeaver를 쓸 때부터 갖고 있던 생각이었다.
(다른 DB 툴도 비슷하리라고 생각된다.)
DBeaver를 사용하다보면 어떤 DB는 Databases 아래에 테이블 목록이 바로 있는 반면
어떤 DB는 Databases 목록 하위에 Schemas 하위에 Tables 가 보이는 등 구조가 달랐기 때문이다.
이번 포스팅에선 스키마와 카탈로그의 개념 및 DB 계층에 대해 다뤄본다.
📘 스키마란?
Database Schema.
스키마는 직역하면 개요, 계획, 도식을 나타낸다.
데이터베이스에서 자료의 구조, 자료의 표현 방법, 자료 간의 관계를 형식 언어로 정의한 구조이다.
데이터베이스 관리자(DBA)/유저에 의해 생성 및 관리된다.
📒 스키마 예
- 테이블 정보(테이블 이름, 컬럼 이름, 컬럼 데이터 타입 등)
- 테이블 간의 관계(relationship)
- 제약 조건(NOT NULL, UNIQUE, PRIMARY KEY, FOREINKEY, DEFAULT, INDEX 등)
📒 스키마 구조
스키마는 크게 개념 스키마, 외부 스키마, 내부 스키마로 나눌 수 있다.
(뭔가 대학 전공 수업때 들었던거 같은 기억이...)
개념 스키마
일반적으로 '스카마' 라고 했을 때, 개념 스키마를 의미한다.
개념 스키마는 DB의 전체 구조를 나타낸다.
모든 데이터베이스 객체 및 객체 간의 관계를 포괄적으로 정의한다.
사용자 관점에서 데이터베이스를 전반적으로 이해할 수 있는 논리적인 설계를 제공한다.
데이터베이스의 고수준 뷰를 정의하는 데 사용된다.
외부 스키마
외부 스키마는 데이터베이스의 부분적인 뷰 또는 사용자 관점을 나타낸다.
때문에 일부만 볼 수 있다는 의미에서 '서브 스키마'라고도 한다.
특정 사용자 그룹이나 응용 프로그램에 의해 볼 수 있는 데이터베이스 부분을 정의한다.
각 사용자 그룹이 필요로 하는 데이터에 액세스할 수 있도록한다.
데이터베이스의 특정 부분을 개별적으로 제어 및 사용자 지정할 수 있다.
쉽게 설명하자면, 권한 별 접근 가능 부분을 정의해둔 것이라 생각하면 될 듯 하다.
하나의 데이터베이스 시스템에는 여러 개의 외부 스키마가 존재할 수 있다.
내부 스키마
내부 스키마는 데이터베이스의 물리적 구조와 저장 방법을 정의한다.
데이터베이스 관리 시스템(DBMS) 내부에서 데이터가 어떻게 저장되고 관리되는지를 나타낸다.
주로 데이터 압축, 색인 구조, 파일 구성 및 기타 물리적인 세부 사항을 다룬다.
개발자나 일반 사용자가 직접 접근하는 것이 아니라 DBMS가 내부적으로 처리하는 영역이다.
📘 카탈로그란?
Database Catalog.
데이터 사전이라고도 불린다.
데이터베이스 카탈로그는 메타데이터들로 구성된 데이터베이스 내의 인스턴스이다.
즉, 카탈로그에 저장된 데이터 = 메타데이터 인것이다.
메타데이터는
기본 테이블, 뷰 테이블, 동의어(synonym)들, 값 범위들, 인덱스들, 사용자들, 사용자 그룹 등등과 같은 데이터베이 개체의 정의를 의미한다.
💡 메타데이터
메타 데이터는 데이터에 관한 구조화된 데이터이다.
대량의 정보 가운데에서 확인하고자 하는 정보를 효율적으로 검색하기 위해 원시데이터(Raw data)를 일정한 규칙에 따라 구조화 혹은 표준화한 정보를 의미한다.
쉽게 얘기하자면 다른 데이터를 설명해 주는 데이터이다.
메타(Meta)는 일반적으로 '~에 관한', '~에 대한' 이라고 해석된다.
예를 들어, 과일 정보를 저장하고 있는 테이블이 있다.여기서 테이블 내의 '사과', '오렌지', '맛있음'의 데이터 따위가 아니라테이블 이름, 열(컬럼) 이름, 데이터 타입(숫자타입, 문자타입 등) 등을 메타 데이터라고 할 수 있다.
카탈로그는 DB 종류에 따라 다른 구조를 가진다.
데이터베이스 관리 시스템(DBMS, database management system)에 의해 스스로 생성 및 관리된다.
📘 스키마 VS 카탈로그
스키마든 카탈로그든 테이블 정보, 인덱스 등 정의하는 데이터가 비슷한 것 같은데,
스키마와 카탈로그는 서로 어떤 차이점이 있을까?
일단 한마디로 정리하자면,
카탈로그가 스키마 정보를 포함하고 있다.
카탈로그가 스키마보다 더 큰 개념인 것이다.
스키마는 유저(DBA)에 의해 생성/관리 되고, 카탈로그는 DBMS에 의해 생성/관리된다.
카탈로그는 모든 종류의 스키마를 가진 공간이다.
카탈로그는 한 개 이상의 스키마를 가질 수 있으며 INFORMATION_SCHEMA 라는 이름의 스키마는 항상 가지고 있다.
카탈로그는 보통 데이터베이스의 동의어로 사용된다.
📘 DB 계층 구조
카탈로그가 스키마를 포함한 것이라는 걸 이해했다.
그렇다면 아래 이미지처럼 스키마가 없는 DB가 있었던 이유는 뭘까?
일단 정확하게 말하자면 말하자면,
스키마가 없는게 아니라 카탈로그가 없는 것이다.
MySQL 에선 Database 와 Schema 를 동의어로 쓰고 있다. (공식문서)
그리고 앞서 설명한 것 처럼, MySQL 외 일반적인 다른 DB에선 Catalog 와 Database 는 동의어로 사용된다.
따라서 위 이미지의 PostgreSQL 은 Catalog(Database) 와 Schemas 가 둘 다 있는 것이고,
MySQL은 Schemas(Databse) 만 존재하는 것이다.
그렇다면 MySQL 에 카탈로그가 없는 이유가 대체 뭘까?
이를 이해하려면 DB별 계층 구조에 대해 알아야한다.
DB는 서로 다른 계층 구조를 가지는데,
크게 4계층과 3계층 구조로 나눌 수 있다.
대표적인 3계층 구조 DB엔 MySQL 이 있고,
4계층 구조 DB 엔 PostgreSQL이 있다.
그리고 3계층인지 4계층인지 아리송 하지만 결국은 4계층인 Oracle 이 있다.
📘 4계층 구조
위 그림과 같이
4 계층 구조는 인스턴스, 데이터베이스, 스키마, 그리고 테이블 목록 구역으로 나눈 구조를 의미한다.
ANSI 가 정한 표준 계층이다.
여기서 인스턴스는 DBMS가 동작할 때의 단위이다.
OS 입장에서는 프로세스,
DBMS에 따라서는 서버 프로세스 또는 서버로 부르기도 한다.
데이터 베이스가 실행 가능하도록 메모리에 올라간 상태라고 이해하면 된다.
일반적인 데이터베이스는 이 같은 4계층으로 되어 있다.
트리 구조로,
1개의 인스턴스 아래엔 여러개의 데이터베이스가 존재할 수 있고,
하나의 데이터베이스 아래엔 여러개의 스키마가 존재할 수 있고,
하나의 스키마 아래엔 여러개의 테이블이 존재한다.
가장 하위 계층인 4계층엔 정확인 테이블 이외에도 인덱스, 프로시저 등이 존재한다.
이런 데이터베이스에 보존된 것들을 오브젝트라고 한다.
즉, 테이블 또한 오브젝트의 일종인 것이다.
📘 3계층 구조
위 그림과 같이
3계층 구조는 인스턴스, 스키마, 그리고 테이블 목록 구역으로 나눈 구조를 의미한다.
4계층 구조와 다른점은 데이터베이스 계층이 없다는 것이다.
정확히는, 데이터베이스와 스키마를 동의어로 사용하기 때문에 데이터베이스 계층이 따로 없는 것이다.
대표적으로 MySQL 에서 3계층 구조를 따른다.
📘 Oracle 계층 구조
Oracle 은 4계층 구조를 잘 따르는 것처럼 보이지만,
오라클엔 인스턴스 아래에 데이터베이스를 하나만 만들 수 있다는 독자적인 제약이 있다.
때문에 인스턴스를 데이터베이스와 동의어처럼 사용하기도 한다.
따라서 마치 인스턴스/데이터베이스 아래에 바로 스키마가 오는 것 처럼 보여
3계층으로 취급받는 경우도 있다.
📘 DB별 동의어 정리
Oracle
- 서버 인스턴스 = 데이터베이스 = 카탈로그 = 동일한 실행 엔진에 의해 관리되는 모든 데이터
- 스키마 = 데이터베이스 내 네임스페이스 = 사용자 계정
- 사용자 = 스키마 소유자 = 명명된 계정 = 데이터베이스에 연결할 수 있는 사람 = 스키마를 소유하고 다른 스키마에 있는 개체를 사용할 수 있는 사람
- 실행 중인 서버에서 오브젝트(테이블 등)를 식별하려면 스키마 이름 + 오브젝트 이름이 필요하다.
💡 네임스페이스
데이터베이스에서 오브젝트(테이블 등)들을 그룹화하고 식별하는데에 사용되는 개념.
오브젝트의 이름 충돌을 방지하고 오브젝트를 조직화하며 보안 및 권한 관리를 용이하게 한다.
MySQL
- 서버 인스턴스
- 데이터베이스 = 스키마 = 카탈로그 = 서버 내의 네임스페이스
- 사용자 = 명명된 계정 = 서버에 연결하고 하나 이상의 데이터베이스에서 개체를 사용할 수 있지만 소유할 수는 없음(소유권 개념 없음)
- 실행 중인 서버에서 오브젝트(테이블 등) 를 식별하려면 데이터베이스 이름 + 오브젝트 이름이 필요하다.
PostgreSQL
- 서버 인스턴스 = DB 클러스터 = 동일한 실행 엔진에 의해 관리되는 모든 데이터
- 데이터베이스 = 카탈로그 = DB 클러스터 내의 단일 데이터베이스 (동일한 DB 클러스터의 다른 데이터베이스와 격리됨)
- 스키마 = 데이터베이스 내의 네임스페이스 (기본적으로 "public"이 사용됨)
- 사용자 = 데이터베이스에 연결할 수 있고 허용된 각 데이터 베이스의 개체를 개별적으로 소유하고 사용할 수 있는 명명된 계정
- 실행 중인 서버에서 오브젝트(테이블 등) 를 식별하려면 데이터베이스 이름 + 스키마 이름 + 오브젝트 이름이 필요하다.
💡 DB 클러스터
여러 개의 데이터베이스 서버 인스턴스가 협력하여 데이터베이스 작업을 처리하는 분산 시스템
Microsoft SQL Server
- 서버 인스턴스 = 관리되는 데이터베이스 세트
- 데이터 베이스 = 카탈로그 = 서버 내의 네임스페이스
- 스키마 = 소유자 = 데이터베이스 역할에 연결된 데이터베이스 내 네임스페이스가 기본적으로 "dbo"로 사용된다.
- 사용자 = 명명된 계정 = 서버에 연결하고 하나 이상의 데이터베이스에서 개체를 사용할 수 있지만 소유할 수는 없음 (스키마는 소유자로 작동함)
- 실행 중인 서버에서 오브젝트(테이블 등) 를 식별하려면 데이터베이스 이름 + 소유자 + 오브젝트 이름이 필요하다.
이번 포스팅에선 스키마와 카탈로그의 차이, DB 계층 구조, DB 별 동의어에대해 알아보았다.
댓글, 하트, 피드백은 언제나 환영입니다. 😊
