물리데이터베이스

SQL 성능 튜닝의 정의

• 튜닝 대상이 되는 SQL을 이해하고 정보를 분석하여 성능을 개선하는 활동
• 최소한의 CPU, I/O, 메모리를 사용하여 최대한 빠른 시간 내에 원하는 작업을 수행하도록 만드는 것

SQL 성능 튜닝의 순서

1. 문제 있는 SQL 식별
2. 옵티마이저 통계 확인
3. 실행 계획 검토
4. SQL문 재구성
5. 인덱스 재구성
6. 실행 계획 유지 관리

SQL 성능 튜닝 순서

1. 문제 있는 SQL 식별

• 애플리케이션의 성능을 관리하거나 모니터링하기 위한 툴인 APM을 활용
  • APM; Application Performance Management

2. 옵티마이저 통계확인

• 개발자가 작성한 SQL을 가장 빠르고 효율적으로 수행할 최적의 처리경로를 생성해 주는 데이터베이스 핵심 모듈
• Oracle은 CBO와 RBO 모드 지원
  • CBO; Cost Based Optimizer
  • RBO; Rule Based Optimizer

3. 실행 계획 검토

• DBMS의 옵티마이저가 수립한 SQL 코드의 실행 절차와 방법을 의미
• 요구사항들을 처리하기 위한 연산 순서가 적혀 있으며, 연산에는 조인, 테이블, 검색, 필터, 정렬 등이 있음
• Driving 테이블이 최상의 필터를 가지고 있는지를 중심으로 검토
  • Driving 테이블
    • 조인이 발생할 때 첫 번째로 액세스 되는 테이블
    • 드라이빙 테이블 순서에 따라 데이터를 액세스하는 양이 대폭 늘어나거나 줄어들 수 있기 때문에 어떤 테이블을 먼저 드라이빙 하는지가 매우 중요
    • 가장 적은 데이터를 추출할 것으로 예상되는 테이블을 먼저 드라이빙
• 처리량이 작은 Table을 Driving 테이블로 지정되었는지 확인

4. SQL문 재구성

• WHERE절 사용
• 칼럼 변경 연산자 확인
• 범위 한정 사용
  • 서브쿼리에 특정 데이터가 존재하는지 확인할 때는 EXISTS 보다 IN 사용

5. 인덱스 재구성

• 인덱스 구성
• 실행 계획 검토
• 관련 SQL 검토
• 코드 테이블 확인
  • 단일 인덱스로 조회만 이루어진 테이블은 IOT로 구성
• 불필요한 인덱스 제거

6. 실행 계획 유지관리

• 실행 계획이 유지되고 있는지 모니터링하고 관리
• 데이터베이스 버전 업그레이드시
• 데이터의 시스템 이동 등 시스템 환경의 변경 사항 발생시

물리데이터베이스

CRUD의 개념

CRUD 분석의 개념

• 데이터베이스 테이블에 변화를 주는 트랜잭션의 CRUD 연산에 대해 CRUD 매트릭스를 작성하여 분석하는 것
• 테이블에 발생하는 트랜잭션의 주기별 발생횟수를 파악하고 연관된 테이블을 분석하면 테이블에 저장되는 데이터의 양을 유추할 수 있고 트랜잭션이 몰리는 테이블 분석 가능
• CRUD 연산의 우선순위
  • C > D > U > R
  • 활용목적에 따라 모두 적을 수 도 있음

CRUD 매트릭스 분석 개념

• 데이터 프로세스와 엔티티 목록으로 CRUD Matrix 작성
  

CRUD 매트릭스 점검사항

• 모든 엔티티 타입에 CRUD가 한 번 이상 표기되었는가?
• 모든 엔티티 타입에 C가 한 번 이상 존재하는가?
• 모든 엔티티 타입에 R이 한 번 이상 존재하는가?
• 모든 단위 프로세스가 하나 이상의 엔티티 타입에 표기가 되는가?

물리데이터베이스

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

