데이터베이스 구축 - 물리 데이터베이스 설계

물리 데이터베이스 설계 : 논리적 DB를 물리적 구조의 데이터로 변환

● 기본적인 데이터 단위 : 저장 레코드  ● DB 시스템의 성능에 영향을 줌

< 고려사항 >

● 인덱스 구조  ● 레코드 크기/개수 ●파일 크기의 변화가능

● 트랜잭션의 참조 성향 ● 개념 스키마의 변경 여부 검토

 

데이터 명명 규칙 : 물리 데이터 모델에 적용해야 하는 규칙

● 서로 일관성을 유지해야 한다.( 물리 DB와 논리 DB )

● 중복 구축 방지

 

시스템 자원 : DB 설치에 영향을 미칠 수 있는 물리적인 요소

< 하드웨어 자원 >

● 중앙처리장치 : CPU의 성능과 집중적인 부하 발생시간

● 메모리 : 확보된 자원이나 실질적인 시스템 활용 정도

● 디스크 : 사용 가능한 디스크 공간

● I/O Controller : 입/출력 컨트롤러의 성능/운용의 적절성

● 네트워크 : 처리량, 처리속도, 부하 발생 시간, 동시 접속 가능 정도

< OS 및 DBMS 버전 >

● DB 운영에 영향을 미칠 수 있으므로 관련 요소 등을 파악하고 적절하게 관리

< DBMS 파라미터 정보 >

● 시스템별 DBMS 파라미터의 종류/관리 대상 파악

 

DB 관리 요소

● DB 관리 요소를 파악 후 시스템 조사 분석서 작성

● 시스템 조사 분석서를 기반으로 DB 구조, 이중화 구성, 분산 DB, 접근제어/통제, DB암호화 특성 파악

 

테이블 : 로우( 행 ), 컬럼( 열 )로 구성

-> 컬럼 : 데이터 타입과 길이로 정의, 데이터 타입과 길이가 다른 두 컬럼은 데이터 타입을 변환 후 비교 연산 수행, 참조 관계 컬럼들은 데이터 타입과 길이가 일치해야 함

● DB의 모든 데이터는 테이블에 저장

● 논리 설계 단계의 개체에 대응하는 객체

< 종류 >

1. 일반 테이블

● 로우 위치는 속성 값에 상관없이 데이터가 저장되는 순서에 따라 결정

2. 클러스터드 인덱스 테이블

● 기본키나 인덱스키의 순서에 따라 데이터 저장

3. 파티셔닝 테이블

● 테이블을 작은 논리적 단위인 파티션으로 나눔

-> 범위 분할 : 열 값 기준으로 분할

-> 해시 분할 : 해시 함수를 적용한 결과 값으로 분할

-> 조합 분할 : 범위 분할로 분할 후 해시 함수를 적용하여 분할

4. 외부 테이블

● 일반 테이블처럼 이용할 수 있는 외부 파일

● 데이터웨어하우스에서 ETL 작업에 사용

5. 임시 테이블

● 트랜잭션이나 세션 별 데이터를 저장하고 처리

● 임시 테이블에 저장된 데이터는 트랜잭션 종료 시 삭제

< 테이블 스페이스 >

● 테이블이 저장되는 논리적인 영역

● 테이블 저장시 논리적으로 테이블 스페이스에 저장, 물리적으로 데이터 파일에 저장

● 투명성 보장

 

트랜잭션 : DB 상태 변환하기 위한 작업 단위

● 병행 제어 및 회복 작업 시 처리되는 논리적 단위

● 서비스 요구 시 시스템이 응답하기 위한 상태 변환 과정의 작업 단위

< 특성 >

● Atomicity( 원자성 ) : DB에 모두 반영되도록 완료 or 전혀 반영되지 않도록 복구

● Consistency( 일관성 ) : 성공 시 일관성 있는 DB 상태로 변환

● Isolation( 독립성 ) : 어느 하나의 트랜잭션 실행 중 다른 트랜잭션의 연산이 끼어들 수 없다.

● Durability( 지속성 ) : 성공적으로 완료된 트랜잭션의 결과는 시스템이 고장나도 영구적으로 반영

 

CRUD 분석 : 생성, 읽기, 갱신, 삭제

● 트랜잭션의 주기별 발생 획수 파악 후 테이블에 저장되는 데이터 양 유추

● 트랜잭션이 몰리는 테이블 파악

 

CRUD 매트릭스 : 행에는 프로세스, 열에는 테이블, 행과 열이 만나는 위치에는 변화 표시

● C > D > U > R의 우선순위 적용

 

트랜잭션 분석

● 목적 : 트랜잭션 양을 분석하여 테이블에 저장되는 데이터 양 유추

● DB 용량을 산정하고 DB 구조 최적화

● 업무 개발 담당자가 수행

 

인덱스 : 키 값, 포인터 쌍으로 구성되는 데이터 구조

● 물리적 구조 접근 방법 제공

● 레코드에 대한 액세스를 빠르게 수행

● 인덱스의 개수 최소 효율적

