6장 모델검토

분석단계에서 모델링 작업이 완성되고, 설계단계로 넘어가기 전에 모델에 대한 검증작업이 이루어진다.
ERD모델을 검증하는 목적은 고객의 업무분석이 효과적으로 이루어졌고, 분석된 업무의 내용이 효과적으로 데이터 모델에 표현되었는지, 정확하고 안정적이며, 확장에 유연한 모델인지 확인하는 것이다.
모델을 검토하고 수정하는 작업은 시스템 구축을 요청한 고객이 모델의 내용을 인정, 승인할 때까지 지속적으로 하는 것이 원칙이다.
하지만 실제로는 모델의 완성도가 높아지고 위험요소가 발견되지 않는다면 설계단계에서 보완하며 진행하는 것도 무리없는 진행방법이다.
이미 상세설계단계가 종료되고 개발이 진행중인 상태에서 중요한 모델을 변경하는 것은 프로젝트 일정에 치명적인 영향을 준다.

데이터 모델 검토는 세개의 조직에서 이루어진다.

(1) 모델링을 수행한 모델러
소규모 프로젝트에서 이루어지는 형태
단점:내부인원이 검토하기 때문에 정확하고, 객관적인 시각에서 모델을 검증할 수 없다.
장점:업무를 잘알고 모델을 검토할 수 있다.

(2) 시스템 통합팀이나 품질보증팀
프로젝트 조직에는 방법론,모델링,데이터베이스,기반기능의 전문인력을 통합한 전문 시스템 통합팀이나 품질 보증팀이 있는 경우가 많다.
이 경우는 업무파악이 응용팀의 모델러에 수준이 미치지 못하더라고 전체모델링작업을 하는 동안 업무파악이 어느정도 되었으므로, 모델검토가 용이하고 시스템 전체적인 인터페이스를 검증하는데 효율적검증이 될수있다. 하지만, 내부인원이 모델검토를 수행하므로, 단점을 정확하게 지적하는데 효과적이지 못할 수 있으며, 모델링 작업을 교육,지도하였으므로 객관적이지 못할 수 있다.

(3) 외부감리인원 초청
프로젝트 내부인원이 아니므로 객관적 검증이 가능하고, 문제점을 프로젝트상황과 상관없이 이야기할 수 있다.
하지만, 복잡한 업무에 대한 이해가 빠른 시간안에 이루어져야 하므로 업무파악의 한계가 있어, 업무적 결함이 있는 모델에 대하여 지적하지 못하는 한계가 있을 수 있다.
또한, 프로젝트 내부인원이 효과적인 감리지원을 하지 않거나, 의사소통이 원활하지 않을 경우, 상황에 맞지 않는 검토결과를 초래할 수도 있다.

중요한 프로젝트인 경우, 충분한 시간을 가지고 시스템 통합팀에서 모델을 검토한후, 분석단계 종료시점에서 감리를 초청하여 검토받는 이중적인 검토활동을 수행하여 모델의 완성도를 높인다.

ERD는 분석단계의 가장 중요한 결과물로, 업무적 측면, 모델규약측면 두가지면에서 검토가 이루어진다.
(1) 업무적 측면
모델링이 업무적요건을 충분히 반영하고 있는지, 모델링의 관계가 업무프로세스에 잘 부합하는지 검토한다.
요구사항 정의서, 업무기능분해도, CRUD MATRIX와 같은 분석단계산출물이 관련자료로 활용된다.

사례)
사용자 요구사항과 대비하여 도출되지 않은 엔티티타입 및 속성은 없는가?
엔티티타입간의 관계는 업무절차와 잘 부합하는가?

(2) 모델규약 측면
데이터모델링이 갖추어야할 일반적인 규약을 잘 준수하고 있는지 검토한다.
케이스 툴의 검증기능이나 검토와 관련된 기타 툴이 활용되기도 한다.

사례)
다른 타입/크기, 제약(Constraint)을 가지는 중복된 속성은 존재하지 않는가?
엔티티간의 관계가 M:N으로 정의된 것은 없는가?
엔티티타입명, 속성명, 관계명에 대한 정의는 모델의 일반규약을 준수하고 있는가?

