정보처리기사 실기 3장 데이터 입 · 출력 구현 요점 정리

1. 데이터 모델의 개념

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

- 데이터, 데이터의 관계, 데이터의 의미 및 일관성, 제약 조건 등을 기술하기 위한 개념적 도구들의 모임

- 현실 세계를 DB에 표현하는 중간 과정, 즉 DB 설계 과정에서 데이터의 구조(Schema)를 논리적으로 표현하기 위해 사용되는 지능적 도구

● 구성 요소

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

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

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

● 개념적 데이터 모델

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

- 속성들로 기술된 개체 타입과 이 개체 타입들 간의 관계를 이용하여 현실 세계를 표현

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

- 대표적으로 E-R 모델

● 논리적 데이터 모델

:  개념적 모델링 과정에서 얻은 개념적 구조를 컴퓨터가 이해 및 처리 가능 환경에 맞도록 변환하는 과정

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

- 데이터 모델이라고 하면 논리적 데이터 모델 의미

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

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

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

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

- 논리 데이터 모델의 품질은 논리 데이터 모델 품질 기준에 따라 개체, 속성, 관계, 식별자 모델 전반 등에 대해 검토 체크리스트를 작성하고 체크리스트의 각 항목을 확인하는 방식으로 검증

● 데이터 모델에 표시할 요소

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

- 연산(Operation) : DB 조작하는 기본 도구

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

 

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

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

- 삽입 이상(Inserion Anomaly) : 삽입 불가

- 삭제 이상(Deletion Anomaly) : 연쇄 삭제

- 갱신 이상(Upadate Anomaly) : 일부 튜플만 갱신되어 정보에 불일치성(Inconsistency) 발생

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

- 함수적 종속은 데이터의 의미를 표현하는 것으로 현실 세계를 표현하는 제약 조건이 되는 동시에 DB에서 항상 유지되어야 할 조건

● 정규화(Nomalization)

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

관계현 DB에서 정확성을 더욱 유지하기 위해 스키마를 쪼개는 과정

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

* - 도메인 원자값 (1NF)

  - 부분적 함수 종속 제거 (2NF)

  - 이행적 함수 종속 제거 (3NF)

  - 결정자이면서 후보키가 아닌 것 제거 (BCNF)

  - 다치 종속 제거 (4NF)

  - 조인 종속성 이용 (5NF)

 

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

● 테이블 : 데이터를 저장하는 DB의 가장 기본적인 오브젝트

● 엔티티를 테이블로 변환

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

- 테이블과 엔티티 명칭은 동일하게 하는 것을 권고

- 엔티티는 주로 한글명을 사용하지만 테이블은 소스코드 가독성을 위해 영문명을 사용

- 표준화된 용어 사용

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

- 슈퍼타입과 서브타입은 논리 데이터 모델에서 이용되는 형태이므로 물리 데이터 모델 설계 시 테이블로 변환해야 함

- 슈퍼타입 기준 테이블 변환 : 서브타입을 슈퍼타입에 통합하여 하나의 테이블로 만듦, 서브타입 속성이나 관계 적을 시 적용

* 장점 : 데이터 액세스 상대적 용이, 뷰 이용하여 각각의 서브타입만을 액세스 하거나 수정 가능, SQL 문장 구성 단순해짐

서브타입 구분 없는 임의 집합에 대한 처리 용이, 수행 속도 빨라짐

*단점 : 디스크 저장 공간 증가, 서브타입에 대한 구분이 필요한 경우 많아짐, 인덱스 효율 떨어짐

- 서브타입 기준 테이블 변환 : 슈퍼타입 속성들을 각각의 서브타입에 추가하여 서브타입들을 개별적인 테이블로 만드는 것, 서브타입에 속성이나 관계가 많이 포함된 경우 적용

* 장점 : 선택 사양 명확한 경우 유리, 처리할 때마다 서브타입 유형 구분할 필요 X, 통합으로 테이블당 크기 감소로 전체 테이블 스캔 시 유리

* 단점 : 수행 속도 감소, SQL 통합 어렵, 부분 범위에 대한 처리 곤란, 여러 테이블 통합한 뷰는 조회만 가능, 식별자 유지 관리 어렵

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

