릴레이션 : 레코드들의 집합
파일 안에서 레코드를 어떻게 구성할 것인가?

1. Heap file organization

레코드들 간에 아무 순서 없이 그냥 저장하는 것. 일반적으로 하나의 릴레이션은 하나의 파일로 존재.

2. Sequential file organization

• 레코드들은 검색 키(search key)값에 따라 연속적인 순서로 저장됨.
  (linked list 자료구조와 비슷하게 link를 사용하여 레코드들을 연결)
• 정렬 기준 : search key (반드시 PK일 필요 없다.)
• 모든 레코드들을 순차적으로 접근해야하는 연산이 많이 발생할 때 유리한 구조
• 소수의 레코드를 찾는 연산에서는 비효율적인 구조
• 삽입, 삭제 연산이 빈번할 수록 링크가 복잡해짐 -> 검색 성능 저하, 공간 사용 효율 저하
  -> 파일을 주기적으로 reorganize 해줘야함.

3. Multitable Clustering File Organization

논리적으로 다른 여러 릴레이션들을 동일한 하나의 파일에 저장.
? 왜 이런 구조를 사용할까?

• 특정 테이블 간의 join 질의가 자주 발생할 경우 --> 레코드를 클러스터링 하여 하나의 file에 저장하면 이미 조인 된 것 같은 효과를 얻을 수 있고 block I/O 횟수도 감소하게 됨.

3. Hashing file organization

추후 작성

4. B+ tree file organization

추후 작성

Data Dictionary Storage

데이터 사전 저장소
데이터에 대한 데이터인 메타데이터를 저장하는 공간.
메타데이터?

• 릴레이션에 대한 정보
  • 릴레이션 이름
  • 릴레이션 속성 이름
  • 속성과 도메인 길이
  • 무결성 제약 조건
  • 릴레이션 저장 위치
• 사용자에 대한 정보
  • 권한이 부여된 사용자 이름
  • 사용자 인증하기 위해 사용되는 비밀 번호 혹은 다른 정보
• 통계 데이터
  • 각 릴레이션의 투플 수
  • 각 릴레이션의 저장 방법 (clustering or not clustering)
• 물리적인 저장 구조에 대한 정보
• 인덱스에 대한 정보

이런 메타데이터들 또한 디스크에 관계형 테이블로 저장된다.

Storage Access

• 블록 : storage allocation과 데이터 전송의 단위
• DBMS의 주요 목적은 디스크와 메모리 사이에 블록의 전송 수를 최소화 하는 것
  -> 메인 메모리에 모든 블록을 유지하는 것은 불가능하기 때문에 가능한 많은 블록들을 미리 보유한다.
• Buffer : 디스크 블록의 복사본을 저장하기 위해 이요할 수 있는 메인 메모리의 일부분
• 버퍼 관리자 : 버퍼 공간의 할당을 책임지는 하부 시스템
  버퍼 교체 방법 : LRU (Least Recently Used) : 최근에 가장 적게 사용된 블록을 교체한다.