[자격증][정처기] 3과목 데이터베이스 구축 - 2

2장 물리 데이터베이스 설계

85 사전 조사 분석

• 논리적 구조로 표현된 논리적 DB를 디스크 등의 물리적 저장장치에 저장할 수 있는 물리적 구조의 데이터로 변환하는 과정
• 물리적 DB 구조의 기본적인 데이터 단위는 저장 레코드이다.
• 반드시 포함되어야 하는 요소
  1. 저장 레코드의 양식 설계
  2. Record Clustering의 분석 및 설계
  3. 접근 경로 설계
• 여러 가지 타입의 저장 레코드 집합이라는 면에서 단순한 파일과 다르다.
• 고려 사항
  1. 인덱스 구조
  2. 레코드 크기
  3. 파일에 존재하는 레코드 갯수
  4. 파일에 대한 트랜잭션(논리적 기능을 수행하기 위한 작업 단위. 한 번에 모두 수행되어야하는 일련의 연산들)의 갱신과 참조 성향
  5. 성능 향상을 위한 개념 스키마의 변경 여부 ㄱ ㅓㅁ토
  6. 빈번한 질의와 트랜잭션들의 수행속도를 높이기 위한 고려
  7. 시스템 운용 시 파일 크기의 변화 가능성
• 물리적 설계 옵션 : 특정 DBMS에서 제공되는 것으로 DB 파일에 대한 저장 구조와 접근 경로에 대한 다양한 옵션
  1. 반응시간 : 트랜잭션 수행을 요구한 시점부터 처리 결과를 얻을 때까지의 경과 시간
  2. 공간 활용도 : DB 파일과 액세스 경로 구조에 의해 사용되는 저장 공간의 양
  3. 트랜잭션 처리량 : 단위 시간 동안 DB 시스템에 의해 처리될 수 있는 평균 수
• 데이터 명명 규칙 파악
  • 예시1. 업무코드는 업쿠모드 3자리, 세부 업무코드 3자리로 구성된다.
  • 데이터 표준화 및 논리 DB 설계의 결과물 등을 통해 파악한다.
  • 논리적 데이터 요소를 물리적 데이터 요소로 전환할 때 동일 명칭 부여의 근거로 사용된다.
• 데이터 사전(데이터 용어 사전) : 전체 프로젝트 관리에서 일관성 있는 데이터 이름과 인터페이스를 제공하기 위해 데이터 속성의 논리명, 물리명, 용어 정의를 기술해 놓은 것. 명칭 부여의 근거로 사용된다.

86 데이터 베이스 저장 공간 설계

• 데이터베이스의 모든 데이터는 테이블에 저장된다.
• 테이블 = 로우 + 컬럼
• 테이블 종류
  1. 일반 테이블 : 저장되는 데이터의 row 위치는 데이터가 저장되는 순서에 따른다.
  2. 클러스터드 인덱스 테이블 : PK나 인덱스 키의 순서에 따라서 데이터가 저장된다.
  3. 파티셔닝 테이블 : 대용량의 테이블을 작은 논리적 단위인 파티션으로 나눈다.
     • 범위 분할(지정 열의 값을 기준)
     • 해시 분할(해시 함수의 결과 값을 기준)
     • 조합 분할(범위 분할+해시분할)
  4. 외부 테이블 : DB에서 일반 테이블처럼 이용할 수 있는 외부 파일. DB 내에 객체로 존재한다.
     • 데이터웨어하우스와 ETL의 작업에 유용하게 사용된다.
     • 데이터 웨어하우스 : 주요 업무 시스템에서 추출되어 의사결정지원 시스템을 지원하는 데이터의 집합
     • ETL : Extraction, Transformation, Loading
  5. 임시 테이블 : 트랜잭션이나 세션별로 데이터를 저장하고 처리하는 테이블.
     • 트랜잭션이 종료되면 삭제된다. 절차적인 처리를 위한 임시 사용 공간
• 컬럼
  • 컬럼 비교 연산에서 컬럼의 데이터 타입,길이가 다르면 DBMS 내부적으로 데이터 타입을 변환한 후 비교 연산을 수행한다.
  • 참조 관계인 컬럼들은 데이터 타입,길이가 일치해야 한다.
  • 길이 : 가변길이(예상되는 최대 길이로 정의), 고정 길이(최소 길이로 지정)
  • 타입에 따른 물리적 순서
    1. 앞쪽 : 고정 길이 컬럼 + not null
    2. 뒤쪽 : 가변 길이 컬럼
    3. 뒤쪽 : Null 값이 많을 것으로 예상되는 컬럼