슈퍼타입과 서브타입 테이블들 사이는 각각 1:1 관계 성립

* 개별타입 적용하는 경우 : 처리 빈번한 경우, 서브타입 처리 대부분 독립적인 경우, 통합하는 테이블의 칼럼 수 많은 경우, 서브타입의 칼럼 수가 많은 경우, 트랜잭션이 주로 슈퍼타입에서 발생하는 경우, 단일 테이블 클러스터링이 필요한 경우

* 장점 : 저장 공간 상대적으로 작음, 슈퍼타입 서브타입 각각 테이블에 속한 정보만 조회할 경우 문장 작성 용이

* 단점 : 슈퍼타입 or 서브타입의 정보를 같이 처리하면 항상 조인이 발생하여 성능이 저하됨

● 속성을 칼럼으로 변환

- 논리 데이터 모델에서 정의한 속성을 물리 데이터 모델의 칼럼으로 변환

- 일반 속성 변환 : 칼럼의 명칭은 표준화된 약어 사용하여 일치시키는 것이 좋음, 칼럼명은 SQL 예약어 사용 피함

칼럼명은 가능한 한 짧게 지정, 복합 단어를 칼럼명으로 사용 시 미리 정의된 표준 따름, 테이블의 칼럼을 정의한 후 칼럼 정합성 검증

● 관계를 외래키로 변환

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

- 1:1 관계(테이블을 모두 독립적인 테이블로 변환 시), 1:N 관계, N:M 관계

● 관리 목적의 테이블/칼럼 추가

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

● 데이터 타입 선택

- 정의된 논리적인 데이터 타입을 물리적인 DBMS의 물리적 특성과 성능을 고려하여 최적의 데이터 타입과 데이터의 최대 길이를 선택

- Oracle에서 자주 사용되는 데이터 유형 : CHAR = 고정길이 문자열, VARCHAR2 = 가변 길이 문자열, NUMBER =38자리 숫자

DATE = 날짜 저장

 

4. 반정규화(Denormalization)

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

- 성능 및 효율성 증가, 일관성 및 정합성 저하, 과도한 정규화 성능 저하

- 사전에 데이터의 일관성과 무결성 우선인지, DB의 성능과 단순화를 우선으로 할지 결정

● 테이블 통합 : 두 개의 테이블이 조인되는 경우가 많아 하나의 테이블로 합쳐 사용하여 성능 향상

- 두 개의 테이블서 발생하는 프로세스가 동일하게 자주 처리될 때, 두 개의 테이블 이용하여 항상 조회 수행 경우 고려

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

- 고려 사항 : 레코드 증가로 인해 처리량 증가(검색은 간편), 입력 삭제 수정 규칙 복잡, 제약 조건 설계 어렵

● 테이블 분할 : 수직 or 수평으로 분할

- 수평 분할 : 레코드 기준으로 테이블 분할, 레코드 별로 사용 빈도 차이 큰 경우 사용 빈도에 따라 테이블 분할

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

- 고려 사항 : 기본키 유일성 관리 어려워짐, 데이터양이 적거나 사용 빈도 낮은 경우 테이블 분할 필요한지 고려, 수행 속도 느려질 수 있음, 데이터 검색에 중점 두어 테이블 분할 여부 결정

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

- 경우 : 정규화로 속도 느려진 경우, 많은 범위나 특정 범위만 자주 처리하는 경우, 처리 범위 줄이지 않고 속도 개선할 수 없는 경우

● 중복 속성 추가 : 조인해서 데이터 처리 시 데이터 조회 경로 단축 위해 자주 사용하는 속성을 하나 더 추가하는 것

- 무결성 확보 어렵, 디스크 공간 추가 필요

- 경우 : 조인이 자주 발생하는 속성인 경우, 접근 경로 복잡 속성인 경우, 액세스의 조건으로 자주 사용되는 경우, 기본키의 형태 적절하지 않거나 여러 개의 속성으로 구성된 경우

- 고려 사항 : 테이블 및 속성의 중복 고려, 데이터 일관성 및 무결성에 유의, SQL 그룹 함수 이용하여 처리 가능해야 함, 저장 공간의 지나친 낭비 고려

