Namu | 나무 개발자 블로그입니다

[방통대] 데이터베이스 수업 정리 by namu

Created at
| 2021-03-20 14:42
Updated at
| 2021-04-15 11:58
database image
image by Maksym Kaharlytskyi

목차

  1. 데이터베이스의 이해
  2. 데이터베이스 모델링
  3. 관계형 모델
  4. SQL 1
  5. SQL 2
  6. SQL 3
  7. 정규화
  8. 연습문제 풀이01
  9. 데이터 저장과 파일
  10. 인덱싱
  11. 해싱과 특수 인덱스

참조


들어가며

다음은 2021학년도 1학기 데이터베이스 수업에 대한 정리입니다.


1. 데이터베이스의 이해

데이터베이스 시스템이 만들어진 이유는 급격한 사회 트렌드의 변화 속에서 빠르게 증대되는 데이터를 효율적으로 관리할 필요성이 높아졌기 때문입니다. 실제로 데이터 세계의 총량은 2013년 4.4 ZB(제타바이트) 규모였으나 2020년 44 ZB 규모로 증대될 것이라 예측되었고, 현재는 60 ZB 분량으로 늘어났다고 합니다.

데이터베이스의 역할

데이터베이스 시스템은 이와 같이 많은 데이터를 저장 및 관리하고 필요한 데이터를 신속히 검색할 수 있도록 보조하는 장치입니다.

데이터 관리의 역사 history of database

전통적 데이터 관리 방식(데이터베이스 시스템 이전)을 살펴보기 위해 파일 처리 시스템에 주목해 봅시다. 학적, 성적, 수강 관리 어플리케이션이 각각 존재한다고 했을 때, 파일 처리 시스템에서는 이들의 데이터를 파일의 형태로 따로따로 저장했습니다. 단순히 데이터를 저장하는 수준이었던 이 방식에는 몇 가지 문제점이 존재했는데, 데이터 종속의 문제(물리적, 논리적 종속), 데이터 중복의 문제(일관성, 보안성, 경제성 저해), 무결성 훼손의 문제(데이터의 제약조건 불만족, 정확성x), 동시 접근의 문제(일관성 훼손) 들이 그것입니다.

데이터베이스의 특징

데이터베이스 시스템의 사용은 데이터의 사용과 관리 영역을 철저히 분리하여 파일 처리 시스템의 문제점을 해결하는 데 그 의미가 있습니다. 기본 원리는 데이터베이스 시스템이 중간관리자 역할을 하여 어플리케이션 혹은 사용자가 직접적으로 데이터에 접근하지 못하도록 하는 것입니다. 데이터에 접근 가능한 것은 오직 데이터베이스 시스템뿐이며 이 중간관리자를 DBMS(Database Management System)라고 부릅니다.

데이터베이스 시스템의 구성 structure of database system

데이터베이스의 특징은 다음과 같습니다.

1. 데이터베이스 시스템의 자기 기술성

2. 프로그램과 데이터의 격리 및 추상화

3. 다중 뷰 제공

4. 데이터 공유와 다수 사용자 트랜잭션 처리

데이터베이스의 구성요소

데이터베이스 언어

데이터베이스 시스템 아키텍쳐

데이터베이스 시스템이라 함은 단순히 데이터 저장의 측면 뿐만 아니라 클라이언트가 데이터에 어떠한 방식으로 접근 및 처리를 하는지에 대해 전체적으로 설계된 아키텍쳐(구조)를 의미합니다.

분산 시스템 방식은 부하를 분산하고 소프트웨어 유지보수 비용 절감 및 이식성 증대의 측면에서 효율적입니다. 또한 분산 시스템은 비즈니스 로직 어플리케이션 서버가 추가적으로 분리되었는지 여부에 따라 2계층 구조와 3계층 구조로 나뉩니다.


2. 데이터베이스 모델링

데이터베이스를 사용하기 위한 계획을 세우는 과정을 모델링이라고 합니다.

데이터베이스 모델링의 이해

