논리 데이터 저장소 확인 물리적 데이터 저장소 설계

일반적인 시스템 개발 절차

 

논리 데이터 저장소

데이터 및 데이터 간 연관성, 제약조건을 식별하여 논리적 구조로 조직화하여 모델링 표기법으로 형성화한 데이터 저장소

 

물리 데이터 저장소

논리 데이터 저장소에 저장된 데이터와 구조들을 DBMS의 특성을 고려하여 저장한 하드웨어적 저장 장치

 

데이터 모델링

1. 데이터 모델링 정의

기업의 정보 구조를 실체(Entity)와 관계(Relation)를 중심으로 명확하고 체계적으로 표현하여 문서화하는 기법

 

2. 데이터 모델링 목적

(1) 연관 조직의 정보요구에 대한 정확한 이해를 할 수 있음

(2) 사용자, 설계자, 개발자 간에 효율적인 의사소통 수단을 제공

(3) 데이터 체계 구축을 통한 고품질 S/W와 유지보수 비용의 감소효과를 기대할 수 있음

(4) 신규 또는 개선 시스템의 개발 기초를 제공

 

3. 데이터 모댈링 특성

(1) 데이터 중심 분석을 통한 업무 흐름 파악이 용이

(2) 데이터 무결성을 보장할 수 있음

(3) 데이터의 공유를 통한 중복을 제거하고 일관성 있는 정보를 제공받을 수 있음

 

 

데이터 모델링 절차

1. 개념 데이터 모델링

: 전사의 정보요건을 표현한 상위수준의 모델로서

(1) 주요 엔티티타입, 기본 속성, 관계, 주요 업무기능

(2) 모든 업무 영역, 주요 업무 규칙 정의

(3) 논리 데이터 모델의 기초가 됨

개체-관계(E-R) 모델

 

2. 논리 데이터 모델링

엔티티(Entity)와 속성(Attribute)들의 관계(Relation)를 구조적으러 정의하는 단계이고 개념 모델로부터 업무 영역의 업무 데이터

및 규칙을 구체적으로 표현한 모델

(가) 엔티티(Entity): 관리할 대상이 되는 실체

(나) 속성(Attribute): 관리할 정보의 구체적 항목

(다) 관계(Relationship) : 엔티티간의 대응관계

(1) 모든 업무용 엔티티 타입, 속성, 관계, 프로세스 등을 포함

(2) 모든 업무 데이터를 정규화(Normalization)하여 모델링

(3) 모든 업무 규칙과 관계를 완전하고 정확하게 표현

(4) 성능 혹은 기타 제약 사항과는 독립적인 모델로서, 특정 DBMS로부터 독립적

 

 

정규화

(1) 정의

중복성을 최소화하고 정보의 일관성을 보장하기 위한 개념

 

(2) 특징

(가) 어떠한 관계구조가 바람직한 것인지, 바람직하지 못한 관계를 어떻게 분해하여야 하는지 관한 구체적인 판단기준을 제공

(나) 정규화된 데이터 모델은 정확성, 일치성, 단순성, 비중복성, 안정서 보장

 

(3) 정규화 수준에 따른 장단점

정규화 수준이 높을수록

  (가) 장점

     1) 유연한 데이터 구축이 가능

     2)  데이터의 정확성 높아짐

  (나) 단점

     1) 물리적 접근이 복잡

     2) 길이가 짧은 데이터 생성으로 과도한 조인 발생

 

논리 데이터 모델의 검증 포인트

구축하고자 하는 업무 시스템의 사용자 요구사항과 데이터 흐름이 누락되지 않고 반영되었는지

모델링 표준의 준수도

중복회피를 위한 정규화가 수행되었는지

 

3. 물리 데이터 모델링

설계단계에서의 정보 요건을 정확하고 안전하게 표현한 모델

(1) 데이터베이스 생성을 위한 물리 구조로 변환

(2) 설계와 성능을 고려한 조정을 수행

(3) 적용 DBMS에 적합한 성능 조정을 수행

 

물리적 데이터 저장소 설계

논리적 DB 설계와 물리적 DB 설계의 차이점

