파일 구조

# 파일 구조
1. 파일
- 데이터베이스는 많은 파일들로 구성
- 디스크에 영구적으로 저장
- 일련의 레코드들의 논리적인 구조 (레코드들은 디스크의 블록에 대응)

2. 블록
- 파일 구성
- 고정길이 저장 단위 -> 저장장소 할당과 데이터 전송의 단위
- 4~8KB
- 여러 레코드들로 구성
- 블록보다 큰 레코드는 없는 것으로 가정 (Large Object는 예외 : 주소 사용)
- 본체와 디스크 사이의 입출력 단위
- 연속된 섹터들

3. 레코드
- 각 레코드는 단일 블록에 온전히 저장
- 여러 블록에 걸쳐 저장되지 않음(비워두고 다음 블록에 저장)
- 여러 개의 pgm language : 필드(db language : attribute, column)로 구성

 

# 고정길이 레코드
type instructor = record

                          ID char(5);

                          name char(20);

                          dept_name char(20);

                          salary numeric(8, 2);

                      end
- 하나의 레코드는 53바이트로 고정
- 연속적으로 배정
- 블록의 크기가 53 배수가 아닐 경우에 빈 공간을 남김

 

 

# 삭제 시 삭제된 공간 처리

=> record 3 삭제
1. 삭제된 레코드 뒤에 있는 레코드를 모두 이동 -> 많은 레코드 이동 발생

2. 해당 블록의 마지막 레코드를 옮김

=> record 11을 record 3 위치로 옮김

3. 나중의 삽입을 대비하여 빈 공간을 남겨 둠

- Free List 운영
- 비어 있는 공간을 파일 앞부분에 파일 헤더 할당
- 파일 헤더에 삭제된 첫 번째 레코드 주소 기록
- 공간에 삽입되면 시작 주소 변경
- 고정길이 레코드의 삽입, 삭제는 상대적으로 간단
- 공간이 없을 경우 파일 끝에 추가

 

 

# 가변길이 레코드
type instructor = record

                          ID varchar(5);

                          name varchar(20);

                          dept_name varchar(20);

                          salary numeric(8, 2);

                      end

- 공간을 알뜰하게 사용하기 위함
- 한 개 이상의 필드가 가변 길이를 허용
- 한 개 이상의 필드가 배열이나 다중 값을 허용
- 가변길이 속성은 (offset, length)로 표현
  offset: 레코드 내에서 해당 속성 값이 시작되는 위치
  length: 해당 속성 값의 길이
- Null bitmap: Null을 가지는 속성 위치를 표현

# 가변길이 레코드 블록 내에서의 표현
# 블록의 시작 부분
- 블록 내 레코드 수
- 블록에서의 빈 공간의 끝
- 각 레코드의 위치, 크기를 가지고 있는 배열
- 레코드들은 블록의 끝에서부터 연속적으로 할당
- 데이터 레코드들 <-- 순
- 데이터 레코드들에 대한 정보들은 --> 순

# 레코드 삽입
- Free Space에 할당되고 위치와 크기를 헤더에 추가

# 레코드 삭제
- 차지하고 있던 공간이 비워지고
- 해당 엔트리는 삭제된 것으로 명시(예를 들어 크기 값을 -1로 수정)
- 삭제된 레코드 앞에 위치하고 있던 레코드들을 뒤로 이동  Free Space 확보
- 헤더 정보 수정

# 파일 내에 레코드 구성 방법
- 테이블은 레코드(row)들의 집합
- 이들을 파일 안에 어떻게 구성할 것인가
- 각 테이블 저장을 위하여 독립된 파일이 배정되는 것으로 전제
  : Multitable Clustering File Organization은 본 전제에서 제외

 

 

1. 힙 파일 구조(Heap File Organization)
- 검색키 없음
- 파일 안에 레코드를 위한 공간이 있으면 어디든 배정
- 물리적 순서가 없음
- 필드 값의 크기 순서와 물리적 순서가 관계가 없음

2. 순차 파일 구조(Sequential File Organization)
- 주어진 키(검색 키. field, column, attribute 예) 학번) 값에 따라 연속적인 순서로 배정
- 데이터 값의 크기에 따른 순서와 레코드의 파일 내에서의 물리적 순서가 관계있음(동일)

3. 해싱 파일 구조(Hashing File Organization)
- 검색키 존재
- 레코드의 속성(들)을 해시함수에 적용
- 그 결과로 파일 내 위치를 정함
- 차곡차곡 들어가는 것이 아님
- 어떤 위치에 들어갈 것으로 약속

 

# 순차 파일 구조(Sequential File Organization)

- 레코드들의 효율적인 처리를 위하여 주어진 검색키를 기준으로 정렬된 순서로 설계
- 검색키 : 
  특정 속성(들), 반드시 Primary Key나 Super Key일 필요는 없음. 
  where 절에 등장하는 column
- 이들을 포인터로 연결
- 가능한 한 검색키 순서와 동일하게 물리적 순서를 가지도록 저장
- 어떤 테이블은 오직 파일 한 개 파일에만 들어감(구성의 선택지는 한 번 밖에 없음)

 

# 순차파일 구조 : 삽입

- 삽입 후에도 물리적 순서를 유지하는 것은 부담 => 다른 공간에 두고 포인터 이용
- 삽입 레코드 배정 :
  삽입할 위치의 블록에 빈 공간이 있으면 그곳에 배정
  없을 경우 Overflow 블록에 배정
- 검색키 순서와 물리적 순서가 다르게 됨
- 그럼에도 불구하고 계속 순차처리를 할 경우 비효율성 증가
- 물리적 순차 성을 가지도록 재구성(다른 곳에 순서대로 다시 적음) => 성능 복구
- 재구성에 많은 비용 발생
- 헤드 움직여야 함(순차 파일 목적과 어긋남)
- 시간에 지남에 따라 성능 떨어짐

 

# 다중 테이블 클러스터링 파일 구조
- 많은 DBMS들이 OS의 파일 처리 시스템에 대하여 직접적으로 의존하지 않는다.
- 한 테이블당 파일 하나씩을 배정하는 대신
- 큰 파일 하나를 하나의 데이터베이스에 배정
- 그래도 대부분의 경우 하나의 블록에는 하나의 테이블의 레코드들이 저장됨
- 하지만, 경우에 따라서는 하나의 블록에 2개 이상 테이블의 레코드를 저장하는 것이 효과적일 수 있음
- 테이블 하나당 파일 하나 매칭. 일반적으로 디비에선 여러 개 테이블이 파일 하나에 들어감

=> natural join(department.dept_name == instructor.dept_name)

=> 다중 테이블 클러스터링 파일 구조

 

- instructor 레코드들이 dept_name에 대응하는 department 레코드 근처에 배정됨
- 효과적인 조인 처리 가능
- instructor 레코드의 dept_name은 제거되어 저장됨
- 조인된 레코드 단위에서의 포인터로 연결됨
- department만 요구할 때도 이와 관련된 instructor 레코드들도 함께 접근됨(성능 저하)
- 다중 테이블 클러스터링 구조를 선택할 때는 많이 요구되는 질의에 대한 신중한 분석이 전제되어야 함
- 학과 단위에서만 접근하거나 교수 단위에서만 접근하면 성능 떨어짐