데이터 모델은 모델의 구성요소에 따라 엔티티타입, 관계, 속성, 도메인의 네가지로 볼수있으며, 구성요소별로 검토 내역 및 주요 오류사례에 대해 기술하기로 한다.

1. 엔티티타입 검토

엔티티타입은 자료를 저장하는 곳이다.
현업의 장표, DFD의 데이터 영역을 표시하는 데이터스토어, 업무기술서, 인터뷰내용, 현행 시스템 분석등 여러 부분에서 초기엔티티가 도출될수있다.
초기 엔티티 타입은 정규화 및 비정규화를 통해 업무가 구체화되고, 시스템 환경을 고려함에 따라 전략적으로 병합, 분리, 신규도출, 제거 등의 과정을 거친다.
최종적으로 생성된 엔티티타입은 모델러의 능력과 관점, 업무 및 시스템환경의 이해도에 따라 다양한 형태로 나타날 수 있으며, 이에 따라 자료의 무결성, 성능, DB확장성, 활용성에 지대한 영향을 미치게 된다.

엔티티타입을 검토하는 대표적인 질문내용은 다음과 같다.

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

• 주요 오류유형 사례

(1) 자료의 유일성을 보장할 수 없는 항목에 의한 PK선정
업무분석이 구체화되면서 초기에 예측했던 주식별자가 유일성의 요건을 충족하지 못할 때 주로 발생한다.

초기요건: 보험계약변경은 하루에 한번이상 발생하지 않는다.
변경요건: 보험계약변경은 하루에 두반이상 발생할 수 있다.

(2) 일반적으로 필요이상의 항목을 PK로 선정한 경우
두개이상의 부모엔티티타입이 하나의 자식엔티티타입과 만나 상위부모엔티티타입PK 모두 자식 엔티티타입PK에 포함시켰을때 주로 발생한다.

(예 1) ARC 관계에 의한 여러 부모와 자식 엔티티간의 관계
보험에 대한 계약은 법인에 의한 수탁약정과, 개인에 의한 보험계약으로 이루어진다.
두계약은 성격이 달라 독립된 엔티티로 구성하고, 계약이력은 통합조회가 많아 하나의 엔티티타입으로 통합하여 모델링하였다.
통합시에, 부모엔티티PK을 하나로 통합할 수 있는 적절한 도메인을 정하는 것이 좋다.

(예 2) 하나의 완전 종속부모와 기타 부분 종속 부모를 가진 자식 엔티티타입
보험업무에서 소송이 발생하여 원고 또는 피고가 상소를 하게 되면, 원고 및 피고는 자신들이 조사한 장해내역을 제출한다.
판결은 원고 또는 피고의 장해내역에 대해 "한쪽"의 조사내역을 완전히 인정하는 것으로 내려진다.
(완전종속부모:상소내역, 부분종속부모:확정내역, 자식:장해내역)
겉으로 보기엔 순환참조가 있는 모델처럼 보이나, 지극히 정상적인 모델이다.
확정내역에 따른 장해내역엔티티와, 상소내역에 따른 장해내역엔티티가 별도로 존재했던 것을 병합했기 때문에 이상한 모델의 모습처럼 보이는 것이다.

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

PK를 정하는 기준은 다음과 같다.
선정된 속성은 해당 업무에서 대표성을 가지는가?
최소의 속성으로 자료의 유일성을 확보할 수 있는가?

인사관리 업무에서 사람을 식별할 수 있는 속성은 사번, 주민등록번호 등이 있을 수 있으나, 주민등록번호는 유일성은 있으나, 특정회사 조직원에 대한 대표성은 없으므로 PK로는 적합치 않다.
자료의 유일성을 확보하고자, 여러 속성으로 PK를 구성할 수도 있는데, 엔티티타입간에는 상호관계를 가지므로, 부모엔티티에 선정된 PK는 자식엔티티, 손자엔티티의 PK구성에 지대한 영향을 미친다.
다시말해, 부모엔티티의 PK가 4개의 속성을 조합하여 만들었다면, 자식,손자엔티티는 4개이상의 PK가 되며, PK가 너무커지면 인덱스로서의 효용이 떨어진다.
그러므로 자료의 유일성을 확보할 수 있는 최소한의 속성으로 PK를 구성하거나 일련번호를 적절히 활용한다.