데이터 모델이란 요구사항에 필요한 데이터를 선별하고 구조화하기 위해 표준적으로 정의된 개념 틀이라고 생각하면 됩니다. 우리가 필요한 데이터는 이렇게 설계된 모델에 맞게 저장 및 사용되죠.

데이터 모델: 의미, 데이터 타입, 연산 등을 명시하기 위해 사용할 수 있는 개념들의 집합

데이터 모델링이라 함은 실세계의 일부분을 구조화된 데이터 모델의 형태로 나타내는 과정입니다. 데이터 모델링은 아래의 단계에 맞게 진행됩니다.

1. 개념적 데이터 모델링 - 요구사항의 해석 오류를 방지 - 데이터 구조, 데이터 타입, 속성, 관계, 제약조건 등을 이끌어내는 과정

2. 논리적 데이터 모델링 - 특정 DBMS의 구현 모델에 맞춰 데이터를 표현하는 과정 - 데이터 정의 언어(DDL)로 기술된 개념 스키마 생성

3. 물리적 데이터 모델링 - 데이터베이스 파일의 내부 저장구조, 파일 구성, 인덱스, 접근 경로 등을 결정하는 과정

사용자 요구사항 분석

ER 모델

ER 모델은 실세계의 속성들로 이루어진 개체(Entity)와 개체 간 관계(Relationship)를 정형화시킨 모델이며, 데이터베이스 시스템 구현 과정 중 개념적 모델링 단계에서 ER 표현을 위해 사용됩니다. 이것은 ER 다이어그램(ERD)로 표현됩니다. 그 구성요소는 다음과 같습니다.


3. 관계형 모델

관계형 모델은 논리적 모델링 단계에서 산출됩니다. 이는 이전 단계인 개념적 모델링의 개체-관계모델(ERD)을 통해 도출됩니다.

개념 단계를 넘어서 DBMS에서 사용하는 데이터 모델에 맞추어 데이터를 표현해야 하는데 이를 논리적 데이터 모델링이라 합니다. 이것의 최종 목적은 데이터 정의 언어로 기술된 개념 스키마를 생성하여 관계형 모델을 만드는 것입니다.

관계형 모델의 개념

릴레이션의 구성과 특징

relation01

  • 레코드의 유일성: 중복된 레코드의 존재 불가능
  • 레코드의 무순서성: 레코드 순서는 의미가 없음
  • 컬럼의 무순서성: 컬럼도 순서가 없으며, 이름과 값의 쌍임
  • 컬럼값의 원자성: 모든 값들은 나눌 수 없는 단 하나의 의미

앞서 개체 집합에는 키 속성이 있다고 했는데, 릴레이션에서 이것은 유일성을 가지는 키 컬럼으로 지정할 수 있습니다. 예를 들어 학과 릴레이션에서 학과명 혹은 전화번호가 그것입니다.

유일성을 가진 릴레이션 키 속성은 개체 집합에서의 키 속성과 한 가지 차이점이 있습니다. 그것은 최소성(Irreducibility)인데, 레코드를 대표하는 식별키는 군더더기를 제외한 가장 간결한 값이어야 합니다.

키의 종류 및 속성

  • 키의 속성 » 유일성(Uniqueness), 최소성(Irreducibility)
  • 키의 종류
    • 수퍼키(super key): 유일성 만족
    • 후보키(candidate key): 유일성, 최소성 만족
    • 기본키(PK: primary key): 레코드의 구분을 위해 선택된 후보키
    • 외래키(FK: foreign key): 참조된 다른 릴레이션의 기본키

유일성을 만족시키기 위해서는 학과명 컬럼 하나만으로도 가능하지만, 학과명+단과대학의 결합으로도 유일성을 만족시킬 수 있습니다. 따라서 특별한 사유가 있는것이 아니라면 릴레이션의 기본키 속성으로 선택되기 위해서는 최소성까지도 만족하는 학과명만을 사용하게 됩니다.