​

4. 인덱스 설계

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

- 데이터가 저장된 물리적 구조와 밀접한 관계, 하나 이상의 필드로 만들어도 됨, 액세스 빠르게 수행 가능

- 물리적인 구조에 접근 방법 제공, 레코드 삽입 삭제 빈번한 경우 인덱스 개수 최소로 하는 것이 효율적

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

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

                             레코드의 물리적 순서가 인덱스의 엔트리 순서와 일치

- 넌클러스터드 인덱스 : 인덱스의 키값만 정렬되어 있을 뿐 실제 데이터는 정렬되지 않는 방식

● 트리 기반 인덱스 : 인덱스 지정 블록들이 트리 구조 이루고 있는 것, 상용 DBMS에서는 트리 구조 기반 B+ 트리 인덱스 주로 씀

- B 트리 인덱스 : 일반적 사용하는 인덱스 방식, 루트 노드에서 하위 노드로 키값의 크기 비교하며 데이터 검색 모든 리프 노드 레벨 동일

- B+ 트리 인덱스 : 노드로 구성된 인덱스 세트와 단말 노드로만 구성된 순차 세트로 구분, 인덱스 세트에 있는 노드들은 단말 노드에 있는 키값을 찾아갈 수 있는 경로로만 제공, 순차 세트에 있는 단말 노드가 해당 데이터 레코드 주소 가리킴,

인덱스 세트에 있는 모든 키값이 단말 노드에 다시 나타나므로 단말 노드 만을 이용한 순차 처리 가능

● 비트맵 인덱스 : 인덱스 칼럼의 데이터를 Bit 값인 0 or 1로 변환하여 인덱스 키로 사용하는 방법

- 키값을 포함하는 로우(행)의 주소 제공, 데이터가 Bit로 구성되어 있어 효율적인 논리 연산이 가능하고 저장 공간이 작음

- 분포도가 낮은 칼럼에 적합하여 성능 향상 효과 기대, 다중 조건 만족하는 튜플의 개수 계산에 적합, 압축 효율 좋음

● 함수 기반 인덱스 : 칼럼의 값 대신 칼럼의 특정 함수나 수식을 적용하여 산출된 값을 사용

- B+ 트리 인덱스 or 비트맵 인덱스를 생상하여 사용, 부하 발생 가능, 사용자 정의 함수가 시스템 함수보다 부하 더 큼

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

● 비트맵 조인 인덱스 : 다수의 조인된 객체로 구성된 인덱스, 비트맵 인덱스와 물리적 구조 동일

● 도메인 인덱스 : 개발자가 필요한 인덱스 직접 만들어 사용하는 것으로 확장형 인덱스라고 함

● 인덱스 설계 : 인덱스의 대상 테이블, 칼럼 등을 선정 -> 인덱스의 효율성을 검토하여 인덱스 최적화 수행 -> 인덱스 정의서 작성

● 인덱스 대상 테이블 선정 기준 : MULTI BLOCK READ 수에 따라 판단, 랜덤 액세스 빈번 테이블, 특정 범위 특정 순서로 데이터 조회 필요 테이블, 다른 테이블과 순차적 조인 발생되는 테이블

● 인덱스 대상 컬럼 선정 기준

- 인덱스 컬럼의 분포도가 10~15% 이내인 컬럼, 이상이어도 부분 처리 목적으로 하는 컬럼

- 입출력 장표 등에서 조회 및 출력 조건으로 목적으로 하는 컬럼

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

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

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

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

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

● 인덱스 설계 시 고려사항

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

- 인덱스를 지나치게 만들면 오버헤드 발생

- 넓은 범위를 인덱스로 처리 시 많은 오버헤드 발생

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

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

 

5. 뷰 설계

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

- 가상 테이블, 물리적 존재 X, 사용자에게는 있는 것처럼 간주, 임시적인 작업 위한 용도로 활용

- 조인문 최소화로 사용자 편의성 최대화함

● 특징 : 기본 테이블과 같은 형태 구조 사용, 조작도 기본 테이블과 거의 같음

