모델링 주요 개념

1) 모델링 검토 시기

• 분석단계에서 모델링 작업이 완성되고, 설계 단계로 넘어가기 전에 모델에 대한 검증작업이다.
  
  

2) ERD모델을 검증하는 주요 목적

• ① 해당 고객의 업무 분석이 효과적으로 이루어졌을까?
• ② 분석된 업무를 바탕으로 업무의 내용을 효과적으로 데이터 모델에 표현했을까?
• ③ 모델은 정확하고 안정적으로 했을까?
• ④ 이후에 확장 가능한 유연한 모델인지를 살펴 보았을까?

3) 실제 프로젝트에서 데이터 모델 검토 3단계에서 진행

• ① 모델링을 수행한 모델러
  • 내부 인우너이 검토하기 때문에 정확하고 객관적인 시각에서 모델을 검증 할 수 없다는 단점과 업무를 잘 알고 모델을 검토할 수 있다는 장점
• ② 시스템 통합팀이나 품질 보증팀
  • 전체 모델링 작업을 진행하는 동안 어느 정도 업무 파악이 되어있으므로, 업무에 의한 모델 검토가 용이하고 시스템 전체적인
  • 인터페이스를 검증하는 데 효율적인 검증이 수행될 수 있다.
• ③ 외부 감리 인원 초청
  • 분석 단계 종료 시점에 감리를 초청하여 다시 모델을 검토받는 이중적인 검토 활동을 수행하여 모델의 완성도를 높이는 경우

4) ERD 분석 단계 활동

• ① 업무적인 측면
  • 모델링이 시스템의 업무적 요건을 충분히 반영하고 있는지, 모델링의 관계가 해당 업무 프로세스에 잘 부합하는지 검토한다.
  • 요구 사항 정의서, 업무 기능 분해도, CRUD MATRIX와 같은 분석 다녜 산출물이 관련 자료로 활용한다.
• ② 모델 규약 측면
  • 데이터 모델링이 갖추어야 할 모델링에 관한 일반적인 규약을 잘 준수하고 있는지 검토한다.

1.엔티티타입 검토

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

• 이유 ▶ 엔티티타입 내에 저장/관리되는 자료의 유일성을 식별하기 위한 것이다.

주요 오류 유형 사례

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

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

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

• 두 개 이상의 부모 엔티티타입이 하나의 자식 엔타티타입과 만나 상위 부모 엔티티타입 PK를 모두 자식 엔티티타입으로 PK에 포함시켰을 경우에 주로 발생한다.
• 예1) ARC 관계에 의한 여러 부모와 자식 엔티티간의 관계

• 오른쪽 모델에서 구성된 PK처럼 여러 부모로부터 받은 PK를 그 속성에 따라 하나로 통합될 필요.
• 계약이력 엔티티타입에는 수탁 약정 엔티티타입이든지 보험계약 엔티티타입이든지 특정 시점에는 하나의 관계만 있을 수밖에 없으므로 비식별자 관계로 연결할 수밖에 없다.
• 양쪽에 선택 관계로 해주어야 정상적으로 이 관계가유지될 수 있다.

예2) 하나의 완전 종속 부모와 기타 부분 종속 부모를 가진 자식 엔티티타입

• 확정내역은 원고나 피고 하나만 가능하다는 업무 규칙을 적용하기에 적절한 PK가 될 수 없다.
• 장해내역에 등록된 모든 데이터는 확정내역에도 등록되어야한다는 PK구조를 가지고 있음.
• 확정내역에 대한 장해내역의 관계가 PK 상속 관계가 될 수 없는 비식별자관계 표현.
• 결론 : 확정내역 엔티티타입에 따른 장해내역 엔티티타입이 원래 존재하였고, 상소내역 엔티티타입에 따른 장해내역 엔티티타입이 별도로 존재했던 것이다.

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

*이유 ▶ SQL 등을 통해 데이터의 입력, 수정, 조회, 삭제 등을 처리할 때 SQL 전반에 걸쳐 매우 빈번히 사용되는 속성임

주요 오류 유형 사례

잘못된 ERD

• PK를 복잡하게 선정함으로써 업무 전체적으로 엔티티타입에 PK가 복잡해지는 경우

개선 ERD