또는 유일성+최소성을 만족시키는 주소 컬럼, 전화번호 컬럼 등을 기본키로 선택할 수 있습니다. 이렇게 기본키가 될 수 있는(유일성+최소성을 만족하는) 컬럼을 후보키라고 합니다.

외래키는 릴레이션 간의 관계를 표현할 때 유용합니다. 예를 들어 교수의 소속 학과를 저장하기 위해서는 교수 릴레이션에 소속학과 외래키(FK)를 지정하게 됩니다. 앞서 1장에서 파일 처리 시스템은 여러 파일에 걸쳐 동일한 데이터가 존재하는 데이터 중복의 문제가 있다고 했는데, 외래키를 사용하면 교수가 속한 학과의 정보는 학과 릴레이션에 한 번만 저장되기 때문에 이 문제를 해결할 수 있습니다.

relation02

DBMS(매니지먼트 시스템)는 데이터의 무결성을 만족시키기 위해 관계형 모델에 제약조건을 가지고 있습니다. 파일 처리 시스템에서는 데이터를 넣는 대로 파일에 저장이 되었으나, DBMS 에서는 관리 시스템이 이를 차단하게 됩니다.

관계형 모델의 제약조건

  • 영역 제약조건: 컬럼에 정의된 도메인(domain, 영역)에 속한 값으로만 컬럼값이 결정
  • 키 제약조건: 유일성과 최소성을 만족하지 않는 데이터는 키 컬럼에 입력되지 않음
  • 개체 무결성 제약조건: 어떠한 기본키(PK) 값도 널(null)이 될 수 없음
  • 참조 무결성 제약조건: 반드시 존재하는 레코드의 기본키만 참조 가능

여기서 널(null)은 ‘아직 데이터를 알 수 없다’의 의미입니다. 미지의 값이라는 것이죠. ‘0’이나 ‘없음’과는 다른 값입니다. 따라서 기본키에 null 값을 넣을 수 있다면 null 이 있는 레코드 자체를 식별할 수 없게 됩니다. > 개체 무결성 제약조건

ERD의 변환

논리적 데이터 모델링은 DBMS의 구현 모델에 맞춰 데이터를 표현하는 과정입니다. 개념적 데이터 모델링에서 생성된 ERD를 DBMS에 최적화하여 구현하는 것이죠. 우리가 데이터베이스를 사용할 때 실제 커뮤니케이션하는 층위는 DBMS이기 때문에 이 과정은 필요합니다.

또한 이 과정에서는 데이터 정의 언어(DDL)로 기술합니다.

관계형 모델로 변환 방법

  1. 개체 집합: 개체 집합은 릴레이션으로 변환
  2. 약한 개체 집합: 강한 개체 집합의 키 속성을 약한 개체 집합의 릴레이션에 포함
  3. 일대일 관계: 두 릴레이션 중에서 한 릴레이션의 PK를 다른 릴레이션의 FK로 참조
  4. 일대다 혹은 다대일 관계: ‘일’쪽의 PK를 ‘다’쪽 릴레이션에서 FK로 참조
  5. 다대다 관계: 관계 릴레이션을 생성하고, 두 릴레이션의 PK를 각각 참조하는 FK를 복합키 형태의 컬럼으로 구성
  6. 다중값 속성: 릴레이션의 PK를 참조하는 FK와 다중값 속성으로 별도 릴레이션 구성
  7. 관계 집합의 속성: FK가 위치한 릴레이션의 컬럼으로 삽입

그럼 ER 다이어그램을 관계형 모델로 변환해 봅시다. 교수 개체 집합과 과목 개체 집합 간의 관계입니다.

(교수) <- <강의> = (과목)

erd_relation01

이는 일대다 관계입니다. 따라서 ‘다’쪽의 과목 릴레이션에 ‘일’쪽 교수 릴레이션의 PK가 교수번호 FK로써 저장되었습니다.

(학생) - <수강> - (과목)

erd_relation02

