[DB] 13-4. Data-Dictionary Storage

지금까지 우리는 relation 그 자체의 표현에 대해서만 다뤄왔다.
Relation DataBase System은 relation에 대한 정보를 갖고 있어야 한다. (ex. relation의 스키마)
일반적으로 데이터에 대한 데이터를 metadata라고 한다.

Relational 스키마와 relation에 대한 메타데이터는 data dictionary 또는 system catalog라고 부르는 곳에 저장되어 있다.
data dictionary에 저장되어 있어야 할 데이터들은 다음과 같다.

- relation의 이름
- 각 relation의 속성의 이름
- 속성의 특징(domain), 길이
- 데이터베이스에서 정의된 view의 이름과 view의 정의 
- 무결성 제약조건(Integrity constraint) 

사용자에 관해서는 다음과 같은 정보들을 저장한다.

- 사용자 이름, 사용자의 기본 스키마, 사용자 인증을 위한 비밀번호 또는 관련 정보들
- 각 사용자 확인을 위한 정보 

또한, 데이터베이스는 relation과 속성(attribute)에 대한 통계 및 기술적인 데이터를 저장할 수 있다. 이러한 데이터는 각 relation 내의 튜플 수나 각 attribute의 고유한 값의 개수와 같은 정보를 포함할 수 있습니다.

Data Dictionary는 relation의 저장 구조(heap, sequential, hash 등등)와 각각의 relation이 어디에 저장되어 있는지 기록할 수 있다.

- 만약 relation들이 OS 파일에 저장되어 있다면 dictionary는 각 relation을 포함한 파일의 이름을 저장한다
- DB가 모든 relation들을 하나의 파일에 저장했다면, dictionary는 연결 리스트와 같은 자료구조에 각 relation의 레코드들을 포함한 블록을 저장한다.

14장에서 인덱스에 대해 다룰 때 각 relation에 대한 각각의 index에 대한 정보를 저장할 필요성을 살펴봐야 한다.

- 인덱스의 이름
- 인덱싱된 relation의 이름
- 인덱스가 정의된 속성 
- 인덱스의 타입

위와 같은 모든 메타데이터 정보들은 작은 DB를 구성한다.
일반적으로 데이터베이스에 대한 데이터를 데이터베이스 내의 relation으로 저장하는 걸 더 선호한다.

DB의 relation을 이용해서 메타데이터를 저장함으로써

• 시스템의 구조를 단순화할 수 있고
• DB의 모든 힘을 시스템 데이터에 빠르게 접근하는데 사용할 수 있다.

relation을 통해 시스템의 메타데이터를 어떻게 표현할 지는 시스템 설계자에 의해 선택되어야 한다.

ex) 스키마 다이어그램 예시 그림

아래 스키마는 설명을 위한 것이고 실제로는 더 많은 정보를 저장한다. 사용하고 있는 DB가 어떤 시스템 메타데이터를 유지하는지 알 고 싶다면 꼭 공식문서를 읽어보자.

• Index_metadata relation의 Index_attributes라는 속성은 하나 이상의 속성값들의 리스트를 갖고 있는 걸로 보인다. 이렇게 되면 해당 relation은 제 1정규형을 위반하지만 접근하는데 있어서는 더 효율적인 방법이다.
• DB 시스템이 relation으로 부터 record를 가져올 때 마다 아래와 같은 이유로 Relation_metadata relation을 참고해야 한다.
  • 위치를 찾기 위해서
  • relation의 저장 구성을 찾기 위해서
  • 이러한 정보들을 바탕으로 record를 가져온다.

하지만, Relation_metadata라는 relatoin의 저장 구조와 위치는 다른 곳에 저장되어야 한다. 왜냐하면, Relation_metadata relation의 내용을 찾아야 하기 때문이다.

시스템 메타데이터에 빈번하게 접근해야 하기 때문에 대부분의 DB는 메타데이터를 in-memory 데이터 구조에 있는 database로 부터 원하는 데이터를 읽어온다. 그래서 굉장히 효율적으로 정보에 접근할 수 있기 때문이다.

이러한 작업들은 데이터베이스가 쿼리를 수행하려고 하기 전에 데이터베이스 시작과정의 일부로 수행된다.