• 주요 오류유형 사례

(1) 업무분석결과 자료의 유일성을 확보할 수 있는 적절한 속성의 조합이 파악되지 않아 최대한 많은 항목을 PK로 선정하여 자료의 유일성을 확보하려는 경우
인사시스템에서 사원명,생년월일, 성명등의 속성으로 사원정보 엔티티타입에 대한 자료의 유일성을 확보할 수 없다.
그러므로 일반적으로 사원번호를 만들어 개개인을 식별한다.

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

• 주요 오류유형 사례

(1) 장표단위의 엔티티 타입 생성
영업업무에서 현행문서를 검토하여, 부서별 매출현황과 지점별 매출현황을 엔티티타입으로 생성하였다.
그럴 경우, 매출이 발생 변경할 때는 항상 두 엔티티타입을 동시에 생성/변경하는 상황이 초래되었다.
매출은 특정사원이 특정일자에 특정제품을 판매하는 것으로 나타나 사원기준으로 테이블을 수정하였다.

(2) 집약도가 큰 여러개의 통계 엔티티 타입
고객이 제품별, 월별, 부서별, 분기별 매출집계내역을 알고 싶다고 요구해서, 세개의 엔티티타입을 생성하였다.
이와 같은 형태로 구성하면, 고객이 요구하는 통계수만큼 엔티티타입을 생성해야 하므로, 고객의 요구에서 공통요소를 도출하여 활용할 수있는 엔티티를 생성하면, 엔티티수를 최소화할 수있다.

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

업무는 단위업무간의 상호 연관을 맺으며 지속적으로 흐른다. ERD는 이러한 흐름의 관계를 표현한 것이므로 독립된 엔티티타입이나 엔티티타입 그룹의 존재는 업무분석이 미흡한 것으로 의심할 수 있다.

단, 세가지 경우는 예외가 될 수있다.
코드 엔티티는 관계를 갖으나, ERD에 일일이 표현하면 복잡하므로 일반적으로 표현하지 않는다.
통계 엔티티는 검색편의를 위한 단순 조회용 엔티티로서 업무적 흐름이 없다.
시스템관리 엔티티타입은 업무와 개별적으로 시스템을 통제하기 위한 엔티티 타입이므로 경우에 따라서는 업무적 연계가 없을 수도 있다.

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

엔티티타입의 병합 및 분리기준은 관계가 1:1일때 업무적 속성간에 또는 레코드간에 어떠한 연계성이 있느냐에 따라 좌우된다.
업무간의 선후 관계가 있다면, 분리하는 것이 좋다.

여러 엔티티타입의 상호PK가 같고, 구성항목이 비슷하면 통합을 검토할수 있다.
엔티티타입간의 정보를 검토한 결과, 구성항목은 거의 유사하나 그 자료가 배타적이어서 상호 영향을 미치지 않는다면 병합하는 것이 좋다.

• 주요 오류유형 사례

(1) 연속적인 업무절차가 같는 엔티티타입의 병합으로 인해 발생하는 문제
특정 사건에 대해 보험금 심의를 하고 심의된 사건의 확정여부에 대해서 처리할때, 심의 및 확정이 종결된 자료를 확정이 취소되어 자료를 삭제하면, 심의 정보까지 같이 삭제된다.
원래 엔티티 타입에 있는 업무성질에 따라 엔티티 타입을 분리하거나, 병합이 발생된 엔티티타입에 대해서 업무프로세스를 고려한 추가적인 시스템 관리 속성을 만들어준다.

(2) 대칭적인 업무의 경우 엔티티타입의 분리
회계 시스템에서 관리되는 전표에는 매출전표, 매입전표등 여러 전표가 있으나, 구성항목은 유사하다.
이때 엔티티 타입을 통합관리하면, 보고서를 출력할 때, 효과적으로 처리할 수 있다.

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

데이터 모델링을 할 때, 초기 엔티티타입을 생성한 후 엔티티타입의 지속적인 추가 및 삭제가 일어나는 이유는 다음과 같다