이번에는 다대다의 관계입니다. 학생 릴레이션의 PK, 과목 릴레이션의 PK 각각을 PK, FK 쌍으로 갖는 수강 릴레이션이 생성되었습니다. 여기에는 수강 신청시각의 관계집합의 속성이 컬럼으로 저장될 수 있습니다.

다음으로는 특수한 상황입니다. 약한 개체 집합을 릴레이션으로 표현하는 경우인데요,

(학생) <- «보유» -> (계좌)

erd_relation03

기본적으로는 일대일의 관계이지만, 계좌 개체 집합이 약한 개체 집합이므로 강한 개체 집합인 학생 개체 집합의 의존적인 데이터가 사라지면 약한 개체 집합의 계좌 데이터도 함께 사라져야만 합니다.

일대일에서 릴레이션의 FK는 어느 쪽에 추가해도 상관없지만(가급적 개수가 적은 쪽으로, 의미적으로 의존적인 쪽으로), 약한 개체 집합의 경우는 계좌 릴레이션에 학생 릴레이션의 학생번호 PK를 FK로써 저장해야 합니다. 또한 연쇄삭제를 의미하기 위해 학생번호 FK를 PK의 제약조건까지 만족하는 복합키로써 지정합니다. » 계좌번호+학생번호(복합키: PK, FK)

데이터 연산

위 과정을 통해 도출된 관계형 모델을 통해 관계 연산을 수행할 수 있습니다. 관계 연산은 DBMS가 결과적으로 여러 릴레이션 간의 관계를 하나의 릴레이션으로 표현하여 보여주기 위해 필요합니다.

관계 연산을 정의하기 위해 관계 대수(relational algebra)를 활용합니다. 이때 연산자는 다음과 같습니다.

relational algebra 출처: mathcs

각각 순서대로 합집합, 교집합, 차집합, 카티션, 셀렉션, 프로젝션, 조인, 디비전 등등입니다. 관계 대수 연산자의 중첩을 통해 연산 처리 절차 자체를 표현할 수도 있고, 이 결과 생성된 임시 릴레이션은 사용자가 원하는 데이터셋을 가공하여 보여줍니다.

여기서 집합 연산자(합, 교, 차, 카티션)의 경우는 각 릴레이션을 하나의 집합으로, 레코드를 집합에 포함된 원소로 가정합니다.

관계 대수를 활용한 연산 표현

  • 셀렉션
    • algebra_selection
  • 프로젝션
    • algebra_projection
  • Q1. 직위가 ‘부교수’인 교수의 교수이름을 출력하라.
    • algebra_selection_projection
    • 셀력션 후 프로젝션을 수행하는 연산 처리 절차를 표현
  • 집합 연산자 사용 조건
    • 연산을 위해 릴레이션 R과 S의 차수(컬럼의 개수)가 동일
    • 모든 i에 대해 R의 i번째 컬럼의 도메인과 S의 i번째 컬럼의 도메인이 반드시 동일
  • 카티션 프로덕트 연산
    • 두 릴레이션에 포함된 레코드 간의 모든 조합을 생성하는 이항 연산자 ‘X’(R X S)
    • 카티션 프로덕트는 서로 다른 컬럼과 레코드를 가지고 있는 두 릴레이션을 결합하는 역할
  • 조인(JOIN)
    • 조건 상관 없이 결합하는 카티션과 다르게 특정 조건을 만족하는 릴레이션 간 레코드를 결합
    • algebra_join01
    • 조인의 연산 처리 절차를 살펴보면, 내부적으로 cartesian 이후 selection 이 수행됨을 확인할 수 있습니다.
    • algebra_join02
    • 과목과 교수 릴레이션을 카티션한 후, 교수번호가 동일한 레코드 결과만 셀렉션하는 조인 연산입니다.

위와 같이 여러 조건에 따른 관계성을 표현하는 집합 연산 외에 수량적인 연산이 필요할 수 있습니다. 특정 조건을 만족하는 레코드의 개수 구하기처럼 말이죠. 이때는 sum, avg, count 등의 집계 함수를 사용합니다.

