데이터베이스 생명주기 - 요구 조건 분석 단계 - 설계 단계 - 구현 단계 - 운영 단계 - 감시와 개선 단계
데이터베이스 설계 단계 - 요구 조건 분석: 요구 조건 명세서 작성 - 개념적 설계: 개념 스키마, 트랜잭션 모델링, E-R 모델 - 논리적 설계: 목표 DBMS에 맞는 스키마 설계 - 물리적 설계: 목표 DBMS에 맞는 물리적 구조의 데이터로 변환 - 구현: 특정 DBMS의 DDL로 데이터베이스 생성
요구 조건 분석 단계: 시스템의 운영상태 등을 분석하고 사용자들의 요구사항에 대한 분석까지 포함하는 단계 소프트웨어 공학에서의 눈덩이 효과: 분석 단계의 작은 오류 < 시스템 완성 단계의 누적된 오류
<요구 조건 분석>
인터뷰 진행 절차 - 개획과 준비 단계: 인터뷰 일정, 지침, 요지, 기록 양식 등을 결정하는 단계 - 인터뷰 수행 단계: 핵심 사항 및 상세 면담 기록 작성 - 인터뷰 결과 분석 단계: 인터뷰 결과 분석 - 분석 단계 피드백 단계: 인터뷰 분석 결과 승인 요청. 승인 완료 후 프로젝트 진행
<개념적 설계>
개념적 설계 단계 - DBMS에 독립적이고 고차원적인 표현 기법으로 기술 - 데이터베이스 요구 사항들 -> 개념적 설계 -> 개념적 스키마, ER 스키마
<ERD의 표현 방법 - CASE, 정보 공학(IE)> CASE: 프로그램을 개발하는데 사용되는 프로그램 자동화 도구. 일반적인 프로그램 툴과의 차이점은 CASE는 개발 방법론에 입각한 프로그래밍 자동화 도구라는 점
엔티티 - 업무의 관심 대상이 되는 정보를 갖고 있거나, 그에 대한 정보를 관리할 필요가 있는 유형 - 무형의 사물
업무 기술서에서 엔티티의 도출 1. 회사에는 다수의 사원들이 재직하고 있으며 사원들은 각자 부서에 소속되어 근무한다. 2. 각 사원에 대해서 사원 번호(고유 번호), 사원명, 직책, 급여, 입사 일은 년, 월, 일로 세분하여 나타낸다. 3. 각 사원은 한 부서에만 속하며 각 부서에 대해서 부서 번호(고유 번호), 부서명, 부서가 위치한 지역을 나타낸다.
주 식별자(=기본키) - 엔티티에 소속된 인스턴스들을 구분하는 기준이 되는 속성 - 만일 어떤 속성 X가 엔티티의 주 식별자라면 그 엔티티에 속한 모든 인스턴스들의 속성 X값을 비교했을 때 중복된 값이 나타나지 않아야 한다. - 사원 관리 시스템에서 엔티티, 속성, 주 식별자 도출
관계 - 두 엔티티 타입 사이의 관계를 의미. 업무의 흐름을 제대로 파악해야만 관계 도출 - 어떤 엔티티 A의 정보가 만들어지기 위해서는 다른 엔티티 B의 정보를 필요로 하는 관계에 있을 때 엔티티 B는 엔티티 A와 관계를 가지며 엔티티 B는 엔티티 A의 부모 엔티티가 된다.
외래식별자의 정의 - 부서와 사원 엔티티 간의 관계 도출 - 관계가 있는 두 엔티티를 부모, 자식으로 구분 - 부모 엔티티의 주 식별자 속성을 자식이 가지고 있는지를 확인(없으면 추가) 한다. 식별 관계, 비식별 관계
- 식별 관계: 자식테이블에서 기본키는 기본키이자 외래키. 즉, 부모 기본키 = 자식 기본키 - 비식별 관계: 자식테이블에서 기본키와 외래키는 따로 있음. 즉, 부모 기본키 != 자식 기본키
<논리적 설계>
논리적 데이터 모델 - 데이터베이스 관리 시스템의 종류에 따라 관계 데이터 모델, 네트워크 데이터 모델, 계층 데이터 모델 - 개념적 스키마, ER 스키마 -> 논리적 설계 -> 논리적 스키마, 관계 데이터베이스 스키마
정규 엔티티 타입과 단일 값 속성 약한 엔티티 타입과 단일 값 속성 - 강한 엔티티와 약한 엔티티의 관계가 있을때 약한 엔티티의 식별자로 강한 엔티티의 기본키가 넘어오게 됨 1:1 관계 타입 1:N 관계 타입 N:M 관계 타입 - 다대다 관계에서는 관계도 테이블로 만드는 것이 일반적 다중 값 속성
<물리적 설계>
물리적 설계 과정 - 사용 DBMS 결정 -> 데이터 타입 크기 결정 -> 데이터 용량 및 설계 및 업무 프로세스 분석 -> 역정규화 -> 무결성 제약조건 정의 -> 인덱스 정의 -> 데이터베이스 생성
물리적 설계 시 고려사항 - 응답 시간의 최소화, 저장 공간의 효율화, 트랜잭션 처리도(처리 능력)
자료 검색 방법 - FTS 방법: 테이블을 처음부터 끝까지 검색하는 방법 - 인덱스 스캔 방법: 인덱스를 통해 부분 검색을 하여 인덳에 저장된 테이블의 ROWID를 가지고 테이블을 검색한 후 정보를 가져오는 검색 방법
인덱스의 종류 - 논리적 구분에 따른 인덱스
구분
설명
단일 칼럼 인덱스와 결합 인덱스
- 단일 칼럼 인덱스: 한 개의 칼럼으로 생성된 인덱스 - 결합 인덱스: 두 개 이상의 칼럼으로 생성된 인덱스로, 최대 32개 칼럼의 조합으로 구성. 일반적으로 10개 이하의 칼럼 조합으로 생성
Unique 인덱스와 Non-Unique 인덱스
- Unique 인덱스: 모든 Unique 및 기본키 제약조건 생성 시 자동으로 Unique 인덱스 생성 - Non- Unique 인덱스: 중복된 값을 가질 수 없고 테이블의 칼럼 값이 중복되지 않도록 보장하기 위해서는 Non- Unique 인덱스보다는 Unique 제약조건으로 지정하여 칼럼 고유 값을 보장하는 것이 더 좋음
함수기반 인덱스
인덱스에 포함된 1개 이상의 칼럼이 함수 또는 수식을 사용하여 생성된 경우. 인덱스로 저장되기 전에 값이 계산됨. B-tree 또는 비트맵 인덱스로 생성. 오라클의 경우 버전 8.1.x부터 사용 가능
물리적 구분에 따른 인덱스
구분
설명
B-tree 인덱스
일반적으로 생성되는 인덱스는 거의 대부분이 B-tree 구조. 같은 키 값을 가지고 있는 Row가 여러 개이면 키 값이 반복됨. 모든 칼럼 값이 Null일 경우 인덱스는 만들어지지 않음. DML 문장의 WHERE 절에 자주 나오는 칼럼에 대해 데이터의 분포도가 테이블 전체의 약 10~15% 이내의 범위일때 인덱스 생성. 하나의 테이블에 인덱스를 많이 만들면 UPDATE, DELETE 작업 실행 속도가 느려짐. 한 개의 테이블에는 3~4개의 인덱스가 적당함
비트맵 인덱스
인덱스된 칼럼의 정보를 0과 1의 값으로 표현하여 데이터를 검색할 떄 SQL문의 WHERE 절에 정의된 AND, OR 연산자에 의해 AND 연산, OR 연산을 실행하여 데이터를 검색하는 방법. 인덱스를 적용하고자 하는 칼럼 값의 분포가 전체 행의 1% 미만인 경우에 생성. 인덱스한 칼럼 값의 변화가 거의 없어야 함. 인덱스 칼럼 값의 변화가 발생하면 테이블 전체 인덱스 데이터에 대해 인덱스를 다시 생서앻야 하므로 비용 추가
클러스터링 인덱스
클러스터링이란 논리적으로 관련된 데이터를 물리적으로도 디스크상에 인접시켜 저장하는 것. 관련된 데이터가 일반적으로 동시에 함께 사용된다는 특징 이용. 키가 아닌 특정 필드 값을 정렬해서 그 값을 탐색 키로 이용. 키가 아닌 필드를 탐색 키로 이용하기 때문에 탐색 키의 값은 중복될 수 있음. 수정이 자주 발생되지 않는 칼럼을 사용하며, 하나의 테이블에는 단 하나의 클러스터 인덱스를 생성할 수 있음. 칼럼 값이 다량 범위의 데이터일 경우, 해당 칼럼의 다량 데이터에 대한 검색(LIKE, BITWEEN 등)을 자주하는 경우 생성
성능 향상을 위한 인덱스 관리 - 인덱스 정보 확인 1. DBA_INDEXS는 DBA 권한으로 확인할 수 있는 뷰 2. USER_INDEXS는 일반 사용자 권한으로 자신이 생성한 인덱스 정보를 확인할 수 있는 뷰 3. ALL_INDEXS는 일반 사용자 권한으로 다른 사용자가 생성한 인덱스 정보를 확인할 수 있는 뷰
- 인덱스 재구축 1. 존재하는 인덱스를 다른 테이블스페이스(=데이터베이스)로 옮길 필요가 있는 경우 2. 테이블과 인덱스가 값은 테이블스페이스에 존재하거나 객체를 디스크로부터 분산시킬 필요가 있는 경우 3. 삭제된 테이블의 행이 많아 인덱스의 저장공간이 반환되지 않고 사용할 수 없는 공간으로 남아있는 경우 ex) 존재했던 번호는 삭제되고 새로운 번호로 데이터가 추가되었을 경우, 기존의 인덱스에는 삭제된 번호의 저장 공간이 반환되지 않으므로 공간 활용 면에서 문제가 있음. 이런 경우에는 인덱스를 재구축함으로써 공간을 효율적으로 활용 1) 기존 인덱스를 데이터 소스로 이용함으로써 인덱스 생성 시간 단축 2) 재구축 인덱스는 기존에 존재하는 인덱스를 데이터 소스로 하여 재구축 3) 신규로 인덱스를 생성할 경우 기존의 인덱스를 활용하여 생성하면 인덱스를 생성하는 속도 더 향상됨 4) 기존 인덱스를 이용하여 재구축 인덱스를 만들었을 경우에는 정렬이 필요 없으므로 신규 인덱스를 만드는 것에 비해 속도 향상 5) 기존의 인덱스를 삭제한 후 생성하는 경우가 아니므로 2개의 인덱스와 관련된 충분한 테이블스페이스 공간 필여 6) 재구축 인덱스를 구축한 후 기존 인덱스 제거. 재구축 인덱스를 구축하는 동안 기존 인덱스 및 재구축 인덱스와 관련된 테이블스테이스에 대해서는 충분한 공간 필요 7) 재구축 인덱스는 삭제된 테이블 행의 정보를 포함하지 않기 때문에 공간을 효율적으로 사용. 기존 인덱스는 삭제된 테이블 행의 정보를 포함하고 있음
역정규화: 시스템 성능을 고려해서 기존 설계를 재구성하는 것 칼럼 역정규화(데이터의 중복): 테이블 간의 조인을 줄이고자 데이터의 중복을 허용하는 방법 테이블 분리: 테이블 하나를 여러 테이블로 분리하는 방법 테이블 통합: 정규화를 통해서 나눈 테이블을 다시 하나의 테이블로 통합하는 작업