• ERD의 중심 엔티티타입인 사원의 PK가 사원번호로 단순화됨으로써 자식 및 손자 엔티티타입의 PK가 단순하게 될 수 있다.
• PK가 단순해지면 복잡한 SQL문장이 훨씬 더 단순해질 수 있다.

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

주요 오류 유형 사례

(1) 장표 단위의 엔티티타입 생성

• (문제) 시스템을 구축했을 때 매출이 발생하거나 변경되어 두 엔티티타입을 동시에 생성/변경해야 하는상황
• (해결) 매출은 특정 사원이 특정일자에 특정 제품을 판매(Who, When, Whar)하는 것으로 나타나 사원 기준으로 테이블을 수정

(2) 집약도가 큰 여러 개의 통계 엔티티타입

• (문제) 고객이 요구하는 통계 수만큼 엔티티타입을 생성
• (해결) 고객의 요구에서 공통 요소를 도출하여 활용할 수 있는 엔티티를 생성하면 엔티티타입의 수를 최소화할 수 있다.

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

• ERD에 독립된 엔티티타입이나 엔티티타입 그룹의 존재는 업무 분석이 미흡한 것으로 의심할 수 있다.

예외

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

병합 또는 분리되어야 하거나 불필요한 엔티티타입은 없는가?

주요 오류 유형 사례

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

• (문제) 그림에 심의 및 확정이 종결된 자료를 확정이 취소되어 해당 자료를 삭제하면, 심의 정보까지 같이 삭제된다.
• (해결) 그림에 확정 취소 여부를 관리하여, 확정을 취소할 때 심의 데이터에 대한 영향 없이 데이터를 관리할 수 있다록 유도할 수 있다.

(2) 대칭적인 업무의 경우엔티티타입의 분리

• 엔티티타입을 통합하여 관리한다면, 발행인별 전표 현황, 발행 일자별 전표 현황의 보고서를 출력할 때
• 엔티티타입을 분리하여 처리하는것보다 훨씬 유리하다.

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

주요 오류 유형 사례

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

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

• (문제) 제품과 공급자 엔티티타입간의 관계가 M:N으로 연결되어 있으므로 관계 엔티티타입이 필요
• (해결) 제품과 공급자 엔티티타입의 PK를 복합 PK로 구성한 공급자제품이라는 관계 엔티티타입이 생성해준다.

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

• 예1) 1차정규화 응용

• (문제) 왼쪽 모델의 일재로에는 3개월분에 대한 장기재고수량, 주문수량, 금액, 주문금액이 차례대로 기술되어있다.
• 이렇게 되면 장기재고 관릴가 4개월 이상 으로 늘어날 때 모델을 변경해야 하는 치명적 결함.
• (해결) 오른쪽과 같이 1차 정규화를 통해 모델을 분리함으로써 업무 변형에 따른 데이터 모델의 확장성을 확보하도록 해야 한다.
• 예2) 2차 정규화 응용
• 여러 개의 속성이 주실별자로 구성되어 있을때 일반 속성 중에서 일부 주식별자에만 종속적인 속성이 있을경우 2차 정규화를 적용하여 엔티티타입을 분리하도록한다.

• (문제) 실전 프로젝트에서는 코드 유형의 엔티티타입들이 2차 정규화가 되지 않고, 하나의 엔티티타입으로 표현되는 경우가 많다.
• (해결) 고객번호에 종속적이지 않은 속성들을 분리하여 고객점포라는 새로운 엔티티타입을 생성한다
• 예3) 3차 정규화 응용
• 결정자 역할을 하는 일반 속성이 있고, 결정자 역할 속성에 의존하는 의존자가 존재하는 엔티티타입은 3차 정규화 대상

• (문제) 등록카드번호가 결정자 역항를 하고 , 등록카드사면과 등록카드유효일자가 의존자 역할을 하는, 속성간의 종속성이 발견되었다.
• (해결) 등록카드에 대한 내용에 대해 별도의 엔티티타입을 도출한 오른쪽 모델로 만듦으로써 3차 정규화를 완성시킴.

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

주로 공통 엔티티타입과 주변 엔티티타입과의 관계가 수퍼타입/서브타입 관계일 때 주로 발생하는 3가지

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

주요 오류 유형 사례

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