다음은 과목 릴레이션의 과목명 개수를 추출하는 count 집계함수의 활용예입니다.

여기서는 단순히 과목명의 개수를 추출합니다.

그렇다면 소속학과 별 교수가 몇명인지는 어떻게 추출할까요? 학과의 개수를 세서? 교수의 명수를 세서? 한 릴레이션 내에서 특정 조건을 만족하는 개수를 추출할 때는 그룹화(group) 절차를 거칩니다.

연산식을 보면, 소속학과에 따라 레코드들을 그룹화하고, 각 그룹의 레코드 개수를 추출함으로써 원하는 결과를 얻었습니다.


4. SQL 1

SQL을 통해 우리는 DBMS에게 데이터베이스를 조작하도록 명령할 수 있습니다. DBMS를 거치는 이유는 1강에서 살펴 본 파일 처리 시스템의 문제들을 방지하면서 데이터 구조와 데이터를 조작하고, 사용자가 원하는 뷰를 유기적으로 제공하기 위함입니다.

데이터베이스 언어

SQL의 개요 및 특징

개요: Structured Query Language로써, 관계대수에 기초하여 RDBMS의 데이터 관리를 위해 설계된 언어. 특징: 비절차적(선언형) 언어, 필요한 데이터만 기술. 인간의 언어와 매우 유사하고 간단, 명료.

데이터베이스 언어에는 DDL과 DML이 있습니다.

DDL(Data Definition Language), 데이터 정의 언어

먼저 데이터베이스를 생성해 봅시다. 한 조직의 데이터베이스 시스템의 운영에 필요한 모든 객체의 집합을 스키마라고 부르기 때문에 데이터베이스 생성은 곧 스키마 생성을 의미합니다.

create_schema01

일반적으로 ALTER 스키마는 사용하지 않습니다. 데이터베이스 자체는 수정이 아닌 생성하거나 삭제하는 대상으로만 취급되기 때문입니다.

데이터베이스 생성 이후에는 테이블을 생성합니다. 테이블은 스키마에 속하는 릴레이션입니다. ‘교수’릴레이션을 통해 테이블을 생성하는 다음의 예시를 봅시다.

create_table01

위와 같이 테이블은 CREATE TABLE [테이블명] ([상세내용])의 방식으로 생성합니다. 여기서 주목할 부분은 [상세내용] 중 각 컬럼의 데이터 타입과 제약조건입니다.

문자 데이터 타입 중 고정길이 CHAR와 가변길이 VARCHAR의 차이에 주목해 봅시다. 둘다 사이즈 10의 컬럼으로 정의한다고 했을 때, 전자는 언제나 10칸을 차지하는 반면에 후자는 10칸 이하라면 그것에 맞는 크기만 차지합니다.

VARCHAR의 가변길이 특성은 자신 이후에 뒤따르는 다른 컬럼의 저장공간에도 영향을 미쳐 부수적인 작업이 수행되므로 상대적인 성능 저하를 불러올 수 있습니다. 따라서 저장되는 문자열의 길이가 유의미하게 가변적이라면 VARCHAR가 효율적일 수 있고, 반면에 어느 정도 고정된 크기의 입력이 예산된다면 적절한 크기의 CHAR 타입을 사용하는 것을 고려해 보아야 합니다.

다음으로는 테이블을 수정해 봅시다. 테이블 수정의 상황은 컬럼 추가, 수정(이름, 데이터 타입, 제약조건), 삭제가 있습니다. 특히 컬럼의 삭제 혹은 데이터 타입 수정시 데이터가 소실되므로 각별히 주의해야 합니다.

alter_table01

예시로 [교수] 테이블에 INT 데이터 타입의 '나이' 컬럼을 추가는 쿼리는 다음과 같습니다.

ALTER TABLE 교수
    ADD COLUMN 나이 INT

기존의 레코드들에 없던 컬럼이 일괄적으로 추가되는 것이기 때문에 각 값으로 NULL이 투입됩니다.