• 테이블 스페이스 : 테이블이 저장되는 논리적인 영역
  • 하나의 테이블 스페이스에 하나 또는 그 이상의 테이블을 저장할 수 있다.
  • 테이블 저장 = 논리적으로는 테이블스페이스에 저장 + 물리적으로는 해당 테이블스페이스와 연관된 데이터 파일에 저장
  • 데이터베이스 = 테이블 + 테이블스페이스 + 데이터 파일 (물리적 구성에 종속되지 않는 투명성)
  • 대용량 테이블은 하나의 테이블스페이스에 독립적으로 저장
  • Large Object(LOB) 타입의 데이터는 독립적인 공간으로 저장

87 트랜잭션 분석 / CRUD 분석

• 트랜잭션 : DB의 상태를 변환시키는 하나의 논리적 기능을 수행하기 위한 작업의 단위. 한번에 모두 수행되어야 할 일련의 연산들
• ACID
  • Atomicity. 원자성. : 트랜잭션 연산은 commit 되던지 rollback되어야 한다.
  • Consistency. 일관성. : 트랜잭션이 완료되면 언제나 일관성 있는 DB의 상태로 변환된다.(수행 전후의 고정 요소 상태가 같다.)
  • Isolation. 독립성. : 둘 이상의 트랜잭션이 동시에 병렬 실행되는 경우 서로 끼어들지 않고, 서로 참조할 수 없다.
  • Durability. 지속성. : 성공적으로 완려된 트랜잭션으 결과는 시스템이 고장나도 영구적으로 반영된다.
• CRUD : Create, Read, Update, Delete
• CRUD 분석 : 데이터베이스 테이블에 변화를 주는 트랜잭션의 CRUD 연산에 대해서 CRUD 매트릭스를 작성하여 분석하는 것
  • 트랜잭션의 주기별 발생 횟수를 파악하고 연관된 테이블들을 분석하면 테이블에 저장되는 데이터의 양을 유추할 수 있다.
  • 생성 트랜잭셔 규모(Create)를 파악하여 구축해야 할 스토리지의 규모를 예측할 수 있다.
  • 트랜잭션이 몰리는 테이블을 파악할 수 있으므로 디스크 구성 시 유용한 자료로 활용될 수 있다.
  • 외부 프로세스 트랜잭션의 부하가 집중되는 DB 채널을 파악하고 분산시켜 연결 지연이나 타임아웃 오류를 방지할 수 있다.
• CRUD 매트릭스 : 2차원 형태의 표로서 Row는 Process, Column은 table, 격자점에는 프로세스가 테이블에 발생시키는 변화를 표시한다.
  • Ex1. 주문 변경 = 데이터 Read + 수정 Upate. C>R>U>D 순서대로 우선순위가 높은 U만 적는다.
  • CRUD 매트릭스가 완성되었다면 어느 것도 적히지 않은 행이나 열, C나 R이 없는 열을 확인하여 불필요하거나 누락된 테이블,프로세스를 찾는다.
  • 프로세스는 C 또는 R이 없을 수 있다. (주문 변경의 예시)
• 트랜잭션 분석서 : 단위 프로세스와 CRUD 매트릭스를 이용하여 작성한다.
  • 구성요소
    1. 프로세스
    2. CRUD
    3. 테이블명
    4. 컬럼명
    5. 참조횟수 : 프로세스가 테이블을 참조하는 횟수
    6. 트랜잭션 수 : 주기별로 수행되는 트랜잭션 횟수1
    7. 발생 주기

88 인덱스 설계

• 인덱스틑 데이터 레코드에 빠르게 접근하기 위해 <키 값, 포인터> 쌍으로 구성되는 데이터 구조이다.
  • ex) <학번, 주소> —> 학생 table의 record 주소
• 포인터는 테이블의 record에 대한 물리적 주소를 가리킨다.
• 레코드의 삽입과 삭제가 수시로 일어나는 경우에는 인덱스의 개수를 최소로하는 것이 효율적이다.
• 인덱스가 없으면 특정한 값을 찾기 위해 모든 데이터 페이지를 확인하는 TABLE SCAN이 발생한다.
• 기본 인덱스와 보조 인덱스가 있다.
• 기본 인덱스는 모든 키에 대해서 자동적으로 생성된다.
• 레코드의 물리적 순서가 엔트리 순서와 일치하게 유지되도록 구성되는 인덱스를 클러스터드 인덱스라고 한다.
  • 클러스터드 인덱스 테이블 : PK나 인덱스 키의 순서에 따라서 데이터가 저장된다.
  • 실제 데이터가 순서대로 저장되어 있어 인덱스를 검색하지 않아도 원하는 데이터를 빠르게 찾을 수 있다.
  • 데이터삽입,삭제시 순서를 유지하기 위해 재정렬해야 한다.
  • 한 개의 릴레이션에 하나의 인덱스만 생성할 수 있다.
  • 넌클러스터드 인덱스
    1. 인덱스의 키 값만 정렬되어 있을 뿐 실제 데이터는 정렬되지 않는 방식
    2. 데이터를 검색하기 위해서는 먼저 인덱스를 검색하여 실제 데이터의 위치를 확인해야 해서 검색 속도가 떨어진다.
    3. 한 개의 릴레이션에 여러 개의 인덱스를 만들 수 있다.
