데이터베이스 설계와 구축 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. 도메인 검토
* 도메인이 적절하게 정의되고 관리되는가?
- 도메인 생성기준
-> 업무적으로 동일한 정보 속성을 가져야한다.
-> 동일한 정보 속성이 아니더라도 데이터 타입과 크기 데이터 제약이 고착화 되어 변경 가능성이 없는 경우는 하나의 도메인으로 통합 가능
- 주요 오류 유형 사례
-> 논리적 개연성 없이 단지 데이터타입과 크기의 속성만 같은 것에 대해 정의된 도메인
* 도메인의 변경에 따라 속성이 변경되는가?
- 주요 오류 유형 사례
-> 복잡한 데이터 모델에서 도메인 관리 소홀