도출된 엔티티타입간의 관계를 분석하는데 M:N관계가 발생하여, 이를 분해하면서 추가적인 엔티티타입이 도출
1,2,3차 정규화 과정에서 추가적인 엔티티타입 도출
단위시스템간 모델링을 통합하는 과정에서 시스템간 연계 엔티티타입이 생성되지 않는 경우 발견
단위시스템간 모델링을 통합하는 과정에서 중복 또는 유사한 엔티티타입이 발견되어 제거 또는 통합
통계 및 시스템관리를 목적으로 엔티티타입을 추가 및 도출
초기 도출된 엔티티가 추후 분석과정에서 해당업무영역에서 제외되는 것임이 판명될때

• 주요 오류유형 사례

(1) 단위 시스템간에 중복된 엔티티타입 발생

(2) 업무적으로 상호 M:N의 관계를 가지는 엔티티타입간의 관계에 의한 추가 엔티티타입이 필요
공급자와 제품간의 관계를 분석하는 과정에서 한종류의 제품을 여러공급자가 제공할 수 있음을 알게되어 추가 엔티티타입을 도출

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

(예1) 1차 정규화 응용
장기재고가 4개월이상으로 늘어날 때 모델을 변경해야 하는 치명적 결함이 있으므로, 업무변형에 따른 데이터 모델의 확장성을 확보하도록 해야 한다.

(예2) 2차 정규화 응용
여러개의 속성이 주식별자로 구성되어 있을 때, 주식별자중 일부에 종속된 일반속성이 있는 경우, 엔티티타입을 분리한다.

(예3) 3차 정규화 응용
결정자 역할을 하는 일반속성이 있고, 결정자 역할을 하는 속성에 의존하는 의존자가 있는 경우는 3차 정규화 대상이다.

엔티티타입이 주변 여러 엔티티타입의 공통엔티티타입인 경우 자료원천이 어느 엔티티타입인지 추적할 수 있는가?
이러한 경우는 공통엔티티타입과 주변 엔티티타입과의 관계가 슈퍼타입/서브타입 관계일때 주로 발생한다.
3가지 유형이 있다.

하나의 부모 엔티티타입이 여러개의 배타적 자식 엔티티타입과 관계를 가지는 경우
하나의 자식이 엔티티타입이 여러개의 배차적 부모 엔티티타입과 관계를 가지는 경우
상호관계가 1:1인 공통 엔티티타입과 주변 엔티티타입과 관계를 가지는 경우

위의 어떤 경우라도 공통으로 관계를 가지는 엔티티 타입에는 어느 엔티티타입과 연결이 가능한지 구분속성이 있어야 한다.

• 주요 오류유형 사례

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

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

PK는 자신의 엔티티타입에서 자료검색및 주변 엔티티타입과 조인하여 검색할 경우 가장 빈번히 사용되므로, 항상 인덱스가 생성된다.
인덱스는 정렬순서가 매우중요한데, 인덱스순서를 어떻게 정하느냐에 따라서 SQL의 성능을 좌우하기 때문이다.

PK조합 우선순위규칙은 다음과 같다.
모든 SQL에서 항상 사용되는 속성은 우선순위를 제일높게 해야 한다.
분포도가 좋은 속성은 우선순위가 높다.(분포도가 좋다는 의미는 자료의 식별성이 뛰어난 속성을 의미한다)
'='조회를 하는 컬럼은 우선순위가 높다.

• 주요 오류유형 사례

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

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

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

2. 속성 검토

엔티티타입 내에서 관리하고자 하는 정보의 항목을 나타내며, 도출된 속성은 정규화과정을 통해 재배치되어 PK를 제외하고 전체ERD에 중복되지 않게 존재한다.
추후 시스템의 성능을 고려하여 반정규화에 의한 속성, 합계, 수량등의 파생속성, 기타 시스템 관리 속성등이 추가되어 실제로 DB에서 관리하게 될 전체 정보가 정의된다.

다음은 속성에 대한 검증 내역이다.

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

정규화가 완성되면 모든 속성은 전체ERD에 걸쳐 하나만 존재하게 되며, 반정규화를 거친 속성은 ERD내에 두개이상 발견될 수 있다.
대규모 시스템에서는 무엇이 반정규화 된 속성인지 알수 없으므로, 개발자는 개발을 마친후 유지보수 담당자에게 인계할 때, 반정규화된 내역에 대해 명확히 설명해주지 않으면, 자료의 무결성이 깨지는 치명적인 문제가 발생될 수 있다.