• (문제) 문서 공통 수퍼 엔티티타입에 서브 엔티티타입을 구분할 수 있는 구분자가 없는 것이 문제.
• (해결) 문서 공통 엔티티타입에 문서 구분을 속성으로 지정함으로써 경비요청서, 근무명령서, 입고증 서브 엔티티타입을 효과적으로 찾아갈 수 있게 된다.

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

PK조합 우선순위는 대체로 다음 규칙에 따라 결정

• 1. 모든 SQL에서 항상 사용되는 속성은 우선순위를 제일 높게 해야한다.
• ==> SQL의 WHERE에 첫번째 속성이 표현되어 있지 않다면 그 인덱스는 사용되지 않기 때문이다.
• 2. 분포도가 좋은 속성은 PK 선정에서 우선순위가 높다.
• 3. '='조회를 하는 컬럼은 PK 조합 시 우선순위가 높다.

주요 오류 유형 사례

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

• (문제) 검색 유형을 검토한 결과 날짜를 통한 급여 현황을 조회할 경웅는 항상 사원정보를 읽는다고 하면,
• 결국 사원번호는 항상 조회 항목으로 사용된다.
• (해결) 급여 엔티티타입의 사원번호를 PK의 첫 번째 항목으로 하는것이 유리하다.
• 검색 유형에 따라 PK 순서를 조정함으로써 실제 SQL실행 시 성능 저하를 예방할수 있다.

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

• (문제) PK에따른 조회 유형에는 사원번호에의한경우, 사원번호+사원구분에 의한 경우, 사원구분에 의한 경우
• 이때 사원번호에 의한 경우에는 사원 구분이 PK의 첫 번째 속성으로 있을 때 PK 인덱스를 사용할수 없다.
• (해결) 사원번호+사원구분의 경우는 PK의 순서에 상관없이 적절하게 인덱스를 사용한다
• 사원구분은 분포도가 매우 낮은 속성이므로 플 스캔하는것이 빠르다.

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

• (문제) 인사시스템의 발령 정보를 읽는 SQL이 있다고 가정하자. 어떤 사원이 어떤 발령내역을 가지고 있는지 조회하는 경우가 많을것이다.
• (해결) '=' 비교를 할 수 있는 어떤 사원에 해당하는 사원번호는 PK의 맨 앞에 위치해야 한다.

2.속성 검토

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

• 속성의 명명은 정규화 시점을 기준으로 이루어진다.
• 정규화가 완성되면 모든 속성은 전체 ERD에 걸처 하나만 존재하게 되며, 이 시점을 기준으로 속성이 명명된다.

주요 오류 유형 사례

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

• (문제) 매출 정보의 전화번호는 반정규화된 속성인데, 고객엔티티타입과 사원 엔티티타입 중 어느 엔티티타입으로부터 반정규화된 속성인지 식별되지 않는다.
• (해결) 개선 모델 에서는 고객전화번호 속성과 사원전화번호 속성의 이름을 다르게 한후 매출정보 엔티티타입에서 고객전화번호를 반정규화했다.
• 반정규화된 속성-의미가 다른 속성이나 이름만 같은 속성 공존

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

• ERD에서 반정규화를 하는 이유는 검색 시 데이터베이스의 성능을 빠르게 하기 위함.

단점.

• 1.자료를 수정할 때 관련 엔티티타입에 존재하는 반정규화된 속성도 함계 변경해 주어야 하므로 자료 수정 시 부하가 발생한다.
• 2.반정규화된 속성을 병행 수정하는 프로세스가 빠졌다든지 운영자에 의해 자료가 직접 변경되는 경우가 생기면 자료의 무결성이 깨질 수 있다.

주요 오류 유형 사례

(1) 시스템 특성에 따르지 않은 과도한 반정규화

• (문제) 이러한 모델은 만일 사원명 또는 직위가 변경되면 문제가 생김
• (해결) 인사 엔티티ㅣ타입과 최초로 자식 관계를 가지는 급여이력 엔티티타입에만 반정규화를 실시하고, 그이하 엔티티타입에 대해서는 반정규화를 실시하지 않았다.

(2) 반정규화를 하지 않아 발생하는 시스템 성능 저하

