데이터베이스 설계와 구축 1부 논리 설계 -6. 모델 검토

데이터베이스 설계와 구축 - 성능까지 고려한 데이터 모델링 Part 1 논리설계

 

 

Chapter 6. 모델 검토

 

* 데이터 모델 검토

 - 모델링을 수행한 모델러

 - 시스템 통합이나 품질 보증팀

 - 외부 감리 인원 초청 : 제 3자의 입장에서 객관적인 평가가 가능

 

* ERD 검토

 - 업무적 측면 : 시스템의 업무적 요건을 충분히 반영하는가, 관계가 해당 업무 프로세스에 잘 부합하는가 검토

 - 모델 규약 측면

 

1. 엔티티타입 검토

* 선정된 PK가 업무적으로 발생하는 자료의 유일성을 보장하는가?

 - 자료의 유일성을 보장할 수 없는 항목에 의한 PK 선정

 - 일반적으로 필요 이상의 항목을 PK로 선정하는 경우

 

* 선정된 PK는 효율적인 모습인가?

 - 자료의 유일성을 확보할 수 있는 적절한 속성 조합이 파악되지 않아 여러 많은 항목의 조합을 PK로 선정하여 자료의 유일성을 확보하려는 경우

 

* 자료의 발생 유형이 유사한 엔티티는 통합되었는가?

 - 장표 단위의 엔티티 타입 생성

 - 집약도가 큰 여러 개의 통계 엔티티타입

 

* 독립된 엔티티타입이나 엔티티타입의 그룹은 없는가?

(예외 경우)

 - 코드 엔티티 관계는 ERD의 복잡성을 낮추기 위해 일반적으로 표현 X

 - 통계 엔티티타입은 검색 편의를 위한 단순 조회용이며 업무적 흐름은 없다.

 - 시스템 관리 엔티티타입은 업무와 개별적으로 시스템 통제를 위한 것으로 경우에 따라서는 업무 연계가 없을 수 있다.

 

* 병합 또는 분리되어야 할 엔티티타입은 없는가?

 - 연속적인 업무 절차가 갖는 엔티티타입의 병합으로 인해 발생하는 문제

 - 대칭적인 업무의 경우 엔티티타입의 분리

 

* 추가적으로 도출되어야 하거나 불필요한 엔티티타입은 없는가?

 - 단위 시스템간 중복된 엔티티타입 발생

 - 업무적으로 상호 M:N의 관계를 가지는 엔티티타입간 관계에 의한 추가 엔티티타입 필요

 - 1,2,3차 정규화가 미흡하여 추가적인 엔티티타입이 도출되지 않음

 

* 엔티티타입이 주변 여러 엔티티타입의 공통 엔티티타입인 경우, 자료 원천이 어느 엔티티타입인지 추적할 수 있는가?

 - 하나의 부모 엔티티타입이 여러개의 배타적 자식 엔티티타입과 관계를 가지는 경우

 - 하나의 자식 엔티티타입이 여러개의 배타적 부모 엔티티타입과 관계를 가지는 경우

 - 상호 관계가 1:1인 공통 엔티티타입과 주변 엔티티타입과의 관계를 가지는 경우

  -> 슈퍼타입/서브타입 모델에서 자료 원천 구분 표시(FLAG)가 없는 경우

 

* PK의 순서는 시스템의 성능을 고려하여 적절한 순서로 정의되어 있는가?

 - PK조합 우선순위

  -> 모든 SQL에서 항상 사용되는 속성은 가장 우선순위가 높아야함. SQL WHERE절에 첫 번째 속성이 표현되어있지 않다면 인덱스는 사용 X

  -> 분포도가 좋은 속성은 PK 선정에서 우선순위가 높다. (분포도가 좋다 => 자료의 식별성이 뛰어난 속성)

  -> ‘=’ 조회를 하는 컬럼은 PK조합시 우선순위가 높다.

 

 - 주요 오류 유형 사례

  -> 잘 사용되지 않는 속성이 PK의 첫 번째 항목으로 선정되는 경우

  -> 구분표시와 같은 속성이 PK의 첫 번째 항목으로 선정되는 경우

  -> 날짜와 같이 주로 범위를 조회하는 속성이 PK의 첫 번째 항목으로 선정되는 경우

 

 

2. 속성 검토

* 반정규화된 속성은 식별되는가?

 - 반정규화된 속성을 식별하기 위해 인계시에 반정규화 내역을 명확히 설명하여 모델링으로부터 속성을 파악할 수 있게 해야한다.

 

 - 주요 오류 유형 사례

  -> 반정규화된 속성에 실제로는 의미가 다르고 이름만 같은 속성이 공존함

 