- 물리적 구현 X, 논리적 독립성 제공, 관리 용이 및 명령문 간단, 뷰를 통해서만 데이터에 접근하면 안전한 효율적 기법 사용 가능

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

● 뷰의 장단점

- 장점

: 논리적 데이터 독립성 제공, 동시에 여러 사용자의 상이한 요구 지원, 데이터 관리 용이, 자동 보안 제공

- 단점

: 독립적 인덱스 가질 수 없음, 뷰의 정의 변경 불가, 삽입, 삭제, 갱신 연산 제약 따름

● 뷰의 설계 순서 : 대상 테이블 선정 -> 대상 칼럼 성정 -> 정의서 작성

● 뷰 설계 시 고려 사항 : 반복적으로 조인을 설정하여 사용하거나, 동일한 조건절을 사용하는 테이블을 뷰로 생성

- 다양한 관점에서 제시, 데이터의 보안 유지하며 설계

​

6. 클러스터 설계

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

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

● 클러스터의 특징 : 데이터 조회 속도 향상, 데이터 입력 수정 삭제에 대한 성능 저하

- 데이터 분포도가 넓을수록 유리 => 저장 공간 절약

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

- 파티셔닝 ​된 테이블에는 적용 X

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

- 디스크 입 출력 줄어듦, 클러스터링 된 테이블에 인덱스 생성 시 접근 성능 향상

● 클러스터 대상 테이블

: 분포도 넓은 테이블, 대량 범위 자주 조회 테이블, 입력 수정 삭제 자주 발생 X테이블, 자주 조인되어 사용되는 테이블

ORFER BY, GROUP BY, UNION이 빈번한 테이블

 

7. 파티션 설계

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

- 파티셔닝 된 테이블은 물리적으로 별도의 세그먼트에 저장

- 대용량 DB의 경우 테이블들을 작은 단위로 나눠 분산시키면 성능 저하 방지, 데이터 관리 용이

- 데이터 처리는 테이블 단위, 데이터 저장은 파티션 별로 수행

● 파티션의 장단점

- 장점

: 쿼리 성능 향상, 디스크 성능 향상, 속도 향상, 손상 정도 최소화, 가용성 향상, 입출력 분산

- 단점

: 세심한 관리 요구, 비용 증가, 용량 작은 테이블 파티셔닝 수행 시 성능 저하

● 파티션의 종류 : 범위 분할(열의 값을 기준으로 분할), 해시 분할, 조합 분할

● 파티션 키 선정 시 고려 사항

- 테이블 접근 유형에 따라 파티셔닝 이루어지도록 선정

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

- 매일 생성되는, 백업 기준이 되는 날짜 칼럼, 파티션 간 이동 없는 칼럼, 데이터 분포 양호한 칼럼을 파티션 키로 선정

● 인덱스 파티션

- 파티션 된 테이블의 종속 여부에 따른 구분

Local Partitioned Index : 1:1 대응되도록 파티셔닝, Global Partitioned Index보다 데이터 관리 쉬움

Global Partitioned Index : 독립적으로 구성되도록 파티셔닝

- 인덱스 파티션 키 칼럼의 위치에 따른 구분

Prefixed Partitioned Index : 인덱스 파티션 키와 인덱스 첫 번째 칼럼이 같음

Non-Prefixed Partitioned Index : 인덱스 파티션 키와 인덱스 첫 번째 칼럼이 다름

 

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

● 개념 : 데이터가 저장될 공간 정의하는 것, 설계 시 저장 공간 예측하여 반영, 물리 DB 설계 과정에서 수행

● 목적 : 저장 공간 효과적 사용, 확장성 및 가용성 높임, 병목 현상 최소화, 접근성 향상, 익스텐트 발생 최소화로 성능 향상

● 접근성 향상 방법 : 테이블의 테이블 스페이스와 인덱스의 테이블 스페이스 분리하여 구성

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

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

● 절차 : 기초 자료 수집하여 용량 분석 -> 오브젝트별 용량 산정 -> 테이블과 인덱스 테이블 스페이스 용량 산정 -> 시스템 용량 합해 디스크 용량 산정