테이블 삭제 쿼리는 사용이 간단하지만 모든 데이터가 소실되어 복구가 불가능해 그 결과가 치명적일 수 있으므로 각별히 주의해야 합니다. 교수 테이블 삭제 쿼리는 다음과 같습니다.

DROP TABLE 교수

마지막으로, 테이블 관리 시 각 컬럼의 제약 조건을 적절히 설정하는 것은 중요합니다.

테이블을 생성하는 위 그림을 살펴보면, 모든 컬럼에 NOT NULL 제약조건을 지정함을 볼 수 있습니다. 또한 ‘교수번호’ 컬럼에 PRIMARY KEY 제약조건을, ‘소속학과’ 컬럼에 FOREIGN KEY 제약조건을 지정하였습니다. PRIMARY KEY 제약조건은 컬럼 선언 뒷부분에 추가할 수도 있지만, 기본키를 지정할 컬럼을 기술할 때 제약조건 부분에 지정할 수도 있습니다.

DML(Data Manipulation Language), 데이터 조작 언어


5. SQL 2


6. SQL 3


7. 정규화


8. 연습문제 풀이01


9. 데이터 저장과 파일

DBMS는 데이터의 물리적 저장방식을 고도로 추상화하여 제공하기 때문에 사용자 및 개발자는 인터페이스 혹은 논리적 비절차 언어를 활용하기만 하면 되었습니다. 하지만 DBA의 관점에서는 데이터가 물리적으로 어떻게 저장되는 것이 효율적인가에 대해서도 고려해야 합니다.

이번 장에서는 DBMS가 활용하는 컴퓨터 시스템(저장장치, OS)의 물리적 저장장치 계층 구조, 물리적 데이터 파일의 구성 및 저장장치 접근 기법, 관리에 대해 살펴봅니다.

9.1 물리적 저장장치

컴퓨터 시스템의 물리적 저장장치는 데이터 접근 속도, 용량을 기준으로 다양한 장치로 구성됩니다.

물리적 저장장치의 구성

physical disc01 이미지 출처: chogyujin 블로그

각 저장장치의 특성은 다음과 같습니다.

9.2 파일

여러 계층으로 구성된 컴퓨터 저장장치에서 DBMS는 어떻게 데이터를 물리적으로 저장하고 관리할까요? 바로 파일시스템입니다.

물리적 차원에서 DBMS는 OS의 파일시스템에 맞게 파일 단위로 데이터를 관리합니다.

물리적 저장장치

사실 저장장치의 측면에서 파일 자체도 논리적 개념입니다. 파일 내 데이터는 물리적 저장장치에 저장될 때 가장 작은 블럭이라는 데이터 묶음 단위로 나뉘어서 저장됩니다. 그리고 이 블럭은 릴레이션의 레코드들로 구성되어 있습니다.

physical disc02 이미지 출처: firewall 티스토리 블로그

파일의 구성

그렇다면 하나의 블럭에는 데이터가 어떻게 저장될까요? 방금 레코드라고 이야기했는데, 레코드에는 고정 길이 레코드와 가변 길이 레코드가 있습니다.

고정 길이 레코드 방식은 위와 같은 특징이 있습니다. 주목할 부분은 데이터를 장기적으로 운용하면서 수정, 삭제 작업이 지속적으로 발생시 어떤 현상이 일어나는가입니다.

특히 삭제 시에는 삭제 후 중간 공간이 비워지지만 그것을 모두 알 수는 없기 때문에 장기적으로 저장 공간 낭비가 누적됩니다.

이제 가변 길이 레코드를 살펴봅시다. 가변적인 여러 레코드를 한 블럭에 저장하기 위하여 현존하는 가장 효율적인 방법은 슬롯 페이지 구조입니다.

가변 길이 레코드를 효율적으로 관리하기 위해 슬롯 페이지 구조가 사용됩니다.