• 트리기반 인덱스
  • 사용 DBMS에서는 트리 구조 기반의 B+ 트리 인덱스를 주로 활용한다.
  • B 트리 인덱스
    1. 루트 노드에서 하위 노드로 키 앖의 크기를 비교해 나가면서 단말 노드에서 데이터를 찾는다.
    2. 키 값과 레코드를 가리키는 포인터들이 트리 노드에 오름차순으로 저장된다.
    3. 모든 리프노드는 같은 레벨에 있다.
  • B+ 트리 인덱스
    1. 단말 노드가 아닌 노드로 구성된 인덱스 세트 + 단말 노드로만 구성된 순자 세트
    2. 인덱스 세트에 있는 노드들은 단말 노드에 있는 키 값을 찾아갈 수 있는 경로로만 제공.
    3. 순차 세트에 있는 단말 노드가 해당 데이터의 레코드의 주소를 가리킨다.
    4. 인덱스 세트에 있는 모든 키 값이 단말 노드에 다시 나타나므로 단말 노드만을 이용한 순차 처리가 가능하다.
• 비트맵 인덱스
  • 인덱스 컬럼의 데이터를 0 또는 1로 변환하여 인덱스 키로 사용한다.
  • 목적 : 키 값을 포함하는 row의 주소를 제공하는 것
  • 분포도(조건에 맞는 레코드 수 / 전체 릴레이션 레코드 수)가 10~15%인 경우 효율적인 인덱스 검색을 할 수 있다.
  • 데이터가 bit로 구성되어 효율적인 논리 연산이 가능하고 저장 공간이 작다
  • 다중 조건을 만족하는 튜플의 개수 계산에 적합하다
  • 동일한 값이 반복되는 경우가 많아 압축 효율이 좋다.
• 비트맵 조인 인덱스
  • 다수의 조인된 객체로 구성된 인덱스.
  • 단일 객체로 구성된 일반적인 인덱스와 액세스 방법이 다르다.
  • 비트맵 인덱스와 물리적 구조가 동일하다
• 함수기반 인덱스
  • 컬럼의 값 대신 컬럼에 특정 함수나 수식을 적용하여 산출된 값을 사용하는 방식.
  • B+ 트리 인덱스 또는 비트맵 인덱스를 생성하여 사용한다.
  • 데이터를 입력하거나 수정할 때 함수를 적용하므로 부하가 발생할 수 있다.
  • 사용된 함수가 사용자 정의 함수일 경우 시스템 함수보다 부하가 더 크다
  • 대소문자, 띄어쓰기 등에 상관없이 조회할 때 유용하게 사용된다.
  • 적용 가능한 함수 종류
    1. 산술식Arithmetic Expression
    2. 사용자 정의 함수
    3. SQL 함수
    4. Package
    5. C callout
• 인덱스 설계
  • 분명하게 드러난 컬럼에 대해 기본적인 인덱스를 먼저 지정한 후 개발 단계에서 필요한 인덱스의 설계를 추가한다
    1. 인덱스의 대상테이블이나 컬럼 등을 선정한다.
    2. 효율성을 검토하여 인덱스 최적화를 수행한다.
    3. 인덱스 정의서를 작성한다.
• 인덱스 대상 테이블 선정 기준
  • MULTI BLOCK READ(한 번에 메모리에 읽어들일 수 있는 블록의 수)에 따라 판단
    • MBR가 16이면 테이블의 크기가 16블록 이상인 경우 인덱스 필요
  • 랜덤 엑세스가 빈번한 테이블
  • 특정 범위나 특정 순서로 데이터 조회가 필요한 테이블
  • 다른 테이블과 순차적 조인이 발생되는 테이블
• 인덱스 대상 컬럼 선정 기준
  • 인텍스 컬럼의 분포도가 10~15%인 컬럼
  • 10~15% 이상이어도 부분 처리를 목적으로 하는 컬럼
  • 입출력 장표 등에서 조회 및 출력 조건으로 사용되는 컬럼
  • 인덱스가 자동 생성되는 기본키와 Unique키 제약 조건을 사용한 컬럼
  • 가능한 수정이 빈번하지 않은 컬럼
  • ORDER BY, GROUP BY, UNION이 빈번한 컬럼
  • 분포도가 좁은 컬럼은 단독 인덱스로 구성
  • 인덱스들이 자주 조합되어 사용되는 경우 하나의 결합 인덱스로 생성