• 주요 오류유형 사례

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

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

ERD에서 반정규화를 하는 이유는 검색시 데이터베이스의 성능을 빠르게 하기위해서다.
하지만 다음과 같은 단점이 있다.

자료를 수정할때, 관련 엔티티타입에 존재하는 반정규화된 속성도 함께 변경해주어야 하므로, 자료수정시 부하가 발생된다.
프로그램에서 반정규화된 속성을 병행수정하는 프로세스가 빠진 경우 자료의 무결성이 깨질 수 있다.

그러므로, 반정규화는 주의깊게 검토되어야 하며, 반정규화된 속성에 대해서는 반드시 자료의 무결성 확보를 위한 완벽한 시스템적 절차와 운영자의 데이터베이스 변경통제절차가 있어야 한다.

개발하고자 하는 시스템이 DW라면, 반정규화의 적극적인 도입을 검토한다.
그 이유는 다음과 같다.
DW는 엔티티당 매우많은 데이터를 관리하고 SQL역시 매우 많은 데이터에 접근하므로, 정규화 상태로 검색을 하면 치명적 성능저하가 따를 수 있다.
DW의 자료는 수시로 생성되는 데이터가 아니고, 실제적으로 기초코드관레 엔티티타입을 제외하고는 자료의 수정,삭제는 없가고 해도 무방하다.
그리고 자료의 무결성이 깨진다 하더라도 원천자료는 이미 가지고 있으므로, 얼마든지 복구가능하므로, 무결성에 대한 부담이 적기 때문이다.

• 주요 오류유형 사례

(1) 시스템 특성에 따르지 않은 과도한 반정규화
이력엔티티 타입에서는 대체로 정보의 확정 시점을 가지는 경우가 많아 반정규화를 적극적으로 검토해 볼 수 있다.
하지만 급여이력, 수당이력, 공제이력 엔티티타입은 확정이력이 동일해 반정규화된 항목에 대한 수정시 반영기준도 동일하므로, 급여이력 엔티티에만 반정규화를 실시하였다.

(2) 반정규화를 하지 않아 발생하는 시스템 성능저하
특정 계열사의 행정동별 우수고객을 검색할 때, 행정동 속성을 계열사별 고객 엔티티타입에 반정규화하여 시스템 성능을 향상 시켰다.

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

ERD의 속성 명명규약이 적절히 준수되었다면, 명칭이 동일한 속성은 같은 도메인을 가지므로 타입과 크기가 같아야한다.
같지 않다면 다음과 같은 문제가 발생한다.

자료의 무결성이 깨질수 있다.
SQL조인시 연결고리의 타입이 달라서, 컬럼 변형이 일어나 인덱스검색을 하지 못해 성능이 저하될 수 있다.

• 주요 오류유형 사례

(1) 크기의 불일치

(2) 타입의 불일치

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