• 엔티티는 테이블, 속성은 칼럼 등으로 변환
• 규칙

  논리적 설계	물리적 설계	데이터베이스
  엔티티 Entity	테이블 Table	테이블
  속성 Attribute	칼럼 Column	칼럼
  주 식별자 Primary Identifier	기본 키 Primary Key	기본 키
  외래 식별자 Foreign Identifier	외래 키 Foreign Key	외래 키
  관계 Relationship	관계 Relationship	-

논리 데이터 모델 물리 데이터 모델 변환 순서

1. 단위 엔티티를 테이블로 변환

• 논리 모델에서 정의된 엔티티는 물리 모델에서 테이블로 변환
• 엔티티는 한글명, 테이블은 영문명으로 명칭을 동일하게 사용
• 메타데이터시스템과 같은 사전에 표준화된 용어가 있을 경우 메타에 등록되어 있는 단어 사용하여 명명
  

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

• 서브타입을 슈퍼 타입에 통합하여 하나의 테이블로 만드는 것
• 서브타입에 속성이나 관계가 적을 경우에 적용하는 방법
• 하나로 통합된 테이블에는 서브 타입의 모든 속성 포함
  

1.2 슈퍼 타입 변환 장/단점

• 장점
  • 데이터의 액세스가 상대적으로 용이
  • 뷰를 이용하여 각각의 서브 타입 만을 액세스하거나 수정 가능
  • 수행 속도 향상
  • 서브 타입 구분이 없는 임의 집합에 대한 가공 용이
  • 다수의 서브 타입을 통합하는 경우 조인 감소
  • 복잡한 처리를 하나의 SQL로 통합 용이
• 단점
  • 특정 서브 타입에 대한 NOT Null 제한이 어려움
  • 테이블의 칼럼 증가로 디스크 저장 공간 증가
  • 처리마다 서브 타입에 대한 구분이 필요할 경우가 많이 발생
  • 인덱스의 크기 증가로 인덱스 효율이 낮아짐

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

• 슈퍼타입 속성들을 각각의 서브 타입에 추가하여 서브타입들을 개별적인 테이블로 만드는 것
• 서브 타입에 속성이나 관계가 많을 경우에 적용
  

1.4 서브 타입 변환 장/단점

• 장점
  • 각 서브 타입 속성들의 선택 사양이 명확한 경우에 유리
  • 서브 타입 유형에 대한 구분을 처리 마다할 필요가 없음
  • 여러 개의 테이블로 통합하므로 테이블 당 크기가 감소하여 전체 테이블을 스캔하는 경우 유리
  • 단위 테이블의 크기 감소
• 단점
  • 서브 타입 구분 없이 데이터를 처리하는 경우 UNION이 발생
  • 처리 속도 감소가 발생할 가능성이 높아짐
  • 트랜잭션을 처리하는 경우 다수 테이블을 처리하는 경우가 자주 발생
  • 복잡한 처리를 하는 SQL의 통합이 어려움
  • 부분 범위에 대한 처리가 곤란해짐
  • 여러 테이블을 통합한 경우 뷰로 조회만 가능
  • UID의 유지관리가 어려움
    • Unique Identifier, 식별자

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

• 슈퍼 타입과 서브 타입들을 각각의 개별적인 테이블로 변환
• 슈퍼 타입과 서브 타입 각각의 테이블 사이에는 1:1 관계 형성
  

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

• 전체 데이터에 대한 처리가 자주 발생하는 경우
• 서브 타입 처리가 대부분 독립적으로 발생하는 경우
• 통합하는 테이블의 칼럼 수가 지나치게 많은 경우
• 서브 타입 칼럼 수가 다수인 경우
• 트랜잭션이 주로 슈퍼 타입에서 발생하는 경우
• 슈퍼 타입에서 범위가 넓은 처리가 빈번하게 발생하여 단일 테이블 클러스터링이 필요한 경우

2. 속성을 Column 칼럼으로 변환