• 고려사항
  1. 새로 추가되는 인덱스는 기존 엑세스 경로에 영향을 미칠 수 있다.
  2. 넓은 범위를 인덱스로 처리하면 많은 오버헤드가 발생한다.
  3. 인덱스는 추가적인 저장 공간이 필요하다
  4. 인덱스와 테이블 데이터의 저장공간이 분리되도록 설계한다.

89 뷰 설계

• 뷰 : 사용자에게 접근이 허용된 자료만을 제한적으로 보여주기 위해 하나 이상의 기본 테이블로부터 유도된, 이름을 가지는 가장 테이블이다.
• 저장장치 내에 물리적으로 존재하지 않지만, 사용자에게는 있는 것처럼 간주된다.
• 뷰는 데이터 보정 작업, 처리 과정 시험 등 임시적인 작업을 위한 용로도 활용된다.
• 조인문의 사용 최소화로 사용상의 편의성을 최대화한다.
• 뷰를 생성하면 뷰 정의가 시스템 내에 저장되었다가 생성된 뷰 이름을 질의어(SQL)에서 사용할 경우 질의어가 실행될 때 뷰에 정의된 기본 테이블로 대체되어 기본 테이블에 대해 실행된다.
• 기본 테이블로부터 유도된 테이블이기 때문에 기본 테이블과 같은 형태의 구조를 사용하며 조작도 거의 같다.
• 가상 테이블이라서 물리적으로 구현되지 않는다.
• 데이터의 논리적 독립성을 제공할 수 있다.
• 독자적인 인덱스를 가지지 않는다.
• 숨겨진 데이터를 위한 자동 보안이 제공된다.
• DBA는 보안 측면에서 뷰를 활용할 수 있다.
• 기본 테이블의 PK를 포함한 속성 집합으로 뷰를 구성해야만 삽입, 삭제, 갱신 연산이 가능하다
• 기본테이블 검색 연산과 비굑하여 제약이 따르지 않는다. 검색 연산은 제약이 없다.
• 뷰는 다른 뷰의 정의에 기초가 될 수 있다.
• 뷰가 정의된 기본 테이블이나 뷰를 삭제하면 그 테이블이나 뷰를 기초로 정의된 다른 뷰도 자동으로 삭제된다.
• 설계 순서
  1. 대상 테이블을 선정한다
  2. 대상 컬럼을 선정한다.
  3. 정의서를 작성한다.
• 고려사항
  1. 테이블 구조가 단순화 될 수 있도록 반복적으로 조인을 설정하여 사용하거나 동일한 조건절을 사용하는 테이블을 뷰로 생성한다.
     • Ex. A 테이블과 B 테이블을 조인해서 사용하는 경우가 많으면 A,B에서 필요한 필드로 구성된 뷰를 생성한다.
  2. 동일한 테이블이라도 업무에 따라 테이블을 이용하는 부분이 달라질 수 있으므로 사용할 데이터를 다양한 관점에서 제시해야 한다.
     • Ex. A 테이블의 속성 중 B 업무에 필요한 속성들만 뷰로 정의해서 사용한다

90 클러스터 설계

• 클러스터는 데이터 저장시 데이터 엑세스 효율을 향상시키기 위해 동일한 성격의 데이터를 동일한 데이터 블록에 저장하는 물리적 저장 방법이다.
• 클러스터링키로 지정된 컬럼 값의 순서대로 저장되고, 여러 개의 테이블이 하나의 클러스터에 저장된다.
• 클러스터링 된 테이블은 데이터 조회 속도는 향상시키지미나, 데이터 입력,수정,삭제에 대한 성능은 저하시킨다.
• 데이터 분포도가 넓을 수록 유리하다
  • 인덱스틑 분포도가 좁을수록, 클러스터링은 분포도가 넓을 수록 유리하다.
• 데이터 분포도가 넓은 테이블을 클러스터링하면 저장 공간을 절약할 수 있다.
  • 클러스터링된 테이블은 클러스터링키 열을 공유하므로 저장 공간이 줄어든다.
• 대용량을 처리하는 트랜잭션은 전체 테이블을 스캔하는 일이 자주 발생하므로 클러스터링을 하지 않는 것이 좋다.
• 단일 테이블 클러스터링 : 처리 범위가 넓은 경우
  • 단일 테이블 내부에서 클러스터링
• 다중 테이블 클러스터링 : 조인이 많이 발생하는 경우
  • 클러스터링이 동일한 성격의 데이터를 동일한 데이터 블록에 저장하는 방식임을 기억