• (문제) Index: 행정동 , 2만건이 넘는다면 이하들도 2만번씩 읽는다.
• (해결) 행정동이 반정규화 했다. 특정 계열사의 행정동별 우수 고객을 검색하려고 할 때 개선 모델에서는 계열사별 고객 엔티티타입의 행정동 인덱스를 읽은후(1차검색) 계열사별 고객 테이블의 데이터에 접근(2차 검색)하게된다.
• 그러면 만 번의 접근은 2차 검색 시에서만 이루어지며, 그 속도는 수 십초 이상 걸리지 않다.

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

동일 명칭을 가지는 속성이 다른 타입과 크기를 가질 때 다음과 같은 문제가 발생

• 1. 자료의 무결성이 깨진수 있다.
• 2. 명칭이 동일한 속성간에는 SQL조인 시 연결 고리가 될 가능성이 많은데, 타입이 달라서 컬럼 변형이 일어나 인덱스 검색을 하지 못해 성능이 저하될수있다.
• 다음표는 타입과 크기의 불일치 여부

주요 오류 유형 사례

(1) 크기의 불일치

• 인사 시스템에서 사원정보의 사원명은 10바이트이고, 급여이력의 사원명은 8바이트라고 하자.
• 이때 '김 미리네'라는 사원은 9바이트를 가진다.
• 따라서 사원정보에서 사원명을 읽어 급여이력이 복사하는 SQL(Insert, Update)을 처리할 때 정보가 손실된다.

(2) 타입의 불일치

• (문제) SQL에서 근태이력의 급여지금일에 컬럼 변형이 일어남으로써 근태이력의 '사원번호+급여지급일' 인덱스가 사용되지 못하게된다.
• (해결) ?애이력과 급여이력의 컬럼 형식과 길이는 동일하게 지정해야한다.

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

내부적인 속성을 갖는 속성은 두가지로 분리

• 1. 속성 별견 초기부터 내부적인 속성을 가지는 경우로, 성명(성+이름), 주민등록번호(생년월일+일련번호), 전화번호(지역번호+국번호+일련번호)가 있다.
• 2. 해당 시스템의 필요에 따라 여러 속성을 병합하여 만들어지는 속성으로, 대표적인 예가 문서번호
• (예: 문서발생부서+문서유형+날짜+일련번호)

주요 오류 유형 사례

(1) 병합된 속성만 관리

• (문제) 전표번호(발행부서+전표유형+날짜+일련번호)를 분리하여 그 항목을 PK로 관리하게 된다면, 그 이하의 자식 및 손자 엔티티타입의 PK는 매우 길어지게 된다.
• (해결) 여러 속성이 병합된 전표번호를 PK로 사용하는 것은 유용하다

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

주요 오류 유형 사례

(1) 날짜와 같이 대부분 범위 조회가 일어나는 속성

• (문제) 인덱스 컬럼의 변형이 일어나 인덱스가 적절하게 사용되지 않아서 애플리케이션의 성능을 저하시키는 요인이된다.
• (해결) 발령일자로 병합하면 SQL에 적절한 인덱스 사용이 이루어진다.

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

주요 오류 유형 사례

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

• (문제) 공사이력 엔티티타입 안에 공사비 누적계라는 속성이 있다면, 특정 공사에 대해 매번 공사 실적이 발생할 때마다 현재 레코드의 공사비 누적계 속성에 이전 레코드까지의 합이 들어갈 것이다.
• (해결) 공사마스터와 공사이력을 분리하여 공사비 누적계라는 속성을 공사마스터 엔티티타입에서 관리한다면 공사이력의 공사비가 변경 또는 추가될 때 공사비 마스터만 변경해주면 성능 저하 없이 데이터를 관리할수 있다.

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

주요 오류 유형 사례

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

• (문제) 이 표에서 보는 것처럼 동일한 자격증에 대해 자격증명이 사용자의 입력 방법에 따라 다르게 입력될수 있으며, 자격증 이름이 'ORACLE ADMIN'인 사원을 집계한다면 사원번호가 '11111'인 사원만 집계되서 그 값은 '1'로 나올 것이다.
• 실제로는 ORACLE ADMIN 자격증 소지자는 모두 4명이다.
• (해결) 특정값에 대해 정확한 통계치가 필요하다면 속성값에 대한 코드화 작업이 필요한지 검토해야한다.
• 마지막 다음표와 같이 자격증코드가 '01' 인것을 SELECT 하므로 총건수는 4건이 나올수있다.