• 칼럼의 명칭은 속성의 명칭과 반드시 일치할 필요는 없으나, 개발자와 사용자간 의사소통을 위해 가능한 표준화된 약어를 사용
• SQL 예약어 사용은 피해야 함
• SQL 문장의 가독성을 위해 칼럼 명칭은 가능한 짧게
• 칼럼명에 복합 단어 사용할 경우 미리 정의된 표준에 의해 명명

3. UID를 기본키로 변환

• 엔티티의 UID는 기본키로 선언
• Not NULL, Unique 등의 제약 조건을 추가적으로 정의

4. 관계를 외래키로 변환

• 1:n 관계에서 1영역에 있는 기본키를 n영역의 외래키로 선언
• 외래키명은 1영역의 기본키 이름을 사용하거나 다른 의미를 가질 경우 변경하여 명명
• 순환 관계에서 자신의 기본키는 외래키로 정의

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

• 논리 모델링에서는 필요가 없으나 관리 또는 데이터베이스를 이용하는 프로그래밍의 수행 속도를 향상을 위해 추가 되는 테이블이나 칼럼
• 관리상 필요한 데이터를 등록한 일자, 시스템 번호 등을 의미

6. 칼럼 유형과 길이 정의

• 정의된 각 컬럼에 대해, 적용 DBMS에서 제공하는 데이터 유형 중 적절한 유형 정의
• 해당 데이터의 최대 길이를 파악하여 길이 설정
• 자주 사용되는 데이터 유형

7. 데이터 표준 적용

• 명명 규칙 및 표준 용어 사전을 활용하여 각 객체의 데이터 표준 수행
• 표준화 적용대상
  • 데이터베이스
  • 스토리지 그룹
  • 테이블 스페이스
  • 테이블
  • 칼럼
  • 인덱스
  • 뷰

물리데이터베이스

• 물리데이터 모델에 대하여 정확성, 완전성, 준거성, 최신성, 일관성, 활용성의 품질기준을 적용
• 논리 데이터 모델과 물리 데이터 모델을 비교하여 테이블, 칼럼, 키, 오브젝트 구성 요소의 누락 여부와 일치성을 확인
• 논리 데이터베이스 설계에서 엔티티, 속성, 주식별자, 외래식별자를 각각 테이블, 칼럼, 기본 키, 외래 키로 변환하여 표현
• CRUD 분석과 SQL 성능 튜닝의 개념과 절차를 이해

물리 데이터 모델 품질 기준

• 물리 데이터 모델을 설계하고 데이터베이스 객체를 생성한 후 개발 단계로 넘어가기 전에 모델러와 이해관계자들이 모여 수행
• 시스템 성능에 직접적인 영향을 미치므로 향후 발생할 문제에 대해 면밀히 검토해야 함
• 데이터베이스 성능 향상과 오류 예방
• 검토시 모든 이해관계자가 동의하는 검토 기준이 필요

품질기준

• 정확성

  • 데이터 모델이 표기법에 따라 정확하게 표현되었고, 업무영역 또는 요구사항이 정확하게 반영되었음을 의미
  • 예시
    • 사용된 표기법에 따라 데이터 모델이 정확하게 표현되었는가?
    • 대상 업무 영역의 업무 개념과 내용이 정확하게 표현되었는가?
    • 요구사항의 내용이 정확하게 반영되었는가?
    • 업무 규칙이 정확하게 표현되었는가?

• 완정성

  • 데이터 모델의 구성 요소를 정의하는데 있어서 누락을 최소화하고, 요구 사항 및 업무 영역 반영에 있어서 누락이 없음을 의미
  • 예시
    • 물리 데이터 모델 작성 항목의 충실도
    • 필요한 설명 항목(테이블/칼럼 설명)들의 작성 상태
    • 물리 모델링 단계에서 결정해야 할 항목들의 작성 성태(칼럼 데이터 타입 및 길이, Null 허용 여부, 서브타입 변환 등 필요에 따라서는 저장공간 지정, 테이블/인덱스 생성 관련 파라미터 결정 사항등까지도 포함)
    • 요구 사항 반영 및 업무 영역 방녕의 완전성 : 목적하는 업무 영역을 기술한 논리 데이터 모델의 구성 요소(엔티티, 속성, 관계, 식별자)들이 누락없이 물리 데이터 모델로 변환되어 정의된 정도