• 클러스터 대상 테이블
  1. 분포도가 넓은 테이블
  2. 대량의 범위를 자주 조회하는 테이블
  3. 입력,수정,삭제가 자주 발생하지 않는 테이블
  4. 자주 조인되어 사용되는 테이블
  5. ORDER BY, GROUP BY, UNION이 빈번한 테이블

91 파티션 설계

• 대용량의 테이블이나 인덱스를 작은 논리적 단위인 파티션으로 나누는 것
• 대용량 DB는 중요한 몇 개의 테이블에만 집중되기 때문에 테이블을 작은 단위로 나눠 분산시켜 성능 저하를 방지하고 관리가 용이해짐
• 파티션키 또는 인덱스키에 따라 물리적으로 별도의 공간에 데이터가 저장된다.
• 데이터 처리는 테이블 단위로 나눠지고, 데이터 저장은 파티션별로 수행된다.
• 파티션 종류 : 범위(열 기준)/해시(해시값 기준)/조합(범위+해시)파티션
• 데이터 관리의 용이성을 위해 이력성 데이터(삭제되었지만 보존되는 기간 내의 데이터)는 파티션 생성주기와 소멸주기를 일치시켜야 한다.
• 매일 생성되는 날짜 컬럼, 백업의 기준이 되는 날짜 컬럼, 파티션 간 이동이 없는 컬럼, IO 병목을 줄일 수 있는 데이터 분포가 양호한 컬럼 등을 파티션키로 선정
• 인덱스 파티션
  • 파티션된 테이블의 데이터를 관리하기 위해 인텍스를 나눈 것
  • Local Partitioned Index : 테이블 파티션과 인덱스 파티션이 1 대 1 대응
    • Ex: 파티션과 인덱스 모두 판매일자 필드를 기준으로 수행한다.
  • Global Partitioned Index : 테이블 파티션과 인덱스 파티션이 독립적으로 구성
    • Ex: 파티션은 판매일자 필드를 기준으로 수행하고, 인덱스는 지점 필드를 기준으로 수행한다.
  • Local이 Global에 비해 데이터 관리가 쉽다.

92 데이터베이스 용량 설계

• 데이터 접근성을 향상시키는 설계 방법
  1. 테이블의 테이블스페이스와 인덱스의 인덱스스페이스를 분리하여 구성
  2. 테이블스페이스와 임시 테이블스페이스를 분리하여 구성
  3. 테이블을 마스터 테이블과 트랜잭션 테이블로 분류
• DB에 생성되는 오브젝트의 익스텐트(기본 용량이 모두 찼을 때 추가적으로 할당되는 공간) 발생을 최소화하여 성능 향상시킨다.
• 테이블과 인덱스의 테이블스페이스 용량을 산정한다. 테이블스페이스 용량은 테이블스페이스에 생성되는 테이블 용량을 모두 더한 값이 40%를 추가해서 산정한다.

93 분산 데이터베이스 설계

• 논리적으로는 하나의 시스템, 물리적으로는 네트워크를 통해 여러 개의 사이트에 분산되어 있는 DB
• 구성요소
  1. 분산 처리기 : 자체적으로 처리 능력을 가진다. 지리적으로 분산되어 있는 컴퓨터 시스템을 말한다.
  2. 분산 데이터베이스 : 지리적으로 분산되어 있는 DB. 지역의 특성에 맞게 DB가 구성됨
  3. 통신 네트워크 : 분산처리기들을 통신망으로 연결하여 논리적으로 하나의 시스템처럼 작동할 수 있도록 하는 통신 네트워크
• 투명성
  • 위치 투명성 : 액세스하려는 DB의 실제 위치를 알필요 없이 논리적인 명칭만으로 액세스
  • 중복 투명성 : 동일한 데이터가 여러 곳에 저장되어 있어도 하나라고 느낌
  • 병행 투명성 : 다수의 트랜잭션이 동시에 실현되어도 다른 트랜잭션의 영향을 받지 않음
  • 장애 투명성 : 여러 장애에도 불구하고 트랜잭션을 정확하게 처리한다.
• 전역 관계망을 논리적 측면에서 소규모 단위(Fragment)로 분할하고, 분할된 결과를 복수의 노드에 할당하는 과정으로 진행된다.
• 분할Fragment
  • 규칙
    1. 완전성 : 전체 데이터를 대상으로 분할해야 한다.
    2. 재구성 : 분할된 데이터는 관계 연산을 활용하여 본래의 데이터로 재구성할 수 있어야 한다.
    3. 상호 중첩 배제 : 분할된 데이터를 서로 다른 분할의 항목에 속하지 않아야 한다.
  • 방법 : 수평 분할(Row 기준), 수직 분할(Col 기준)