논리적 DB 설계(데이터모델링)	물리적 DB 설계
DBMS의 종류나 제품에 상관없이 진행 (ERD는 어떤 데이터베이스를 사용해도 적용 가능)	특정 DBMS를 전제로 진행 (적용 DBMS의 특성을 고려함)
엔티티(entity) 속성(attribute) 주식별자(primary identifier) 외래식별자(foreign identifier)	테이블(table) 컬럼(column) 기본키(primary key) 외래키(foreign key) 뷰(view) 인덱스(index)

 

논리적 DB 설계 -> 물리적 DB 설계

논리적 설계의 산출물인 ERD의 요소들을 관계형 데이터베이스의 요소들로 전환하는 것

ERD 요소들의 전환

 

물리 데이터 모델 설계 순서

1. 엔티티 -> 테이블

엔티티는 그대로 테이블로 변환됨

한글 엔티티명 -> 영문 테이블명

엔티티 -> 테이블 전환

 

 

2. 속성 -> 컬럼

한글 상속명 -> 영문 컬럼명

데이터 타입의 지정

속성 -> 컬럼 전환

 

3. 주식별자 -> 기본키, 외래식별자 -> 외래키

주식별자, 외래 식별자 -> 기본키, 외래키 전환

 

4. 관계의 전환

논리적 설계에서 엔티티간의 관계(relationship)는 물리적 설계에서도 그대로 유지

관계의 전환

카드널리티, 선택/필수도 그대로 적용

관계의 카드널리티 전환

관계의 참여도 전환

 

5. 칼럼의 유형, 길이 정의

CHAR, VARCHAR2, NUMBER, DATE

 

6. 반정규화 수행

반정규화(Denormalization)

1. 정의

정규화에 충실하여 모델링을 수행하면 종속성, 활용성은 향상되나 수행속도가 중가하는 경우가 발생하여 이를 극복하기 위해 성능에 중점을 두어 정규화하는 방법

 

2. 특징 

(1) 데이터 모델링 규칙에 얽매이지 않고 수행

(2) 시스템이 물리적으로 구현되었을 때 성능향상을 목적으로 함

 

3. 사용시기

(1) 정규화에 충실하였으나 수행속도에 문제가 있는 경우

(2) 다량의 범위를 자주 처리해야 하는 경우

(3) 특정범위의 데이터만 자주 처리하는 경우

(4) 처리범위를 줄이지 않고는 수행속도를 개선할 수 없는 경우

(5) 요약 자료만 주로 요구되는 경우

(6) 추가된 테이블의 처리를 위한 오버헤드를 고려하여 결정

(7) 인덱스의 조정이나 부분범위처리로 유도하고, 클러스터링을 이용하여 해결할 수 있는지를 철저히 검토 후 결정

 

엔티티 통합에 의한 반정규화

두 엔티티를 조인하는데 걸리는 시간을 절약하려는 목적

항상 혹은 대부분 조인에 대한 검색을 하고, 검색이 빈번히 이루어지는 두 개의 엔티티를 대상으로 함

두 엔티티의 통합에 의한 반정규화

 

 

 

엔티티 분할에 의한 반정규화

엔티티의 튜플 수 및 속성의 수가 매우 많고, 엔티티의 속성들이 그룹화되어 각 그룹이 특정 부서 혹은 응용 프로그램에 의해서만 사용될 때

엔티티의 데이터 크기 감소, 검색의 분산

 

 

튜플의 검색 빈도가 다르다는 점을 이용

엔티티의 데이터 크기 감소 효과

엔티티 수평분할에 의한 반정규화

 

물리 데이터저장소 구성

물리적 데이터 저장소 설계에 따라 데이터저장소에 실제 데이터를 저장될 물리적 공간을 구성