< 종류 >

1. 트리 기반 인덱스 : 인덱스를 저장하는 블록들이 트리 구조

● B 트리 인덱스 : 루트 노드에서 하위 노드로 키 값의 크기를 비교하며 데이터 검색

● B+ 트리 인덱스 : 인덱스 세트와 순차 세트로 구분

-> 인덱스 세트 : 키 값을 찾아갈 수 있는 경로로만 제공

-> 순차 세트 : 해당 데이터 레코드의 주소를 가리킴

2. 비트맵 인덱스 : 데이터를 Bit 값이 0, 1로 변환하여 인덱스 키로 사용

● 목적 : 키 값을 포함하는 로우의 주소 제공  ● 저장 공간 작음

● 동일한 값이 반복되는 경우가 많아 압축 효율 좋음

3. 함수 기반 인덱스 : 컬럼에 특정 함수나 수식 적용

● B+ 트리 인덱스 또는 비트맵 인덱스를 생성하여 사용

● 데이터를 입력하거나 수정 시 함수를 적용함으로 부하 발생

● 시스템 함수보다 부하 큼

< 인덱스 대상 테이블 선정 기준 >

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

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

< 인덱스 설계 시 고려사항 >

● 인덱스를 많이 만들면 오버헤드 발생

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

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

 

뷰 : 접근이 허용된 자료만을 제한적으로 보여주기 위한 가상 테이블

● 임시적인 작업을 위한 용도  ● 조인문의 사용 최소화 -> 편의성 최대화

● 물리적으로 구현 X  ● 논리적 독립성 제공  ● 관리 용이

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

● 독립적인 인덱스를 가질 수 없음  ● 뷰의 정의 변경 X

● 삽입/삭제/갱신 연산에 제약이 따름

 

클러스터 : 동일한 성격의 데이터를 동일한 데이터 블록에 저장하는 물리적 저장 방법

● 조회 속도 향상 / 데이터 입력, 수정, 삭제 성능 저하

● 테이터의 분포도가 넓을수록 유리

● 클러스터링 된 테이블은 클러스터링키 열을 공유하므로 저장 공간 줄어듬

● 파티셔닝 된 테이블에는 클러스터링 불가능

< 대상 테이블 >

● 분포도가 넓은 테이블

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

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

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

 

파티션 : 테이블이나 인덱스를 논리적 단위인 파티션으로 나누는 것

● 성능 저하 방지 ● 데이터 관리 쉬움

● 세심한 관리 요구 ● 테이블간 조인에 대한 비용 증가

< 인덱스 파티션 >

-> Local Partitioned Index : 테이블 파티션과 인덱스 파티션이 1:1 대응

-> Global Partitioned Index : 테이블 파티션과 인덱스 파티션이 독립적

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

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

 

DB 용량 설계

● 물리 데이터베이스 설계 과정에서 수행

● 저장 곤간 효과적 사용

● 병목 현상 최소화

● 접근성 향상

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

 

분산 데이터베이스 : 여러 개의 컴퓨터 사이트에 분산되어 있는 데이터베이스

● 잠재적 오류 증가

< 설계 시 고려사항 >

● 작업부하의 노드별 분산 정책 ● 지역의 자치성 보장

● 데이터의 일관성 ● 회복 기능 ● 통신 네트워크를 통한 원격 접근 기능

< 목표 >

● 위치 투명성 : DB의 논리적인 명칭만으로 액세스 가능

● 중복( 복제 ) 투명성 : 동일 데이터가 여러 곳에 중복되어 있어도 하나의 데이터만 존재하는 것처럼 사용, 시스템은 자동으로 여러 자료에 대한 작업 수행

● 병행 투명성 : 다수의 트랜잭션들이 동시에 실행되도 트랜잭션의 결과는 영향 X

● 장애 투명성 : 컴퓨터 장애에도 불구하고 트랜잭션을 정확하게 처리

 

데이터베이스 이중화 : 시스템 오류 발생 시 복구하기 위해 동일한 DB를 복제하여 관리

● 사용자가 수행하는 작업이 데이터베이스 이중화 시스템에 연결된 다른 DB에도 동일하게 적용

● DB 부하 줄임  ● 백업 서버 운영

< 분류 >

● Eager 기법 : 데이터 변경 발생 시 즉시 전달하여 즉시 적용

● Lazy 기법 : 변경 사실을 새로운 트랜잭션에 작성하여 DB에 전달, DB마다 새로운 트랜잭션 수행

● 활동-대기 방법 : 한 DB가 활성 상태로 서비스 시 다른 DB는 대기, 활성 DB가 장애 발생 시 대기 상태의 DB가 자동으로 모든 서비스 대신 수행

● 활동-활동 방법 : 두 개의 DB가 서로 다른 서비스 제공하다가 둘 중 한쪽 DB에 문제 발생 시 다른 DB가 서비스 제공

 

클러스터링 : 두 대 이상의 서버를 하나의 서버처럼 운영

● 서버 이중화 및 공유 스토리지 사용 -> 서버의 고가용성 제공