내부적 속성은 속성발견 초기부터 내부적 속성을 가지는 경우(성명(성+이름), 주민번호(생년월일+일련번호))와 해당 시스템의 필요성에 따라 여러속성을 병합하여 만들어지는 속성(문서번호(문서발생부서+문서유형+날짜+일련번호)이 있다.

시스템의 필요에 따라 여러속성을 병합하여 만들어지는 속성은 일반적으로 내부속성이 해당 업무시스템에 유용한 정보로서 가치가 있는 경향이 많다.
그러므로, 속성의 병합이 해당 시스템에 유용한가를 검토하고, 유용하다면 병합속성외에 별도로 내부속성이 분리된 속성을 관리하고, 유용하지 않다면 병합속성을 분리해야 한다.

• 주요 오류유형 사례

(1) 병합된 속성만 관리
전표번호는 발행부서+전표유형+날짜+일련번호로 이루어진다.
이 속성을 분리하여 PK로 관리하면, 자식 엔티티 및 손자 엔티티의 PK는 매우 길어지므로, 병합된 전표번호를 PK로 사용하는 것은 유용하다.
하지만 전표번호의 내부적인 속성도 매우 중요한 속성이므로, 병합된 속성 외에 분리된 속성도 함깨 관리한다.

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

속성 설정기준은 한 속성에는 정의된 속성하나만 갖는것이 원칙이다.
하지만 전화번호, 주민번호, 날짜 등과 같이 병합하였을 때 단일속성이 더 잘 표현되는 경우가 있다.
이런경우에는 병합하여 사용하는것이 좋으며, 하지만 특정시스템에서는 분류하는것이 더 좋을 수도 있다.

• 주요 오류유형 사례
  (1) 날짜와 같이 대부분 범위 조회가 일어나는 속성

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

모델링 규약상 기존 속성의 연산에 의한 파생속성은 권장되지 않는다.

• 주요 오류유형 사례
  (1) 중간 데이터가 변경할 수 있는 이력 엔티티타입에서 현재 데이터까지의 누적정보를 관리하는 속성

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

데이터 모델을 설계할 때, 현행업무를 전산화하는 관점으로 설계하느냐, 추후 경영전략적인 측면에서 사용될 정보로 데이터베이스를 설계하느냐는 모델링시 중요한 요소이다.

• 주요 오류유형 사례

(1) 코드화할 수 있으나 텍스트로 정의된 속성

3. 관계 검토

관계는 엔티티타입간에 업무적 관계를 정의하는 것으로 사용자와의 인터뷰, 업무 흐름도, DFD에서 데이터 흐름 등을 통해 어느 엔티티타입 사이에 관계가 있는지 파악할 수 있다.

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

M:N의 관계를 가지는 엔티티타입에 대해 새로운 부모 엔티티타입을 생성하여 관계를 연결해준다.
두 엔티티타입중 하나의 관계를 All Or Nothing으로 하여 1:N 또는 N:1관계를 정의하든가, 두엔티티 모두의 관계를 All Or Nothing으로 정의한 경우다.
M:N의 관계를 가지는 엔티티타입에 대해 새로운 자식 엔티티타입을 생성하여 관계를 연결해주는 것이다.

• 주요 오류유형 사례
  (1) M:N 관계를 갖는 엔티티타입에 대해 새로운 부모 엔티티타입을 생성하여 관계를 연결하는 경우

(2) 두 엔티티 중 하나의 관계를 All Or Nothing으로 하여 1:N의 관계를 정의하는 경우

(3) M:N의 관계를 갖는 엔티티타입에 대해 새로운 자식 엔티티타입을 생성하여 관계를 연결하는 경우

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

• 주요 오류유형 사례

(1) 매출 및 급여에서 발행하는 전표를 통합하여 관리하는 전표 엔티티타입과 매출 엔티티타입 및 급여 엔티티타입과의관계

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

업무적으로 명확히 정의되지 않아 엔티티타입만 도출하고 추후에 관계정의를 하는 경우
단위시스템간에 업무적 연계가 정의되지 않은 경우

• 주요 오류유형 사례

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

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

업무의 흐름에 직접 관여하는 모습을 나타내지 않아도 상식적으로 알수 있는 엔티티타입은 관계를 표현하지 않고, 나머지 모든 업무 흐름에 대해서는 관계를 정의하여 표현한다.

• 주요 오류유형 사례

(1) 코드 및 통계 엔티티타입과의 관계 연결

(2) PK를 상속받은 엔티티타입과 조상 엔티티타입과의 관계 연결

4. 도메인 검토

도메인은 속성들의 동일 정보속성을 표현한 최소단위로, 엔티티타입별로 속성이 식별되고, 속성을 분석함으로써 생성된다.
도메인에 정의될 수 있는 속성은 데이터타입, 크기, 데이터 제약으로 구성되며, 도메인의 생성 목적은 다음과 같다.

업무적으로 동일한 정보 속성을 가지는 속성이 다른 속성으로 정의되는 것을 방지한다.
업무적으로 동일한 정보 속성을 가지는 속성이 변경될 때 도메인을 통해 변경됨으로써 동일하는 정보속성을 가지는 속성들이 다른 속성으로 정의되는 것을 방지한다.

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

• 주요 오류유형 사례

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

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

• 주요 오류유형 사례

(1) 복잡한 데이터 모델에서 도메인 관리 소홀