관계 검토

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

주요 오류 유형 사례

(1) M:N 관계를 갖는 엔티티타입에 대해 새로운 부모 엔티티타이비을 생성하여 관계를 연결하는 경우

• => 이 모델링은 특정 부서에서 특정 시점에 발생한 자재 요청 건이 그대로 구매요청에 반영되어 조정되는 모델이다.
• => 사위 마스터 엔티티타입 생성을 통한 M:N관계 해결

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

• => 업무 협의 후 일부 요청된 구매 품목의 나머지 수량은 재구매할 수 있는 것만 합의한 경우
• => 엔티티타입간 업무 재정의를 통한 해결

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

• => 구매요청별 구매 엔티티타입을 통해 요청한 자재 중 일부 수량만 구매되었다면 차기 구매에서 나머지 수량의 재구매를 실시함.
• => 동일 자재에 대해 여러 번에 걸친 구매 요청을 한번에 묶어 구매하고 싶다는 모든 요구 사항을 반영할 수 있게 된다.
• => 하위 엔티티타입 도출을 통한 해결

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

주요 오류 유형 사례

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

• (문제) 이 문장을 실제 테이블이 만들어진 데이터베이스에서 실행하면 왼쪽 모델에서는, 즉 필수 관게를 가지는 모델에서는 참조 속성이 Null이되므로 에러가 발생할수 밖에 없다.
• (해결) 오린쪽 모델에서는 급여 테이블의 전표번호가 null을 허용하는 스키마 구조기 때문에 이 문장은 정상적으로 수행된다.

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

일반적으로 업무적 흐름에 비추어 도출되지 않은 관계는 다음과 같은 경우가 발생한다.

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

주요 오류 유형 사례

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

• 일반적으로 MIS에서 가지는 단위 시스템간의 연계
• 1. 인사/급여 시스템의 급여 정보가 전표 처리됨으로써 발생하는 회계 시스템의 전표 정보
• 2. 영업 시스템에서 매출을 통해 발생하는 회계 시스템의 전표 정보
• 3. 구매 시스템에서 구매를 통해 발생하는 회계 시스템의 전표 및 자산 정보
• 4. 구매 시스템에서 구매된 제품이 자재 관리 시스템에서 창고로 입고되는 정보
• 5. 자재 관리 시스템에서 출고된 자재가 부서로 이동할 때 자신 관리 시스템에서의 자산 이동 정보
• 6. 인사 시스템의 사원 및 부서 정보는 다른 모든 시스템에서 기본적으로 사용됨

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

주요 오류 유형 사례

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

• 코드성 엔티티타입과의 관계를 모두 표현한 인사 시스템에서 직위, 부서, 사원, 발령, 퇴직,직무 등을 모델링한 것이다.

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

• 손자는 부모로부터 주식별자를 상속받았음에도 불구하고 원래 주식별자를 새성했던 자신의 할아버지 엔티티타입과 관계를 갖도록 설계한 예이다.

• (문제) 수당이력과 공제이력 엔티티타입은 자신의 부모 엔티티타입인 급여이력에서 사원번호를 상속받았을 뿐만 아니라 자신의 할아버지 엔티티타입인 사원 엔티티타입에서 도 사원번호를 상속받았다.
• (해결)수당이력과 공제 이력의 엔티티타입에서 사원번호를 생성하는 사원 엔티티타입과 관계없이 자신의 부모 엔티티타입인 급여이력과의관계를 통해 사원번호를 상속받았다.

도메인 검토

도메인 생성 목적

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

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

주요 오류 유형 사례

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

• => "구분코드 CHAR(2)"라는 도메인 대신 사원구분코드 CHAR(2)와 전표구분코드 CHAR(2)가 별도로 있어야한다.
• => 전표구분코드 도메인이 CHAR(4) 로 바뀌어도 사원구분코드의 데이터타입이나 크기는 전혀 영향을 받지 안는다.

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

주요 오류 유형 사례

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

• => 하나의 도메인이 바뀌면 전부다 추적하면서 바뀌어야한다.