• 할당Allocation
  • 동일한 분할을 여러 개의 서버에 생성하는 분산 방법
  • 비중복 할당 : 최적의 노드를 선택해서 분산 DB의 단일 노드에서만 분할이 존재
    • 배타적 분할로 분리하기 힘든 요구가 자주 포함되므로 분할된 테이블 간의 의조넝을 무시되고 비용 증가 가능
  • 중복 할당 : 동일한 테이블을 다른 서버에 복제하는 방법으로, 일부 복제하는 부분 복제와 전체를 복제하는 완전 복제가 있다.

94 데이터베이스 이중화 / 서버 클러스터링

• DB 이중화 : 서버 오류로 인한 데이터베이스 서비스 중단이나 물리적 손상 발생 시 이를 복구하기 위해 동일한 DB를 복제하여 관리하는 것
  • 앱을 여러 개의 DB로 분산시켜 처리하므로 DB의 부하를 줄일 수 있다.
  • 쉽게 백업 서버를 운영할 수 있다.
  • 기법
    • Eager : 트랜잭셔 수행 중 데이터 변경이 발생하면 이중화된 모든 DB에 즉시 전달하여 변경 내용이 즉시 적용되도록 하는 기법
    • Lazy : 트랜잭션의 수행이 종료되면 변경 사실을 새로운 트랜잭션에 작성하여 각 DB에 전달되는 기법. DB마다 새로운 트랜잭션이 수행되는 것으로 간주된다.
  • 구성 방법
    • 활동-대기Active-Standy 기법 : 둘 중 하나만 활성 상태로 서비스. 고장나면 하나를 활동 상태로 전환
    • 활동-활동Active-Active 기법 : 두 개의 DB가 서로 다른 서비스를 제공하다가 둘 중 한 쪽 DB에 문제가 발생하면 나머지 다른 DB가 서비스를 제공
• 클러스터링 : 두 대 이상의 서버를 하나의 서버처럼 운영하는 기술
  • 서버 이중화 및 공유 스토리지를 사용하여 서버의 고가용성을 제공한다.
  • 고가용성 클러스터링 : 하나의 서버에 장애가 발생하면 다른 노드 서버가 받아 처리하여 서비스 중단을 막음
  • 병렬 처리 클러스터링 : 전체 처리율을 높이기 위해 하나의 작업을 여러 개의 서버에서 분산하여 처리하는 방식
    • Lode Balancer 사용

95 데이터베이스 보안/ 암호화

• 개인키 암호 방식 = 비밀키 암호 방식
  • 동일한 키로 암호화하고 복호화
  • = 대칭 암호 방식 = 단일키 암호 방식
  • 전위/대체/대수/합성 기법(DES)
• 공개키 암호 방식
  • 서로 다른 키로 암호화하고 복호화
  • 암호화 키 : 공개키. DB 사용자에게 공개
  • 복호화 키 : 비밀키. 관리자가 관리
  • = 비대칭 암호방식
  • RSA

96 데이터베이스 보안 - 접근통제

• 데이터가 저장된 객체와 이를 사용하는 주체 사이의 정보 흐름을 제한
• 임의 접근통제 : 접근하는 사용자의 신원에 따라 접근 권한을 부여
  • 통제 권한이 주체에 있어 주체가 접근통제 권한을 지정/제어 가능
  • SQL의 GRANT와 REVOKE
• 강제 접근통제 : 주체와 객체의 등급을 비교하여 접근 권한을 부여
  • 제3자가 접근통제 권한을 지정
• 접근통제의 3요소 : 정책. 매커니즘. 보안 모델
• 접근통제 정책
  • 신분 기반 정책 : 주체나 그룹의 신분에 근거하여 객체의 접근을 제한
    • IBP. Individual-Based Policy : 최소 권한 정책. 단일 주체에게 하나의 객체에 대한 허가 부여
    • GBP. Group-Based Policy : 복수 주체에 하나의 객체에 대한 허가를 부여
  • 규칙 기반 정책 : 주체가 갖는 권한에 근거하여 객체의 접근을 제한
    • MLP. Multi-Level Policy : 사용자 및 객체별로 지정된 기밀 분류에 따른 정책
    • CBP. Compartment-Based Policy : 집단별로 지정된 기밀 허가에 따른 정책
  • 역할 기반 정책 : GBP의 변형. 역할게 근거하여 객체의 접근을 제한
    • 인사담당자. DBA