가변 길이 레코드의 슬롯 페이지 구조에서 레코드 삭제에 대한 대응은 삭제되어 빈 공간 이후의 레코드들을 이동시키는 방식으로 이루어집니다. 이러한 방식은 고정 길이 레코드에서는 이후 모든 레코드와 블럭에 대한 이동을 의미하기 때문에 너무 많은 비용이 소요되지만, 가변 길이 레코드에서는 해당 블럭 내의 레코드들만 이동시키기 때문에 그렇게 많은 비용이 들지 않습니다. 레코드 이동 이후 정보는 블럭 헤더에 반영됩니다.

파일 구조화

이렇게 구성된 블럭들이 모여 파일을 구성합니다.

그런데 가변 길이 레코드에서 보았듯이, 하나의 블럭에서는 여러 릴리에션의 다양한 길이의 레코드가 저장될 수 있고, 반대로 하나의 릴레이션의 레코드들은 빈 공간을 찾아 여러 블럭에 걸쳐서 저장될 수 있습니다.

파일 구조화는 파일 수준에서 릴레이션의 레코드를 관리(순서 등)하는 기법입니다.

시스템에 최적화된 해시 함수를 적용할 수 있다면 해시 파일 구조가 가장 효율적이겠으나, 일반적으로는 파일 구조화 시 탐색키를 활용하는 순차 파일 구조를 차용합니다.

신규 삽입 시 순차 파일 구조의 단점을 개선하기 위해 오버플로우 블럭이 활용됩니다.

9.3 저장장치 관리

지금까지 DBMS가 물리적 저장장치에 데이터를 저장하고 관리하기 위해 사용하는 파일 구조에 대해 알아봤습니다.

앞서 설명했듯 파일 자체는 저장장치의 관점에서 봤을 때 논리적 저장 객체입니다. 실체 물리적 관점에서는 여러 개의 블럭으로 저장되며, 블럭은 고정적 혹은 가변적 형태의 레코드로 구성되어 있습니다.

이러한 저장장치에 저장된 데이터에는 어떤 식으로 접근하게 될까요? 가장 주목해야 할 점은 효율성과 속도입니다.

저장장치 접근

우선 최소 단위인 블럭을 살펴봅시다.

프로그램에서 사용중인 메모리보다는 디스크의 읽기 속도가 더 느리기 때문에 효율성의 측면에서는 디스크 읽기 횟수가 적을 수록, 메모리에 적재한 블럭의 활용 빈도가 높을수록 효율적입니다.

하지만 메모리의 가용량은 한정적인 경우가 많으므로 한 번에 불필요하게 많은 데이터(블럭)을 읽어들이면 비효율적일 수 있습니다. 따라서 적절한 크기의 블럭을 한 번에 읽어들여 여러 번 재사용 할수록 좋습니다.

또한 적재된 블럭 중 사용되지 않는 블럭은 할당을 해제하고 새 블럭을 읽어들일 수도 있습니다. 이러한 작업을 위해 DBMS는 버퍼 관리자를 두어 메모리 내부 버퍼 공간에 블럭을 적재 혹은 할당 해제하는 등의 관리를 수행합니다.

버퍼 관리자

먼저 DBMS상의 소프트웨어는 필요한 블럭이 있을 때 버퍼 관리자에게 해당 블럭을 요청합니다.

버퍼 교체 전략

교체 전략의 핵심은 위 세 번째 경우에서 할당을 해제할 기존 블럭을 선정하는 것입니다. 가장 안 쓰일것 같은 블럭을 잘 선택하는게 관건이겠죠.

버퍼 교체 전략 중 가장 좋은 것은 없으므로 상황에 맞게 선정해야 합니다. 경우에 따라 LFU(Least ~) 방식을 차용할 수도 있는 것입니다.

추가적인 관리 기법

버퍼 관리자에 의해 블럭이 내보내지는 것을 방지하기 위해 고정해 두는 고정 블럭과 내보내질것 같지는 않지만 강제로 내보내도록 하는 블럭 강제 출력이 있습니다.


10. 인덱싱


11. 해싱과 특수 인덱스

Written on April 15th, 2021 by namu
Feel free to share!

You may also enjoy: