3장 데이터 입출력 구현

Section31. 데이터 모델의 개념

1. 데이터 모델

현실 세계의 정보들을 컴퓨터에 표현하기 위해서 단순화, 추상화하여 체계적으로 표현한 개념적 모델

- 구성요소: 개체, 속성, 관계

- 종류: 개념적 데이터 모델, 논리적 데이터 모델, 물리적 데이터 모델:

- 표시할 요소: 구조, 연산, 제약조건

 

2. 데이터 모델의 구성요소

- 개체(Entity): 데이터베이스에 표현하려는 것으로, 사람이 생각하는 개념이나 정보 단위 같은 현실 세계의 대상체

- 속성(Attribute): 데이터의 가장 작은 논리적 단위로서 파일 구조상의 데이터 항목 또는 데이터 필드에 해당

- 관계(Relationship): 개체 간의 관계 또는 속성 간의 논리적인 연결을 의미

 

3. 개념적 데이터 모델

현실 세계에 대한 인간의 이해를 돕기 위해 현실 세계에 대한 인식을 추상적 개념으로 표현하는 과정

- 현실 세계에 존재하는 개체를 인간이 이해할 수 있는 정보구조로 표현하기 때문에 정보 모델이라고도 한다.

- 대표적인 개념적 데이터 모델: E-R 모델

 

4. 논리적 데이터 모델

개념적 모델링 과정에서 얻은 개념적 구조를 컴퓨터가 이해하고 처리할 수 있는 컴퓨터 세계의 환경에 맞도록 변환하는 과정

- 필드로 기술된 데이터 타입과 이 데이터 타입들 간의 관계를 이용하여 현실 세계를 표현한다.

- 단순히 데이터 모델이라 하면 논리적 데이터 모델을 의미한다.

- 특정 DBMS는 특정 논리적 데이터 모델 하나만 선정하여 사용한다.

- 데이터 간의 관계를 어떻게 표현하느냐에 따라 관계 모델, 계층 모델, 네트워크 모델로 구분한다.

 

5. 논리적 데이터 모델의 품질 검증

완성된 논리 데이터 모델이 기업에 적합한지를 확인하기 위해 품질을 검증하는 것

- 개체, 속성, 관계, 식별자, 모델 전반 등에 대하여 검토 체크리스트를 작성하고 체크리스트의 각 항목을 확인하는 방식으로 검증한다.

- 개체 품질 검증 항목: 단수 명사 여부, 개체의 주 식별자, 개체간 상호 배타성, 개체의 정규화 여부, 개체 상세 정의, 개체 관리 업무 기능, 개체에 2개 이상의 속성 존재 여부, 개체의 총 길이, 개체 동의어 여부, 개체 분산 요구 등

- 속성 품질 검증 항목: 단수 명사 여부, 속성의 값 존재 여부 및 개수, 도메인 정의, 반복되는 속성, 그룹화 가능 속성, 주 식별자 및 비 식별자에 의존하는 속성, 다치 종속 속성 등

- 관계 품질 검증 항목: 관계의 명칭, 2개 이상의 노드와 관계 존재 여부, 노드의 기수성과 선택성, 필수적 관계, 유효한 관계, 중복된 관계, 외부식별자 존재여부, 참조 무결성 여부 등

- 식별자 품질 검증 항목: 식별자의 명칭, 정의, 구성, 적합성, 크기, 순서 등

- 전반적인 품질 검증 항목: 주제 영역 구성의 적절성, 데이터 모델 상에 정규화여부, 다대다 관계 해소 여부, 이력 관리 대상 선정 확인 등

 

6. 데이터 모델에 표시할 요소

- 구조(Structure): 논리적으로 표현된 개체 타입들 간의 관계로서 데이터 구조 및 정적 성질을 표현

- 연산(Operation): 데이터베이스에 저장된 실제 데이터를 처리하는 작업에 대한 명세로서 데이터베이스를 조작하는 기본 도구

- 제약조건(Constraint): 데이터베이스에 저장될 수 있는 실제 데이터의 논리적인 제약조건

 

 

Section32. 이상/함수적 종속/정규화

1. 이상(Anomaly)

테이블에서 일부 속성들의 종속으로 인해 데이터 중복이 발생하고, 이 중복(Redundancy)에 의해 테이블 조작 시 문제가 발생하는 현상

=> 종류: 삽입 이상, 삭제 이상, 갱신 이상

* 삽입 이상(Insertion Anomaly)

테이블에 데이터를 삽입할 때 의도와는 상관없이 원하지 않은 값들로 인해 삽입할 수 없게 되는 현상

* 삭제 이상(Deletion Anomaly)

테이블에서 한 튜플을 삭제할 때 의도와는 상관없는 값들도 함께 삭제되는, 즉 연쇄 삭제가 발생하는 현상

* 갱신 이상(Update Anomaly)

테이블에서 튜플에 있는 속성 값을 갱신할 때 일부 튜플의 정보만 갱신되어 정보에 불일치성(Inconsistency)이 생기는 현상

 

2. 함수적 종속(Functional Dependency)

어떤 테이블 R에서 X와 Y를 각각 R의 속성 집합의 부분 집합이라 하자. 속성 X의 값 각각에 대해 시간에 관계없이 항상 속성 Y의 값이 오직하나만 연관되어 있을 때 Y는 X에 함수적 종속 또는 X가 Y를 함수적으로 결정한다고 하고, X->Y로 표기

 

예제1)

<학생 테이블>

학번	이름	학년	학과
400	이순신	4	컴퓨터 공학과
422	유관순	4	물리학과
301	강감찬	3	수학과
320	홍길동	3	체육과

=> <학생>테이블에서 이름,학년,학과는 각각 학번 속성에 함수적 종속이다. 이 것을 기호로 표시하면 다음과 같다.

예) 학번->이름,학년,학과

     학번->이름, 학번->학년, 학번->학과

- X->Y의 관계를 갖는 속성 X와 Y에서 X를 결정자(Determinant)라 하고,  Y를 종속자(Dependent)라고 한다.

 

예제2) 

<수강>

학번	과목번호	성적	학년
100	C413	A	4
100	E412	A	4
200	C123	B	3
300	C312	A	1
300	C324	C	1

=> 학번,과목번호->성적, 학번->학년

- <수강>테이블의 속성 중 성적은 (학번, 과목번호)에 완전 함수적 종속(Full Functional Dependency)라고 한다.

- 반면에 <수강>테이블의 속성 중 학년은 (학번, 과목번호)에 완전 함수적 종속이 아니므로 부분 함수적 종속(Partial Functional Dependency)라고 한다.

 

3. 정규화(Normalization)

테이블의 속성들이 상호 종속적인 관계를 갖는 특성을 이용하여 테이블을 무손실 분해하는 과정이다.

- 목적: 가능한 한 중복을 제거하여 삽입,삭제,갱신 이상의 발생 가능성을 줄이는 것

- 제1정규형(1NF), 제2정규형(2NF), 제3정규형(3NF), BCNF, 제4정규형(4NF), 제5정규형(5NF)

 

4. 정규화 과정

* 제1정규형

테이블 R에 속한 모든 속성의 도메인(Domain)이 원자 값(Atomic Value)만으로 되어 있는 정규형이다.

* 제2정규형

테이블 R이 제1정규형이고, 기본키가 아닌 모든 속성이 기본키에 대하여 완전 함수적 종속을 만족하는 정규형이다.

(부분 함수적 종속 제거)

* 제3정규형

테이블 R이 제2정규형이고 기본키가 아닌 모든 속성이 기본키에 대해 이행적 함수적 종속을 만족하지 않는 정규형이다.

* BCNF

테이블 R에서 모든 결정자가 후보키인 정규형이다.

* 제4정규형

테이블 R에 다중 값 종속(다치종속) A->->B가 존재할 경우 R의 모든 속성이 A에 함수적 종속 관계를 만족하는 정규형이다.

* 제5정규형

테이블 R의 모든 조인종속이 R의 후보키를 통해서만 성립되는 정규형이다.

 

 

Section33. 논리 데이터 모델의 물리 데이터 모델로 변환

1. 테이블(table)

데이터를 저장하는 데이터베이스의 가장 기본적인 오브젝트

- 칼럼(column,열)과 로우(row,행)으로 구성

- 테이블의 구성 요소

로우(row)	튜플, 인스턴스, 어커런스라고도 한다.
컬럼(column)	각 속성 항목에 대한 값을 저장한다.
기본키(primary key)	- 기본키는 후보키 중에서 선택한 주키(Main Key)이다. - 한 릴레이션에서 특정 튜플을 유일하게 구별할 수 있는 속성이다.
외래키(Foreign Key)	- 다른 릴레이션의 기본키를 참조하는 속성 또는 속성들의 집합을 의미한다. - 한 릴레이션에 속한 속성 A와 참조 릴레이션의 기본키인 B가 동일한 도메인 상에서 정의되었을 때의 속성 A를 외래키라고 한다.

2. 엔티티(Entitiy)를 테이블로 변환

논리 데이터 모델에서 정의된 엔티티를 물리 데이터 모델의 테이블로 변환하는 것

- 엔티티를 테이블로 변환한 후, 테이블 목록 정의서를 작성한다.

- 테이블 목록 정의서: 전체 테이블을 목록으로 요약 관리하는 문서로, 테이블 목록이라고도 한다.

- 변환 규칙

논리적 설계(데이터 모델링)	물리적 설계
엔티티(Entity)	테이블(Table)
속성(Attribute)	컬럼(Column)
주 식별자(Primary Identifier)	기본키(Primary Key)
외부 식별자(Foreign Identifier)	외래키(Foreign Key)
관계(Relationship)	관계(Relationship)

3. 슈퍼타입/서브타입을 테이블로 변환

- 슈퍼타입 기준 테이블 변환

서브타입을 슈퍼타입에 통합하여 하나의 테이블로 만드는 것이다. 서브타입에 속성이나 관계가 적을경우 사용하는 방법으로, 하나로 통합된 모든 테이블에 서브타입의 모든 속성이 포함되어야 한다.

장점	- 데이터의 액세스가 상대적으로 용이하다. - 뷰를 이용하여 각각의 서브타입만을 액세스하거나 수정할 수 있다. - 서브타입 구분이 없는 임의 집합에 대한 처리가 용이하다 - 여러 테이블을 조인하지 않아도 되므로 수행 속도가 빨라진다. - SQL 문장 구성이 단순해진다.
단점	- 테이블의 컬럼이 증가하므로 디스크 저장 공간이 증가한다. - 처리마다 서브타입에 대한 구분(TYPE)이 필요한 경우가 많이 발생한다. - 인덱스 크기의 증가로 인덱스 효율이 떨어진다.

- 서브타입 기준 테이블 변환

슈퍼타입 속성들을 각각의 서브타입에 추가하여 서브타입들을 개별적인 테이블로 만드는 것이다.

서브타입에 속성이나 관계가 많이 포함된 경우 적용한다.

장점	- 각 서브타입 속성들의 선택 사양이 명확한 경우에 유리하다. - 처리할 때마다 서브타입 유형을 구분할 필요가 있다. - 여러개의 테이블로 통합하므로 테이블당 크기가 감소하여 전체 테이블 스캔시 유리하다.
단점	- 수행 속도가 감소할 수 있다. - 복잡한 처리를 하는 SQL통합이 어렵다. - 부분 범위에 대한 처리가 곤란해진다. - 여러 테이블을 통합하는 뷰는 조회만 가능하다. - UID의 유지관리가 어렵다.

- 개별타입 기준 테이블 변환

슈퍼타입과 서브타입들을 각각의 개별적인 테이블로 변환하는 것이다.

슈퍼타입과 서브타입 테이블들 사이에는 각각 1:1관계가 형성된다.

* 개별타입 기준 테이블 변환을 적용하는 경우

- 전체 데이터에 대한 처리가 빈번한 경우

- 서브타입의 처리가 대부분 독립적으로 발생하는 경우

- 통합하는 테이블의 컬럼 수가 많은 경우

- 트랜잭션이 주로 슈퍼타입에서 발생하는 경우

- 슈퍼타입의 처리 범위가 넓고 빈번하게 발생하여 단일 테이블 클러스터링이 필요한 경우

장점	- 저장 공간이 상대적으로 작다. - 슈퍼타입 또는 서브타입 각각의 테이블에 속한 정보만 조회하는 경우 문장 작성이 용이하다.
단점	슈퍼타입 또는 서브타입 정보를 같이 처리하면 항상 조인이 발생하여 성능이 저하된다.

4. 속성을 컬럼으로 변환

- Primary UID를 기본키로 변환

논리 데이터 모델에서의 Primary UID는 물리 데이터 모델의 기본키로 만든다.

- Primary UID(관계의 UID Bar)를 기본키로 변환

다른 엔티티와의 관계로 인해 생성된 Primary UID는 물리 데이터 모델의 기본키로 만든다.

- Secondary(Alternate) UID를 유니크 키로 변환

논리 모델링에서 정의된 Secondary UID 및 Alternate key는 물리모델에서 유니크 키로 만든다.

 

5. 관계를 외래키로 변환

논리 데이터 모델에서 정의된 관계는 기본키와 이를 참조하는 외래키로 변환한다.

- 1:1 관계: 개체 A의 기본키를 개체 B의 외래키로 추가하거나 개체 B의 기본키를 개체 A의 외래키로 추가하여 표현한다.

- 1:M 관계: 개체 A의 기본키를 개체 B의 외래키로 추가하여 표현하거나 별도의 테이블로 표현한다.

- N:M 관계: 릴레이션 A와 B의 기본키를 모두 포함한 별도의 릴레이션으로 표현한다. 이 때 생성된 별도의 릴레이션을 교차 릴레이션, 또는 교차 엔티티라고 한다.

- 1:M 순환 관계: 개체 A에 개체 A의 기본키를 참조하는 외래키 컬럼을 추가하여 표현한다. 데이터의 계층 구조를 표현하기위해 주로 사용

 

6. 관리 목적의 테이블/컬럼 추가

존재하지 않는 테이블이나 컬럼을 데이터베이스의 관리 혹은 데이터베이스를 이용하는 프로그래밍의 수행 속도를 향상시키기 위해 물리 데이터 모델에 추가할 수 있다.

 

7. 데이터 타입 선택

=> 문자 타입, 숫자 타입, 날짜 타입

CHAR: 고정길이 문자열

VARCHAR2: 가변길이 문자열

NUMBER: 38자릿수의 숫자 저장 가능

DATE: 날짜 저장

 

 

Section34. 반정규화(Denormalization)

1. 반정규화

시스템의 성능 향상, 개발 및 운영의 편의성 등을 위해 정규화된 데이터 모델을 통합,중복,분리하는 과정으로, 의도적으로 정규화 원칙을 위배하는 행위이다.

- 반정규화를 수행하면 시스템의 성능이 향상되고 관리 효율성은 증가하지만 데이터의 일관성 및 정합성이 저하될 수 있다.

- 과도한 반정규화는 오히려 성능을 저하시킬 수 있다.

- 반정규화 방법: 테이블 통합, 테이블 분할, 중복 테이블 추가, 중복 속성 추가

 

2. 테이블 통합

두 개의 테이블이 조인(join)되는 경우가 많아 하나의 테이블로 합쳐 사용하는 것이 성능 향상에 도움이 될 경우 수행

- 종류: 1:1 관계 테이블 통합, 1:N 관계 테이블 통합, 슈퍼타입/서브타입 테이블 통합

- 데이터 검색은 간편하지만 레코드 증가로 인해 처리량이 증가한다.

 

3. 테이블 분할

테이블을 수직 또는 수평으로 분할하는 것이다.

 

* 수평 분할(Horizontal Partitioning)

- 수평 분할은 레코드(Record)를 기준으로 테이블을 분할하는 것

- 레코드 별로 사용 빈도의 차이가 큰 경우 사용 빈도에 따라 테이블을 분할한다.

 

* 수직 분할(Vertical Partitioning)

- 수직 분할은 하나의 테이블에 속성이 너무 많을 경우 속성을 기준으로 테이블을 분할하는 것이다.

- 갱신 위주의 속성 분할: 갱신이 자주 일어나는 속성들을 수직 분할하여 사용

- 자주 조회되는 속성 분할: 자주 조회되는 속성이 극히 일부라면, 자주 사용되는 속성들을 수직 분할하여 사용

- 크기가 큰 속성 분할: 이미지가 2GB이상 저장될 수 있는 텍스트 형식등으로 된 속성들을 수직 분할하여 사용

- 보안을 적용해야 하는 속성 분할: 특정 속성에 대해 보안을 적용할 수 없으므로 보안을 적용해야 하는 속성들을 수직분할하여 사용

 

*테이블 분할 시 고려사항

- 기본키의 유일성 관리가 어려워진다.

- 데이터 양이 적거나 사용 빈도가 낮은 경우 테이블 분할이 필요한지 고려해야한다.

- 분할된 테이블로 인해 수행 속도가 늦어질 수 있다.

- 데이터 검색에 중점을 두어 테이블 분할 여부를 결정해야 한다.

 

4. 중복 테이블 추가

여러 테이블에서 데이터를 추출해서 사용해야 하거나 다른 서버에 저장된 테이블을 이용해야 하는 경우 중복테이블을 추가하여 작업의 효율성을 향상시킬 수 있다.

 

* 중복 테이블을 추가하는 경우

- 정규화로 인해 수행 속도가 늦어지는 경우

- 많은 범위의 데이터를 자주 처리해야 하는 경우

- 특정 범위의 데이터만 자주 처리해야 하는 경우

- 처리 범위를 줄이지 않고는 수행 속도를 개선할 수 없는 경우

 

* 중복 테이블을 추가하는 방법

- 집계 테이블의 추가: 집계 데이터를 위한 테이블을 생성하고, 각 원본 테이블에 트리거(Trigger)를 설정하여 사용하는 것으로, 트리거의 오버헤드에 유의해야 한다.

- 진행 테이블의 추가: 이력 관리 등의 목적으로 추가하는 테이블로, 적절한 데이터 양의 유지와 활용도를 높이기 위해 기본키를 적절히 설정해야 한다.

- 특정 부분만을 포함하는 테이블 추가: 데이터가 많은 테이블의 특정 부분만을 사용하는 경우 해당 부분만으로 새로운 테이블을 생성한다.

 

5. 중복 속성 추가

조인해서 데이터를 처리할 때 데이터를 조회하는 경로를 단축하기 위해 자주 사용하는 속성을 하나 더 추가하는 것이다.

- 중복 속성을 추가하면 데이터의 무결성 확보가 어렵고, 디스크 공간이 추가로 필요하다.

 

* 중복 속성을 추가하는 경우

- 조인이 자주 발생하는 경우

- 접근 경로가 복잡한 속성일 경우

- 액세스의 조건으로 자주 사용되는 속성일 경우

- 기본키의 형태가 적절하지 않거나 여러 개의 속성으로 구성된 경우

 

* 중복 속성 추가 시 고려 사항

- 데이터 중복과 속성의 중복을 고려한다.

- 데이터 일관성 및 무결성에 유의해야 한다.

- SQL 그룹 함수를 이용하여 처리할 수 있어야 한다.

- 저장 공간의 지나친 낭비를 고려한다.

 

 

Section35. 인덱스 설계

1. 인덱스(index)

데이터 레코드를 빠르게 접근하기 위해 <키 값, 포인터>쌍으로 구성되는 데이터 구조

- 레코드가 저장된 물리적 구조에 접근하는 방법을 제공

- 인덱스를 통해 파일의 레코드에 대한 액세스를 빠르게 수행할 수 있다.

- 인덱스가 없으면 특정한 값을 찾기위해 모든 데이터 페이지를 확인하는 TABLE SCAN이 발생한다.

- 레코드의 물리적 순서가 인덱스의 엔트리 순서와 일치하게 유지되도록 구성하는 인덱스=> 클러스터드 인덱스

- 인덱스 종류: 트리 기반 인덱스, 비트맵 인덱스, 함수 기반 인덱스, 비트맵 조인 인덱스, 도메인 인덱스 등

 

* 클러스터드 인덱스(Clustered Index) vs 넌클러스터드 인덱스(Non-Clustered Index)

클러스터드 인덱스

- 인덱스 키의 순서에 따라 데이터가 정렬되어 저장되는 방식

- 실제 데이터가 순서대로 저장되어 있어 인덱스를 검색하지 않아도 원하는 데이터를 빠르게 찾을 수 있다.

- 데이터의 삽입, 삭제 발생 시 순서 유지를 위해 데이터를 재정렬해야 한다.

- 한 개의 릴레이션에 하나의 인덱스만 생성 가능

넌클러스터드 인덱스

- 인덱스의 키 값만 정렬되어 있을 뿐, 실제 데이터는 정렬되지 않는 방식이다.

- 데이터를 검색하기 위해서 먼저 인덱스를 검색하여 실제 데이터 위치를 확인해야 하므로 검색 속도가 떨어진다.

- 한 개의 릴레이션에 여러 개의 인덱스를 만들 수 있다.

 

2. 트리 기반 인덱스

인덱스를 저장하는 블록들이 트리 구조를 이루고 있는 것으로, 상용 DBMS에는 주로 B+트리 인덱스를 활용

* B트리 인덱스

* B+ 트리 인덱스

- B트리 변형으로 단말 노드가 아닌 노드로 구성된 인덱스 세트(Index Set)와 단말 노드로만 구성된 순차 세트(Sequence Set)로 구분 된다.

- 인덱스 세트에 있는 노드들은 단말 노드에 있는 키 값을 찾아갈 수 있는 경로로만 제공

- 순차 세트에 있는 단말 노드가 해당 데이터 레코드의 주소를 가리킨다.

 

3. 비트맵 인덱스

인덱스 컬럼의 데이터를 Bit값인 0또는 1로 변환하여 인덱스키로 사용하는 방법

- 목적: 키 값을 포함하는 로우(row)의 주소를 제공하는 것

- 분포도가 좋은 컬럼에 적합하며 성능 향상 효과를 얻을 수 있다.

- bit로 구성되어 있어 효율적인 논리 연산이 가능하고 저장 공간이 작다.

- 동일한 값이 반복되는 경우가 많아 압축 효율이 좋다.

 

4. 함수 기반 인덱스

컬럼의 값 대신 컬럼에 특정 함수(function)나 수식(expression)을 적용하여 산출된 값을 사용하는 것으로, B+트리 인덱스 또는 비트맵 인덱스를 생성하여 사용한다.

- 데이터를 입력하거나 수정 시, 함수를 적용해야 하므로 부하가 발생할 수 있다.

- 사용자 정의함수를 사용할 경우 부하가 더 크다.

- 대소문자, 띄어쓰기 등에 상관없이 조회할 때 유용하게 사용

- 적용가능한 함수의 종류: 산술 식, 사용자 정의 함수, PL/SQL, SQL Function, Package, C callout 등

 

5. 비트맵 조인 인덱스

다수의 조인된 객체로 구성된 인덱스로, 단일 객체로 구성된 일반적인 인덱스와 액세스 방법이 다르다.

- 비트맵 인덱스와 물리적 구조가 동일하다.

 

6. 도메인 인덱스

개발자가 필요한 인덱스를 직접 만들어 사용하는 것으로, 확장형 인덱스라고도 한다.

 

7. 인덱스 설계

분명하게 드러난 컬럼에 대해 기본적인 인덱스를 먼저 지정한 후 개발 단계에서 필요한 인덱스의 설계를 반복적으로 진행한다.

<인덱스 설계 순서>

인덱스의 대상 테이블이나 컬럼 등을 선정한다. => 인덱스의 효율성을 검토하여 인덱스 최적화를 수행한다. => 인덱스 정의서를 작성한다.

 

8. 인덱스 대상 테이블 선정 기준

- MULTI BLOCK READ 수에 따라 판단

- 랜덤 액세스가 빈번한 테이블

- 특정 범위나 특정 순서로 데이터 조회가 필요한 테이블

- 다른 테이블과 순차적 조인이 발생되는 테이블

 

9. 인덱스 대상 컬럼 선정 기준

- 인덱스 컬럼의 분포도가 10~15% 이내인 컬럼

- 분포도가 15% 이상이어도 부분 처리를 목적으로 하는 컬럼

- 입출력 장표 등에서 조회 및 출력 조건으로 사용되는 컬럼

- 인덱스가 자동 생성되는 기본키와 Unique 키 제약조건을 사용한 컬럼

- 가능한 한 수정이 빈번하지 않은 컬럼

- ORDER BY, GROUP BY, UNION이 빈번한 컬럼

- 분포도가 좁은 컬럼은 단독 인덱스 생성

- 인덱스들이 자주 조합되어 사용되는 경우 하나의 결합 인덱스 생성

 

10. 인덱스 설계 시 고려사항

- 새로 추가되는 인덱스는 기존 액세스 경로에 영향을 미칠 수 있다.

- 인덱스를 지나치게 많이 만들면 오버헤드가 발생한다.

- 넓은 범위를 인덱스로 처리하면 오버헤드가 발생한다.

- 인덱스를 만들면 추가적인 저장 공간이 필요하다.

- 인덱스와 테이블 데이터 저장공간이 분리되도록 설계한다.

 

 

Section36. 뷰 설계

1. 뷰(view)

사용자에게 접근이 허용된 자료만을 제한적으로 보여주기 위해 하나 이상의 기본 테이블로부서 유도된, 이름을 가지는 가상 테이블

- 저장장치 내에 물리적으로 존재하지 않는다.

- 조인문의 사용 최소화로 사용상의 편의성을 최대화한다.

 

2. 뷰의 특징

- 뷰는 기본 테이블로부터 유도된 테이블이기 때문에 기본 테이블과 같은 형태의 구조를 사용하며, 조작도 기본 테이블과 거의 같다.

- 뷰는 가상 테이블이기 때문에 물리적으로 구현되어 있지 않다.

- 데이터의 논리적 독립성을 제공할 수 있다.

- 필요한 데이터만 뷰로 정의해서 처리할 수 있기 때문에 관리가 용이하고 명령문이 간단해진다.

- 뷰에 나타나지 않는 데이터를 안전하게 보호하는 효율적인 기법

- 정의된 뷰는 다른 뷰의 정의에 기초가 될 수 있다.

- 뷰가 정의된 기본 테이블이나 뷰를 삭제하면 그 테이블이나 뷰를 기초로 한 다른 뷰도 자동으로 삭제된다.

 

3. 뷰의 장단점

* 장점

- 논리적 데이터 독립성을 제공

- 동시에 여러 사용자의 상이한 응용이나 요구를 지원한다.

- 사용자의 데이터 관리를 간단하게 해준다.

- 접근 제어를 통한 자동 보안이 제공된다.

* 단점

- 독립적인 인덱스를 가질 수 없다.

- 뷰의 정의를 변경할 수 없다.

- 뷰로 구성된 내용에 대한 삽입, 삭제, 갱신 연산에 제약이 따른다.

 

4. 뷰의 설계 순서

 대상 테이블을 선정한다. => 대상 컬럼을 선정한다. => 정의서를 작성한다.

 

5. 뷰 설계 시 고려 사항

- 테이블 구조가 단순화 될 수 있도록 반복적으로 조인을 설정하여 사용하거나 동일한 조건절을 사용하는 테이블을 뷰로 생성한다.

- 동일한 테이블이라도 업무에 따라 테이블을 이용하는 부분이 달라질 수 있으므로 사용할 데이터를 다양한 관점에서 제시해야한다.

- 데이터의 보안 유지를 고려하여 설계한다.

 

 

Section37. 클러스터 설계

1. 클러스터(Cluster)

데이터 저장 시 데이터 액세스 효율을 향상시키기 위해 동일한 성격의 데이터를 동일한 데이터 블록에 저장하는 물리적 저장 방법이다.

- 클러스터링키로 지정된 컬럼 값의 순서대로 저장되고, 여러 개의 테이블이 하나의 클러스터에 저장된다.

 

2. 클러스터의 특징

- 데이터 조회 속도 향상, but 데이터 입력, 수정, 삭제에 대한 성능 저하

- 데이터의 분포도가 넓을 수록 유리하다.

- 저장공간을 절약할 수 있다.

- 대용량을 처리하는 트랜잭션은 전체 테이블을 스캔하는 일이 자주 발생하므로 클러스터링을 하지 않는게 좋다.

- 처리범위가 넓을 경우=> 단일 테이블 클러스터링, 조인이 많이 발생하는 경우=> 다중 테이블 클러스터링

- 파티셔닝된 테이블에는 클러스터링을 할 수 없다.

- 클러스터링을 하면 디스크 I/O가 줄어든다.

- 클러스터링된 테이블에 클러스터드 인덱스를 생성하면 접근 성능이 향상된다.

 

3. 클러스터 대상 테이블

- 분포도가 넓은 테이블

- 대량의 범위를 자주 조회하는 테이블

- 입력, 수정, 삭제가 자주 발생하지 않는 테이블

- 자주 조인되어 사용되는 테이블

- ORDER BY, GROUP BY, UNION이 빈번한 테이블

 

 

Section38. 파티션 설계

1. 파티션(Partition)

대용량의 테이블이나 인덱스를 작은 논리적 단위의 파티션으로 나누는 것

- 테이블이나 인덱스를 파티셔닝 하면 파티션키 또는 인덱스키에 따라 물리적으로 별도의 공간에 데이터가 저장된다.

- 데이터 처리는 테이블 단위로 이뤄지고, 데이터 저장은 파티션 별로 수행된다.

 

2. 파티션의 장단점

* 장점

- 데이터 접근 시 액세스 범위를 줄여 쿼리 성능이 향상된다.

- 파티션 별로 데이터가 분산되어 저장되므로 디스크 성능이 향상된다.

- 파티션 별로 백업 및 복구를 수행하므로 속도가 빠르다.

- 시스템 장애 시 데이터 손상 정도를 최소화할 수 있다.

- 데이터 가용성이 향상된다.

- 파티션 단위로 입출력을 분산시킬 수 있다.

* 단점

- 하나의 테이블을 세분화하여 관리하므로 세심한 관리가 요구된다.