• 접근통제 매커니즘 : 정의된 접근통제 정책을 구현하는 기술적인 방법
  1. 접근통제 목록 : 어떤 행위를 할 수 있는지 객체를 기준으로 목록화
  2. 능력 리스트 : 주체가 허가된 자원 및 권한을 기록
  3. 보안 등급 : 주체나 객체 등에 부여된 보안 속성의 집합.
  4. 패스워드 : 주체가 자신임을 증명하는 인증방법
  5. 암호화
• 접근통제 보안 모델
  1. 기밀성Confidentiality 모델 : 정보와 자원은 인가된 사용자에게만 접근이 허용. 노출되어도 데이터를 읽을 수 없음
     • 군대 시스템 등 특수 환경에서 주로 사용
     • 단순 보안 규칙 : 주체는 자신보다 높은 등급의 객체를 읽을 수 없다.
     • 스타-보안 규칙 : 주체는 자신보다 낮은 등급의 객체에 정보를 쓸 수 없다.
     • 강한 스타-보안 규칙 : 주체는 자신과 등급이 다른 객체를 읽거나 쓸 수 없다.
  2. 무결성 모델 : 정보는 인가된 사용자만 수정할 수 있다. 정보의 내용이 전송 중에 수정되지 않고 전달되는 것을 보장한다.
     • 데이터의 일관성 유지에 중점을 두어 개발
     • 단순 무결성 규칙 : 주체는 자신보다 낮은 등급의 객체를 읽을 수 없다.
     • 스타 무결성 규칙 : 주체는 자신보다 높은 등급의 객체에 정보를 쓸 수 없다.
  3. 접근통제 모델
     • 접근통제 매커니즘을 보안 모델로 발전시킨 것
     • 접근통제 행렬Access Control Matrix
     • 행은 주제. 열은 객체. 격자는 권한(ALL, R, W, R/W).을 표로 만들어서 관리
• 접근통제 조건
  • 값 종속 통제: 객체에 저장도니 값에 따라, 납입한 금액에 따라 보안 등급이 설정되는 등
  • 다중 사용자 통제 : 지정된 객체에 다수의 사용자가 동시에 접근하는 경우 다수결에 따라 접근 통제하는 등
  • 컨텍스트 기반 통제 : 특정 시간, 네트워크 주소 등에 근거해서 접근 제어. 근무시간에만 접근하도록 통제하는 등
• 감사 추적
  • 사용자나 앱이 DB에 접근하여 수행한 모든 활동을 기록하는 기능

97 데이터베이스 백업 : C

• 장애유형
  1. 사용자 실수
  2. 미디어 장애 : CPU, 메모리, 디스크 등 하드웨어 장비나 데이터가 파손된 경우
  3. 구문 장애 : 프로그램 오류, 사용 공간 부족
  4. 사용자 프로세스 장애 : 프로그램 비정상 종료. 네트워크 비연결 세션 종료
  5. 인스턴스 장애 : 여러 이유로 메모리나 DB 서버의 프로세스 중단
• 로그 파일
  • DB 복구를 위해 가장 기본적ㅇ니 자료
  • DB의 상태 변화에 대한 내용을 작업 순서가 아닌 시간의 흐름에 따라서 기록.
  • UNDO, REDO를 위해 사용됨
  • 트랜잭션 시작, Rollback, 데이터 입력, 수정, 삭제 시점에 기록됨
  • 로그 파일 내용
    1. 트랜잭션 잡업 내용
    2. 트랜잭션 식별
    3. 틀내잭션 레코드
    4. 데이터 식별자
    5. 갱신 이전 값
    6. 갱신 이후 값
• 데이터베이스 복구 알고리즘(데이터베이스 백업을 위함. 아래의 저장매체는 백업 저장매체)
  • 동기적 갱신 : 트랜잭션이 완료되기 전에 DB 버퍼 내용을 동시에 저장매체에 기록
  • 비동기적 갠신 : 트랜잭션이 완료된 내용을 일정 주기나 작업량에 따라 시간 차이를 두고 저장매채에 기록
    1. NO-UNDO/REDO : 데이터베이스 버퍼의 내용을 비동기적으로 갱신한 경우의 복구 알고리즘
    • NO-UNDO : 트랜잭션 완료 전에는 변경 내용이 DB에 기록되지 않아서 최소할 필요 없음
    • REDO : 트랜잭션 완료 후 DB 버퍼에는 기록되고 저장매체이는 기록되지 않아서 트랜잭션 내용을 다시 실행 1. UNDO/NO-REDO : 데이터베이스 버퍼의 내용을 동기적으로 갱신한 경우의 복구 알고리즘
    • UNDO : 트랜잭션 완료 전에 시스템이 파손되었다면 변경 내용을 취소
    • NO-REDO : 트랜잭션 완료 전에 데이터베이스 버퍼 내용을 이미 저장 매체에 기록했으므로 트랜잭션 내용을 다시 실행하지 않음 1. UNDO/REDO : 데이터베이스 버퍼의 내용을 동기/비동기적으로 갱신한 경우의 복구 알고리즘
    • UNDO/REDO: DB 기록 전에 트랜잭션이 완료될 수 있으므로 완료된 트랜잭션이 DB에 기록되지 못했다면 다시 실행
      1. NO-UNDO/NO-REDO : 데이터베이스 버퍼의 내용을 동기적으로 저장 매체에 기록하지만 DB와는 다른 영역에 기록한 경우의 복구 알고리즘
    • NO-UNDO : 변경 내용은 데이터베이스와 다른 영역에 기록되어 있으므로 최소할 필요가 없다.
    • NO-REDO : 다른 영역에 이미 기록되어 있으므로 트랜잭션을 다시 실행할 필요가 없다.