• 준거성

  • 제반 준수 요건들이 누락 없이 정화하게 준수되었음을 의미
  • 예시
    • 데이터 표준, 규칙 등을 준수하였는가?
    • 법적 요건을 준수하였는가?
    • 법적 요건을 준수하기에 충분하도록 도메인이 정의 되었는가?

• 최신성

  • 데이터 모델이 현행시스템의 최신 상태를 반영하고 있고, 이슈 사항들이 지체 없이 반영되고 있음을 의미
  • 예시
    • 엄무상의 변경이나 결정 사항 등이 시의 적절하게 반영되고 있는가?
    • 최근의 이슈 사항이 반영되었는가?
    • 현행 데이터 모델의 현행 시스템과 일치하는가?

• 일관성

  • 여러 영역에서 공통 사용되는 데이터 요소가 전사 수준에서 한 번만 정의되고 이를 여러 다른 영역에서 참조/활용되면서, 모델 표현상의 일관성을 유지하고 있음을 의미
  • 예씨
    • 여러 주제 영역에서 공통적으로 사용되는 개체는 일관성 있게 사용되는가?(전사 수준에서 한 번만 정의되고 이를 여러 다른 영역에서 참조/활용한다는 의미에서 통합성이라고하기도 함)
    • 모델 표현상의 일관성을 유지하고 있는가?
    • 동일/유사 목적/용도의 칼럼들은 일관성 있게 정의되었는가?
    • 조인 대상 칼럼들은 일관성있게 정의되었는가?

• 활용성

  • 작성된 모델과 그 설명 내용이 이해관계자에게 의미를 충분하게 전달할 수 있으면서, 업무 변화 시에 설계 변경없이 최소화되도록 유연하게 설계되어 있음을 의미
  • 예시
    • 작성된 설명 내용이나 모델 표기 등이 사용자나 모델을 보는 사람에게 충분히 이해가 될 수 있고, 모델의 작성 의도를 명확하게 이해할 수 있는가(의사소통의 충분성)
    • PK, UK 등의 칼럼 구성은 데이터 무결성을 보장하면서 데이터 액세스를 효율화 하기에 충분한가?
    • 논리 데이터 모델의 유연성이 물리 데이터 모델에도 반영되었는가(오류가 적고 업무 변화에 유연하게 대응하여 데이터 구조의 변경이 최소화 될 수 있는 설계 결과)
    • 코드화 대상 칼럼에 대한 코드 정의는 업무 지원 및 적용에 충분한가?

물리 데이터 모델의 품질 검토 순서

1. 데이터 품질 정책 및 기준 확인
2. 물리 데이터 품질의 특성에 따라 품질 기준 작성
3. 데이터 품질 기준에 따라 체크리스트 작성
4. 논리 데이터 모델과 물리 데이터 모델 비교
5. 각 모델링 단계의 모델러와 이해관계자가 품질 검토 수행
6. 모델러와 이해관계자가 작성한 체크리스트 내용을 종합하여 물리 데이터베이스 모델의 품질 검토 보고서 작성

물리데이터베이스

1. 데이터베이스 무결성

• 데이터의 정확성을 보장하기 위해 부정확한 자료가 데이터베이스 내에 저장되는 것을 방지 하기 위한 제약 조건임
• 무결정의 종류
  • 개체 무결성
  • 도메인 무결성
  • 참조 무결성
  • 사용자 정의 무결성

2. 칼럼 속성

• 속성은 데이터베이스를 구성하는 가장 작은 논리적 단위
• 파일 구조상의 데이터 항목 또는 데이터 필드에 해당됨
• 특성에 따른 분류
  • 기본 속성
  • 설계 속성
  • 파생 속성