- 테이블 간 조인에 대한 비용이 증가한다.

- 용량이 작은 테이블에 파티셔닝을 수행하면 오히려 성능이 저하된다.

 

3. 파티션 종류

=> 범위 분할, 해시 분할, 조합 분할(범위분할+해시분할)

* 범위 분할(Ranging Partitioning)

: 지정한 열의 값을 기준으로 분할 한다. ex) 일별, 월별, 분기별 등

 

* 해시 분할(Hash Partitioning)

- 해시 함수를 적용한 결과 값에 따라 데이터를 분할한다.

- 특정 파티션에 데이터가 집중되는 범위 분할의 단점을 보완한 것으로, 데이터를 고르게 분산할 때 유용하다.

- 특정 데이터가 어디에 있는지 판단할 수 없다.

- 고객번호, 주민번호 등과 같이 데이터가 고른 컬럼에 효과적이다.

 

* 조합 분할(Composite Partitioning)

- 범위 분할로 분할한 다음 해시 함수를 적용하여 다시 분할하는 방식이다.

- 범위 분할한 파티션이 너무 커서 관리가 어려울 때 유용하다.

 

4. 파티션키 선정 시 고려 사항

- 파티션키는 테이블 접근 유형에 따라 파티셔닝이 이뤄지도록 선정한다.

- 데이터 관리의 용이성을 위해 이력성 데이터는 파티션 생성주기와 소멸주기를 일치시켜야 한다.

- 매일 생성되는 날짜 컬럼, 백업의 기준이 되는 날짜 컬럼, 파티션간 이동이 없는 컬럼, I/O 병목을 줄일 수 있는 데이터 분포가 양호한 컬럼 등을 파티션키로 선정한다.

 

5. 인덱스 파티션

파티션된 테이블의 데이터를 관리하기 위해 인덱스를 나눈 것이다.

 

<파티션된 테이블의 종속여부에 따라>

* Local Partitioned Index

: 테이블 파티션과 인덱스 파티션이 1:1로 대응되도록 파티셔닝

* Global Partitioned Index

: 테이블 파티션과 인덱스 파티션이 독립적으로 구성되도록 파티션

=> Local Partitioned Index가 상대적으로 데이터 관리가 쉽다.

 

<인덱스 파티션키 컬럼의 위치에 따라>

* Prefixed Partitioned Index: 인덱스 파티션키와 인덱스 첫 번째 컬럼이 같다.

* Non-Prefixed Partitioned Index : 인덱스 파티션키와 인덱스 첫번째 컬럼이 다르다.

 

 

Section39. 데이터베이스 용량 설계

1. 데이터베이스 용량설계

데이터가 저장될 공간을 정의하는 것이다.

 

2. 데이터베이스 용량 설계의 목적

- 데이터베이스 용량을 정확히 산정하여, 디스크의 저장 공간을 효과적으로 사용하고 확장성 및 가용성을 높인다.

- 디스크의 입출력 부하를 분산시키고 채널의 병목 현상을 최소화한다.

- 디스크에 대한 입출력 경합이 최소화되도록 설계함으로써 데이터 접근성이 향상된다.

- 데이터베이스에 생성되는 오브젝트의 익스텐트 발생을 최소화하여 성능을 향상시킨다.

- 데이터베이스 용량을 정확히 분석하여 테이블과 인덱스에 적합한 저장 옵션을 지정한다.

 

* 데이터 접근성을 향상시키는 설계방법

- 테이블의 테이블 스페이스와 인덱스의 테이블 스페이스를 분리하여 구성

- 테이블 스페이스와 임시 테이블 스페이스를 분리하여 구성

- 테이블을 마스터 테이블과 트랜잭션 테이블로 분류

 

3. 데이터베이스 용량 분석 절차

데이터 예상 건수, 로우 길이, 보존 기간, 증가율 등 기초 자료를 수집하여 용량을 분석한다.

=> 분석된 자료를 바탕으로 DBMS에 이용될 테이블, 인덱스 등 오브젝트별 용량을 산정한다.

=> 테이블과 인덱스의 테이블 스페이스 용량을 산정한다.

( 테이블 스페이스의 용량은 테이블 스페이스에 생성되는 테이블 용량을 모두 더한값에 약 40%정도를 추가하여 산정)

=> 데이터베이스에 저장될 모든 데이터 용량과 데이터베이스 설치 및 관리를 위한 시스템 용량을 합해 디스크 용량을 산정한다.