-> 고가용성 클러스터링 : 한 서버에 장애 발생 시 다른 서버가 받아 처리하여 서비스 중단 방지

-> 병렬 처리 클러스터링 : 하나의 작업을 여러 개의 서버에서 분산 처리

 

데이터베이스 보안 : 권한이 없는 사용자가 액세스하는 것을 금지

 

암호화 : 지정한 수신자 이외에는 내용을 알 수 없도록 평문을 암호문으로 변환

● 비밀키 암호화 기법 : 동일한 키로 데이터를 암호화/복호화 함

● 공개키 암호화 기법 : 서로 다른 키로 데이터를 암호화/복호화 함

-> 공개키 : 암호화 시 사용, DB 사용자에게 공개

-> 비밀키 : 복화화 시 사용, 관리자가 비밀리에 관리

 

접근 통제 : 데이터가 저장된 객체와 이를 사용하려는 주체 사이의 정보 흐름 제한

● 비인가된 사용자의 접근 감시

● 접근 요구자의 사용자 식별

● 접근 요구 정당성 확인 및 기록

< 기술 >

● DAC( 임의 접근통제 )

-> 사용자의 신원에 따라 접근 권한 부여

-> 주체가 접근통제 권한을 지정하고 제어 가능

-> SQL 명령 : GRANT와 REVOKE

● MAC( 강제 접근통제 )

-> 주체와 객체의 등급을 비교하여 접근 권한 부여

-> 제3자가 접근통제 권한 지정

< 접근통제 3요소 >

● 접근통제 정책

-> 신분 기반 정책

-> 규칙 기반 정책 : 주체가 갖는 권한에 근거하여 객체의 접근 제한

-> 역할 기반 정책 : 주체가 맡은 역할에 근거하여 객체의 접근 제한

● 접근통제 매커니즘 : 정책 구현 기술적 방법

-> 접근통제 목록 : 어떤 주체가 어떤 행위를 할 수 있는지 기록한 목록

-> 능력 리스트 : 주체에게 허가된 자원 및 권한을 기록한 목록

-> 패스워드 : 주체가 자신임을 증명

● 접근통제 보안 모델 : 보안 정책 구현을 위한 정형화된 모델

-> 기밀성 모델 : 특수 환경, 정보가 전송 중 노출 시 데이터를 읽을 수 없는 것

-> 무결성 모델 : 일관성 유지, 시스템 내 정보는 인가된 사용자만 수정 가능

-> 접근통제 모델

 

스토리지 : 대용량의 데이터를 저장하기 위해 서버와 저장장치를 연결

< 종류 >

- DAS : 서버와 저장장치를 전용 케이블로 직접 연결

● 서버에서 저장장치 관리  ● 속도가 빠르고 설치/운영 쉬움

● 유지보수 비용 저렴  ● 파일 공유 X

● 확장성 및 유연성 저하

- NAS : 서버와 저장장치를 네트워크를 통해 연결

● NAS Storage가 내장된 저장장치 직접 관리

● 파일 공유 가능, 쉽게 접근  ● 확장성 및 유연성 우수

- SAN : 서버와 저장장치를 연결하는 전용 네트워크를 별도로 구성

● 파이버 채널 스위치 이용 : 처리 속도 빠름  ● 서버들이 저장장치 및 파일 공유 가능

● 확장성, 유연성, 가용성 높음

 

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

< 엔티티를 테이블로 변환 >

● 엔티티 -> 테이블 ● 속성 -> 컬럼 ● 주 식별자 -> 기본키 ● 외부 식별자 -> 외래키

< 슈퍼타입 기준 테이블 변환 >

● 하나의 테이블로 만듬

● 여러 테이블 조인 X -> 수행 속도 빨라짐

● 디스크 저장 공간 증가 ● 인덱스 효율 떨어짐

< 서브타입 기준 테이블 변환 >

● 서브타입들을 개별적인 테이블로 만듬

● 전체 테이블 스캔 시 유리 ● 수행 속도 감소 ● 식별자의 유지 관리 어려움

< 개별타입 기준 테이블 변환 >

● 슈퍼타입과 서브타입들을 각각의 개별적인 테이블로 변환

● 각각 1:1 관계 형성

< 속성을 칼럼으로 변환 >

● 표준화된 약어 사용 ● 컬럼명은 SQL의 예약어 사용 피함/가능한 짧게 지정

● 샘플 데이터( 실제 데이터 )를 사용하여 컬럼의 정합성 검증

 

물리 데이터 모델 품질 검토

● DB의 성능 향상과 오류 예방

● 이해 관계자가 동의하는 검토 기준 필요

< 기준 >

● 정확성 : 요구사항이나 업무 규칙, 표기법에 따라 정확하게 표현

● 완전성 : 요구사항이나 업무 영역을 누락없이 반영

● 준거성 : 데이터 표준, 표준화 규칙, 법적 요건 등을 정확하게 준수

● 최신성 ● 일관성 ● 활용성 : 업무 변화에 따른 데이터 구조 변경 최소화