* 반정규화는 시스템 복잡도와 성능을 고려하여 적절하게 이루어졌는가?
 - 반정규화의 단점

  -> 자료 수정 시 관련 엔티티타입에 존재하는 반정규화된 속성도 함꼐 변경해주어야 하므로 자료 수정 시 부하 발생

  -> 프로그램에서 자료 수정시, 관련 엔티티타입의 반정규화된 속성을 병행 수정 프로세스가 없거나 운영자가 직접 자료 변경 시 자료 무결성이 깨짐

  -> 데이터 웨어하우징에서의 자료와 SQL은 매우 대량이므로 정규화 상태로 검색하면 치명적인 성능 저하가 발생

 

- 주요 오류 유형 사례

 -> 시스템 특성에 따르지 않은 과도한 반정규화

 -> 반정규화를 하지않아 발생하는 시스템 성능 저하

 

* 명칭이 같은 속성의 타입과 크기는 동일한가?

 - 동일 명칭을 가지는 속성이 다른 타입과 크기를 가질 때 문제점

  -> 자료의 무결성이 깨짐. 크기가 다름으로 자료가 복사되는 값이 일부 손실 가능성 생김

  -> 타입이 달라 SQL조인 시 컬럼 변형이 일어나 인덱스 검색 불가 -> 성능 저하로 연계됨

 

- 주요 오류 유형 사례

 -> 크기의 불일치

 -> 타입의 불일치

 

* 내부적인 속성을 갖고 있는 속성은 없는가?

 - 초기부터 내부 속성을 가진 속성

 - 해당 시스템의 필요에 따라 여러 속성을 병합하여 만들어지는 속성

 - 주요 오류 유형 사례

  -> 병합된 속성만 관리

 

* 병합되어야 할 속성은 없는가?

 - 주요 오류 유형 사례

  -> 날짜와 같이 대부분 범위 조회가 일어나는 속성

 

* 전후 레코드간 영향을 미칠 수 있는 속성은 없는가?

 - 주요 오류 유형 사례

  -> 중간 데이터가 변경할 수 있는 이력 엔티티타입에서 현재 데이터까지의 누적 정보를 관리하는 속성

 

* 감사, 통계 등을 고려하여 속성이 정의되었는가?

 - 주요 오류 유형 사례

  -> 코드화 할 수 있으나 텍스트로 정의된 속성

 

 

3. 관계 검토

* 엔티티타입간의 관계가 M:N인 속성은 없는가?

 - 해결방법

  -> 새로운 부모 엔티티타입을 생성하여 관계를 연결. 실제적으로 M:N 관계는 여전히 남게 됨

  -> 두 엔티티타입 중 하나 또는 두 개 모두를 All Or Nothing으로 하여 1:N 관계를 정의

  -> 새로운 자식 엔티티타입을 생상하여 관계를 연결. 자료의 관리 수준에서 구체화가 요구됨

 

* 엔티티타입간의 관계는 업무적 흐름과 규약이 일치하는가?

 - 주요 오류 유형 사례

  -> 매출 및 급여에서 발생하는 전표를 통합하여 관리하는 전표 엔티티타입과 매출 엔티티타입 및 급여 엔티티타입과의 관계

 

* 업무적 흐름에 비추어 도출되지 않은 관계는 없는가?

 - 업무적으로 명확히 정의되지 않아 엔티티타입만 도출하고 추후에 관계 정의를 하려는 경우

  -> 모델러가 이미 인식하고 있으므로 보통 크게 문제되지는 않음

 

 - 단위 시스템간에 업무적 연계가 정의되지 않은 경우

  -> 중형 프로젝트 이상에서 흔히 발생하여 규모가 클수록 강력하고 추진력 있는 시스템 통합 조직에 의한 모델링 통합 활동이 필요함

 

 - 주요 오류 유형 사례

  -> 단위 시스템 담당자들의 업무 협의 부족으로 인한 단위 시스템간 연계 엔티티타입간의 관계 미도출

 

* 관계에 대한 표현은 적절한 수준에서 이루어졌는가?

 - 주요 오류 유형 사례
  -> 코드 및 통계 엔티티타입과의 관계 연결

  -> PK를 상속받은 엔티티타입과 조상 엔티티타입과의 관계 연결

 

 

4. 도메인 검토

* 도메인이 적절하게 정의되고 관리되는가?

 - 도메인 생성기준

  -> 업무적으로 동일한 정보 속성을 가져야한다.

  -> 동일한 정보 속성이 아니더라도 데이터 타입과 크기 데이터 제약이 고착화 되어 변경 가능성이 없는 경우는 하나의 도메인으로 통합 가능

 

 - 주요 오류 유형 사례

  -> 논리적 개연성 없이 단지 데이터타입과 크기의 속성만 같은 것에 대해 정의된 도메인

 

* 도메인의 변경에 따라 속성이 변경되는가?

 - 주요 오류 유형 사례

  -> 복잡한 데이터 모델에서 도메인 관리 소홀