• 개체 구성 방식에 따른 분류
  • 기본키 속성
  • 외래키 속성
  • 일반 속성

3. 키 종류

• 데이터베이스에서 조건에 만족하는 튜플을 찾거나 순서대로 정렬할 때 튜플들을 서로 구분할 수 있는 기준이 되는 애트리뷰트
• 종류
  • 슈퍼키
  • 후보키
  • 기본키
  • 대체키

4. 반정규화

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

물리데이터베이스

반정규화 Denormalization 개념

• 시스템의 성능 향상, 개발 및 운영의 편의성 등을 위해 정규화된 데이터 모델을 통합, 중복, 분리하는 과정으로 의도적으로 정규화 원칙을 위배하는 행위
• 반정규화를 수행하면 시스템의 성능이 향상되고 관리 효율성은 증가하지만 데이터의 일관성 및 무결성이 저하될 수 있므
• 과도한 반정규화는 오히려 성능을 저하시킬 수 있음
• 데이터의 일관성과 무결성을 우선으로 할 지, 데이터베이스의 성능과 단순화를 우선으로 할 지를 사전에 결정해야 함
• 방법
  • 테이블 통합
  • 테이블 분할
  • 중복 테이블 추가
  • 중복 속성 추가

반정규화 방법

1. 테이블 통합

• 테이블 조인이 많은 경우 하나의 테이블로 합치는 것이 성능 향상에 유리
• 종류
  • 1:1 관계 테이블 통합
  • 1:N 관계 테이블 통합
  • 수퍼타입/서브타입 테이블 통합
• 고려사항
  • 데이터 검색은 간편하지만, 레코드 증가로 처리량 증가
  • 입력, 수정, 삭제 규칙의 복잡도 증가

2. 테이블 분할

• 테이블에서 특정 레코드나 특정 속성에 집중적으로 접근할 경우 테이블 분할
• 종류
  • 수평 분할
  • 수직 분할

2.1 수평 분할

• Record 레코드를 기준으로 테이블을 분할
• 레코드별로 사용 빈도의 차이가 큰 경우 사용 빈도에 따라 분할

2.2 수직 분할

• 테이블의 많은 속성 중 특정 속성들만 접근이 잦을 경우 속성을 기준으로 테이블을 분할
• 갱신 위주의 속성 분할
  • 데이터 갱신 시 레코드 잠금으로 인해 다른 작업을 수행할 수 없으므로 갱신이 자주 일어나는 속성 분할
• 자주 조회되는 속성 분할
  • 자주 조회되는 속성이 극히 일부일 경우 자주 사용되는 속성을 수직 분할하여 사용
• 크기가 큰 속성 분할
  • 이미지나 2GB이상 저장 될 수 있는 텍스트 형식 등으로 된 속성을 수직 분할하여 사용
• 보안을 적용해야 하는 속성 분할
  • 테이블 내 특정 속성에 대한 보안ㅇ르 적용할 수 없으므로 보안을 적용해야 하는 속성들을 수직분할하여 사용

2.3 테이블 분할 시 고려사항

• 기본키의 유일성 관리가 어려움
• 데이터 양이 적거나 사용 빈도가 낮은 경우 테이블 분할이 필요한지를 고려
• 분할된 테이블의 전체 조회 시는 Union을 사용해야하므로 수행 속도가 느려짐
• 데이터 검색에 중점을 두어 테이블 부할 여부를 결정해야 함

3. 중복 테이블 추가

• 여러 테이블에서 데이터를 추가해서 사용해야 하는 경우
• 다른 서버에 저장된 테이블을 이용해야하는 경우

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

• 정규화로 인해 수행 속도가 느려지는 경우
• 많은 범위의 데이터를 자추 처리해야하는 경우
• 특정 범위의 데이터를 자추 처리해야하는 경우
• 처리 범위를 줄이지 않고는 수행 속도를 개선할 수 없는 경우