• 백업 종류
  • 물리 백업 : DB 파일을 백업. 속도가 빠름. 작업 단순. 문제 발생시 원인 파악 및 해결 어렵.
  • 논리 백업 : DB 내의 논리적 객체들을 백업. 복원시 데이터 손상을 막고 문제 발생 시 원인 파악 및 해결이 수월. 시간 오래 걸림.

98 스토리지

• DAS. Direct Attached Storage
  • 서버와 저장장치를 전용 케이블로 직업 연결.
• NAS. Network Attached Storage
  • 서버와 저장장치가 네트워크를 통해 연결.
  • 별도의 파일 관리 기능이 있는 NAS Storage가 내장된 저장장치를 직접 관리
  • 이터넷 스위치를 통해 다른 서버에서도 스토리지에 접근 가능.
  • 확장성. 유연성 우수
  • 접속 증가 시 성능이 저하
• SAN. Storage Area Network
  • DAS의 속도 + NAS의 파일 공유 특성
  • 서버와 저장장치를 연결하는 전용 네트워크를 별도로 구성
  • 파이버 채널 스위치를 이용하여 네트워크 구성
  • 파이버 채널 스위치는 서버나 저장장치를 광케이블로 연결해서 처리속도가 빠름.
  • 초기 비용 높음

99 논리 데이터의 모델의 물리 데이터 모델 변환

• 엔티티를 테이블로 변환
  • 엔티티 -> 테이블
  • 속성 -> 컬럼
  • 주 식별자 -> PK
  • 외부 식별자 -> FK
  • 관계 -> 관계
• 슈퍼타입/서브타입을 테이블로 변환
  • 슈퍼타입 기준 테이블 변환
    • 장점 : 데이터 엑세스가 용이. SQL 문장이 단순해짐
    • 단점 : 인덱스 크기의 증가로 인덱스 효율 감소. 디스크 저장 공간 증가.
    • 서브타입에 속성이나 관곅 적을 경우 적용
    • 하나로 통합된 테이블에 서브 타입의 모든 속성이 포함
  • 서브타입 기준 테이블 변환
    • 장점 : 여러 개의 테이블로 통합하므로 테이블당 크기가 감소하여 전체 테이블 스캔시 유리하다.
    • 단점 : 수행속도 감소. UID의 유지 관리가 어려움.
    • 서브타입에 속성이나 관계가 많이 포함된 경우 적용
    • 서브 타입에 슈퍼타입의 속성을 각각 추가
    • 서브타입을 기준으로 여러 개의 테이블로 변환
  • 개별타입 기준 테이블 변환
    • 장점 : 저장공간 작다.
    • 단점 : 조인이 항상 발생.
    • 슈퍼타입과 서브타입 테이블들을 각각의 개별 테이블로 변환
    • 슈퍼와 서브 사이에 각각 1대1 관계 형성
    • 전체 데이터에 대한 처리가 빈번한 경우
    • 서브타입의 처리가 대부분 독립적으로 발생하는 경우
    • 통합하는 테이블의 컬럼 수가 많은 경우
    • 서브타입의 컬럼 수가 많은 경우
    • 슈퍼타입의 처리 범위가 넓고 빈번하게 발생하여 단일 테이블 클러스터링이 필요한 경우

100 물리 데이터 모델 품질 검토

• 정확성 : 데이터 모델이 요구사항에 따라 정확하게 표현됨
• 완전성 : 데이터 모델과 요구사항이 누락 없이 반영됨
• 준거성 : 데이터 모델이 표준, 규칙, 요건 등을 정확하게 준수함
• 최신성 : 데이터 모델이 최근 이슈나 현행 시스템을 반영함
• 일관성 : 데이터 모델이 표현상의 일관성을 유지
• 활용성 : 사용자가 충분히 이해가능. 업무 변화에 따른 데이터 구조 변경이 최소화 가능.