다양한 오브젝트를 설계

    1. 테이블 제약조건 설계 : 참조 무결성을 관리하기 위한 제약조건(Constraint)을 정의

    2. 인덱스(index) 설계

         인덱스(index)는 테이블에 대한 검색 속도를 향상시킬 수 있는 확실한 수단

         책 뒤에 붙어 있는 색인과 비슷한 역할

          순차적 접근

              - 튜플 수가 많아지면 대량의 데이터에 대한 검색 방법으로는 적당하지 않음

          이진 검색

              - 데이터가 정렬되어 있다면 적은 비교횟수로 원하는 튜플을 찾을 수 있음

              - 그러나 10만개의 튜플에 대해 정렬 상태를 유지하는 것은 매우 많은 비용이 듬

 

         

          인덱스로 검색

              - 실제 데이터는 정렬되어 있지 않지만 마치 정렬되어 있는 것과 같은 효과를 얻을 수 있음

 

 

       인덱스에 대한 검토

          - 인덱스의 수가 많으면 인덱스를 재정렬하는데 많은 시간이 소모되므로 DBMS의 성능을 저하시킴

          - 그러므로 인덱스는 꼭 필요한 컬럼에 대해서만 지정을 해야 함

          - 모든 경우에 대해 인덱스가 성능을 발휘하는 것은 아님

                1. 인덱스로 지정하는 컬럼은 SQL의  WHERE 절에서 비교 대상이 되는 컬럼 또는 JOIN에 사용되는 컬럼

                2. 튜플의 수가 적으면 인덱스를 지정하여도 별 효과가 없음

                3. 인덱스로 지정한 컬럼에 의해 검색했을 때 검색 결과가 전체 튜플의 10~15% 미만일 때 인덱스의 효과가 있음

 

 

3. 뷰 설계: 테이블을 기초로 가상(논리) 테이블을 말함

뷰 속성

(1) REPLACE: 뷰가 이미 존재하는 경우 재생성

(2) FORCE: 기본 테이블의 존재 여부에 관계 없이 뷰 생성

(3) NOFORCE: 기본 테이블이 존재할 때 만 뷰 생성

(4) WITH CHECK OPTION: Sub-Query 내의 조건을 만족하는 행만 변경

(5) WITH READ ONLY:DML 작업 불가

뷰 정의서의 예

 

4. 클러스터 설계

지정된 컬럼 값의 순서대로 데이터 행을 저장하는 방법으로, 하나 혹은 그 이상의 테이블을 같은 클러스터 내 저장이 가능합니다.

1) 적용 기준

    분포도가 넓을수록 오히려 유리(인덱스의 단점을 해결)한 기법

    액세스 기법이 아니라 액세스 효율 향상을 위한 물리적 저장 방법

    분포도가 넓은 테이블의 클러스터링은 저장 공간의 절약 가능

    다중(일반적으로 6) 블록 이상의 테이블에 적용

    다량의 범위를 자주 액세스하는 경우 적용

    인덱스를 사용한 처리 부담이 되는 넓은 푼포도에 활용

    여러 개의 테이블이 빈번히 조인을 일으킬 때 활용

    반복 컬럼이 정규화에 의해 어쩔 수 없이 분할된 경우 활용

 

2) 클러스터 설계시 고려사항

    검색 효율은 높여 주나 입력, 수정, 삭제 시는 부하가 증가함을 고려해야 함

    Union, Distinct, Order by, Group by가 빈번한 컬럼이면 고려해 보아야 함

    수정이 자주 발생하지 않는 컬럼은 고려 대상

    처리 범위가 넓어 문제가 발생하는 경우는 단일 테이블 컬러스터링을 조인이 많아 문제가 발생되는 경우는 다중 테이블 클러스

    터링을 고려해야 함

 

5. 파티션 설계

대용량DB는 몇 개의 중요한 트랜잭션 테이블에서 데이터가 저장하므로 보다 작은 단위로 나눔으로써 성능 저하 방지와 관리의 용이성을 사용하는 기법

파티션의 종류

    (1) 범위분할(Range Partitioning) : 지정한 열의 값을 기준으로 분할, 숫자나 날짜 기준

    (2) 해시분할(Hash Partitioning) : 해시 함수에 따라 데이터를 분할

    (3) 조합분할(Composite Partitioning) : 범위분할 후, 해시 함수를 적용하여 다시 분할

장점

    (1) 데이터 액세스 범위를 줄여 성능 향상

    (2) 전체 데이터의 훼손 가능성이 감소 및 데이터 가용성 향상

    (3) 각 분할 영역을 독립적으로 백업하고 복구 가능

    (4) Disk Striping로 I/O 성능을 향상(Disk 컨트롤러에 대한 경합의 감소

 

 

6. 디스크 구성 설계를 함

위의 다양한 오브젝트의 디스크 구성 설계시, 고려사항을 참조하여 설계하도록 함