3.2 중복 테이블 추가하는 방법

• 집계 테이블 추가
  • SUM, AVG 등 집계 데이터를 위한 테이블을 생성하고, 각 원본 테이블에 트리거를 설정하여 사용하는 것
• 이력 테이블 추가
  • 이력 관리 드으이 목적으로 추가하는 테이블로, 적절한 데이터 양의 유지와 활용도를 제고하기 위해 기본키를 적절히 설정
• 부분 테이블 추가
  • 하나의 테이블의 전체 칼럼 중 자주 이용하는 집중화 된 칼럼들이 있을 때 해당 칼럼들을 모아 놓은 별도의 반정규화된 테이블 생성

4. 중복 속성 추가

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

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

• 조인이 자주 발생하는 속성인 경우
• 접근 경로가 복잡한 속성인 경우
• 기본키의 형태가 적절하지 않거나 여러 개의 속성으로 구성된 경우

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

• 테이블 중복과 속성의 중복을 고려
• 테이블 일관성 및 무결성에 유의
• SQL 그룹 함수를 이용하여 처리할 수 있어야 함
• 저장 공간의 지나친 낭비를 고려

물리데이터베이스

키의 개념

• 데이터베이스에서 조건에 만족하는 튜플을 찾거나 순서대로 정렬할 때 튜플들을 서로 구분할 수 있는 기준이 되는 애트리뷰트
• 종류
  • 슈퍼키
  • 후보키
  • 기본키
  • 대체키

키의 특징

• Uniqueness 유일성
  • 하나의 키 값으로 하나의 튜플만을 유일하게 식별할 수 있어야 함
• Minimality 최소성
  • 릴레이션의 모든 튜플을 유일하게 식별하기 위해 꼭 필요한 속성만으로 구성

키의 종류 개념도

• 슈퍼키 > 후보키 > 대체키 > 기본키
• 후보키 = 기본키 + 대체키
• 기본키 = 후보키 - 대체키

키의 종류 상세

• 슈퍼키 Super Key
  • 한 릴레이션 내의 속성들의 집합으로 구성된 키
  • 릴레이션을 구성하는 모든 튜플에 대해 유일성은 만족시키지만 최소성은 만족시키지 못함
  • ex) 학번+주민번호
• 후보키 Candidate Key
  • 릴레이션을 구성하는 속성들 중에서 튜플을 유일하게 식별할 수 있는 하나 또는 몇 개의 속성의 집합
  • 릴레이션의 모든 튜플에 대해 유일성과 최소성 모두 만족
• 기본키 Primary Key
  • 릴레이션에서 튜플ㅇ르 구별할 수 있는 유일한 식별자
  • 후보키 중에서 선정된 키로 유일성과 최소성 만족
  • 기본키는 Null값을 가질 수 없고 중복값을 가질 수 없음
• 대체키 Primary Key
  • 후보키가 둘 이상인 경우 기본키로 선택되지 못한 후보들키를 보조키라고도 함
• 외래키 Foreign Key
  • 참조되는 릴레이션의 기본키와 대응되어 릴레이션 간에 참조관계 표현
  • 참조 릴레이션의 기본키에 없는 값은 입력할 수 없음

물리데이터베이스

칼럼 속성의 정의 및 특징

• 속성은 데이터베이스를 구성하는 가장 작은 논리적 단위
• 파일 구조상의 데이터 항목 또는 데이터 필드에 해당됨
• 속성은 개체의 구성 항목이며 특성을 기술
• 속성의 수는 Degree 또는 차수라고 함

속성의 특성에 따른 분류

• 기본 속성 Basic Attribute
  • 업무 분석을 통해 정의한 속성
  • 개체 타입에 가장 일반적이고 많은 속성을 차지
  • 업무로부터 분석한 속성이라도 이미 업무상 코드로 정의한 속성은 기본 속성에서 제외
• 설계 속성 Designed Attribute
  • 원래 업무에는 존재하지 않지만 설계를 하면서 도출하는 속성
  • 업무의 필요에 의해 새로 만들거나 변형하여 정의한 속성
• 파생 속성 Derived Attribute
  • 다른 속성으로부터 계산이나 변형되어 생성되는 속성
  • 다른 속성의 영향을 받기 때문에 정합성 유지를 위해 가급적 파생 속성을 적게 정의하는 것이 좋음

개체 구성 방식에 따른 분류

• 기본키 속성
  • 개체를 식별할 수 있는 속성
• 외래키 속성
  • 다른 개체와의 관계에서 포함된 속성
• 일반 속성
  • 개체에 포함되어 있고 기본 키, 외래 키에 포함되지 않은 속성

속성 후보 선정 원칙

• 원시 속성으로 보이는 후보는 버리지 않음
• 소그룹별로 후보군을 만들고 가장 근접한 개체에 할당

속성명 지정 원치

• 해당 업무에서 사용하는 이름을 부여
• 서술식 속성명은 사용하지 않음
• 약어 사용은 가급적 자제
• 개체 타입명은 속성명으로 사용해서는 안됨
• 개체타입에서 유일하게 식별 가능하도록 지정

물리데이터베이스

• 데이터베이스 무결성과 칼럼 속성 및 키 종류에 대해 이해
• 테이블 간의 조인을 줄이기 위한 칼럼 반정규화, 정규화에서 나눈 테이블을 하나의 테이블로 통합, 하나의 테이블을 여러 개 테이블로 분리, 요약 테이블을 생성의 방법으로 반정규화를 수행
• 반정규화에 따른 영향도를 조사하여 적절한 조치를 하고, 반정규화가 적용된 물리 데이터베이스 설계서를 작성

데이터베이스 무결성 Integrity 개념

• 데이터의 정확성, 일관성, 유효성, 신뢰성 등과 무효 갱신으로부터 데이터 보호 등을 위해 필요
• 무결성 제약 조건은 데이터베이스에 들어 있는 데이터의 정확성을 보장하기 위해 부정확한 자료가 데이터베이스 내에 저장되는 것을 방지 하기 위한 제약 조건임
• 무결정의 종류
  • 개체 무결성
  • 도메인 무결성
  • 참조 무결성
  • 사용자 정의 무결성

무결성의 종류

1. Entity Integrity 개체 무결성, 실체 무결성

• 개체의 유일성을 보장하기 위한 무결성
• 데이터베이스 테이블은 기본 키로 설정된 속성은 null 값이나 중복 값을 가질 수 없음

2. Domain Integrity 도메인 무결성, 영역 무결성

• 특정 속성 값이 미리 정의된 도메인 범위에 속해야 함
• 도메인은 하나의 애트리뷰트가 취할 수 있는 같은 타입의 원자값의 집합

3. Referential Integrity 참조 무결성

• 릴레이션은 참조할 수 없는 외래키 값을 가질 수 없음
• 외래키 값은 Null이거나 참조하는 릴레이션의 기본 키 값이어야 함

4. User Defined Integrity 사용자 정의 무결성

• 모든 데이터는 사용자가 정의한 제약 조건인 업무 규칙 Business Rule을 준수해야 함

데이터 무결성 강화 개념

• 데이터 품질에 직접적인 영향을 주며, 데이터의 품질을 확보하고 유지하기 위해서는 데이터베이싀 구축 과정에서 적정한 무결성 방안을 확보 해야 함
• 프로그램이 완성되고 데이터가 축척된 상태에서 무결성을 정의할 경우 많은 비용 발생
• 데이터베이스에서 모두 이뤄질 수 없으므로 복잡한 규칙을 기반으로 데이터 상호 간 유지해야할 정합성은 어플리케이션 내에서 처리

데이터 무결성 강화 방법

1. 애플리케이션

• 데이터를 조작하는 프로그램 내에 데이터 생성, 수정, 삭제 시 무결성 조건을 검증 하는 코드를 추가
• 장점
  • 사용자 정의 같은 복잡한 무결성 조건을 구현
• 단점
  • 소스코드에 분산되어 관리의 어려움이 있음
  • 개별적으로 시행되므로 적정성 검토에 어려움

2. 데이터베이스 트리거

• 트리거 이벤트시 저장 SQL을 실행하여 무결성 조건을 실행
• 장점
  • 통합 관리가 가능함
  • 복잡한 요건 구현 가능

3. 제약 조건

• 데이터베이스 제약 조건 기능을 선언하여 무결성을 유지
• 장점
  • 통합 관리가 가능함, 간단한 선언으로 구현 가능
  • 변경이 용이하고, 유효/무효 상태 변경이 가능
  • 원칙적으로 잘못된 데이터 발생을 막을 수 있음
• 단점
  • 복잡한 제약 조건 구현이 불가능, 예외적인 처리가 불가능

물리데이터베이스

1. 파티셔닝

• 데이터베이스에서 파티션은 대용량의 테이블이나 인덱스를 작은 논리적 단위인 파티션으로 나누는 것
• 장점
  • 데이터 접근 시 액세스 범위를 줄여 쿼리 성능이 향상됨
  • 파티션별로 데이터가 분산되어 저장되므로 디스크의 성능이 향상됨
  • 파티션별로 백업 및 복구를 수행하므로 속도가 빠름
  • 시스템 장애 시 데이터 손상 정도를 최소화
  • 데이터 가용성이 향상됨
  • 파티션 단위로 입/출력을 분산시킬 수 있음
• 단점
  • 하나의 테이블을 세분화하여 관리하므로 세심한 관리가 요구됨
  • 테이블간 조인에 대한 비용이 증가함
  • 용량이 작은 테이블에 파티셔닝을 수행하면 오히려 성능이 저하됨
• 종류
  • 범위 분할
  • 해시 분할
  • 조합 분할

2. 클러스터링

• 데이터 저장시 데이터 액세스 효율을 향상시키기 위해 동일한 성격의 데이터를 동일한 데이터 블록에 저장하는 물리적 저장 방법
• 클러스터 대상 테이블
  • 분포도가 넓은 테이블
  • 대량의 범위를 자주 조회하는 테이블
  • 입력, 수정, 삭제가 자주 발생하지 않는 테이블
  • 자주 조인되어 사용되는 테이블
  • ORDER BY, GROUP BY, UNION이 빈번한 테이블

3. 데이터베이스 백업

• 데이터베이스 백업은 전산 장비의 장애에 대비하여 데이터베이스에 저장된 데이터를 보호하고 복구하기 위한 작업
• 로그 파일
  • 데이터베이스의 처리 내용이나 이용 상황 등 상태 변화를 시간의 흐름에 따라 모두 기록한 파일
• 데이터베이스 복구 알고리즘
  • NO-UNDO/REDO
  • UNDO/NO-REDO
  • UNDO/REDO
  • NO-UNDO/NO-REDO
• 백업 종류
  • 물리 백업
  • 논리 백업

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

• 데이터베이스 용량을 설계할 때는 테이블에 저장할 데이터양과 인덱스, 클러스터 등이 차지하는 공간 등을 예측하여 반영함
• 데이터베이스의 용량을 정확히 산정하여 디스크의 저장공간을 효과적으로 사용하고 확장성 및 가용성을 높임
• 테이블스페이스 설계 시 고려사항
  • 테이블스페이스는 업무별로 구분하여 지정
  • 대용량 테이블은 하나의 테이블스페이스에 독립적으로 저장
  • 테이블과 인덱스는 분리하여 저장
  • LOB(Large Object)타입의 데이터는 독립적인 공간으로 지정

5. 데이터 지역화 Locality

• 데이터베이스의 저장 데이터를 효율적으로 이용할 수 있도록 저장하는 방법
• 물리적 데이터베이스 설계, 보조 기억 장치의 역할, 디스크 상의 파일의 배치를 지역화 관점에서 검토